From owner-ietf-pkix@mail.imc.org Sun Feb 2 16:51:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12460 for ; Sun, 2 Feb 2003 16:51:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h12L8Bf25312 for ietf-pkix-bks; Sun, 2 Feb 2003 13:08:11 -0800 (PST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h12L82o25303 for ; Sun, 2 Feb 2003 13:08:02 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id QAA02495; Sun, 2 Feb 2003 16:04:18 -0500 (EST) Message-ID: <3E3D87CB.4050209@mit.edu> Date: Sun, 02 Feb 2003 16:04:11 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Tim Polk , ietf-pkix@imc.org, Stephen Kent , Carlisle Adams , Stephen Farrell Subject: Re: Request for Consideration of RFC References: <20030131045703.958D87B4D@berkshire.research.att.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA844DA1B0061523182A917CB" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA844DA1B0061523182A917CB Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks. I'll take a look at them shortly (I've been fighting off a cold these last few days and am just now catching up). -Jeff Steven M. Bellovin wrote: > I've updated both in draft-tracker. They're now in state "publication > requested". The next step is for Jeff and/or I to review them. > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com (2nd edition of "Firewalls" book) > > --------------enigA844DA1B0061523182A917CB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+PYfL8CBzV/QUlSsRAtTgAKCq7EdpgA3ywyCMi3r28s/DPt5lbQCfaWiZ fr0r4UKar4GsuI0+Vt7kVoE= =e+5l -----END PGP SIGNATURE----- --------------enigA844DA1B0061523182A917CB-- From owner-ietf-pkix@mail.imc.org Mon Feb 3 08:25:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07318 for ; Mon, 3 Feb 2003 08:25:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13Cg7f18946 for ietf-pkix-bks; Mon, 3 Feb 2003 04:42:07 -0800 (PST) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Cg6d18942 for ; Mon, 3 Feb 2003 04:42:06 -0800 (PST) Received: from ofb.nist.gov (ofb.ncsl.nist.gov [129.6.54.187]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h13CfDf2026844; Mon, 3 Feb 2003 07:41:13 -0500 (EST) Message-Id: <5.1.0.14.2.20030203073129.00a2cec0@mail.nist.gov> X-Sender: cjbrown@mail.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Feb 2003 07:41:30 -0500 To: ietf-pkix@imc.org From: Christopher Brown Subject: Update: Progress report: RFC 3280/3281 Interop testing Cc: Tim Polk In-Reply-To: <5.1.0.14.2.20030122102513.01df0f40@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h13Cg6d18943 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit An update on remaining features: At 01:38 PM 01/22/2003 -0500, you wrote: >Folks, > >This message is both a progress report on the RFC 3280 and 3281 testing >and a request for your assistance in completing that testing. > >We are working from a matrix initially developed by Jim Schaad. Chris >Brown here at NIST is performing the certificate and CRL feature testing, >with assistance from Nelson Hastings and David Cooper. We are also >working with DigitalNet (formerly Getronics) and DoD to develop tests for >the path validation algorithm. David Cooper is the NIST lead for that project. > >The certificate and CRL feature testing is largely complete. We have >generated two examples for most features from at least two independent >implementations. However, we need to obtain examples for a few remaining >features. > >The list is appended at the end of this message. The list is divided into >nine certificate fields and 10 CRL "fields", with a number of >subcategories. We are looking for folks that have an implementation which >satisfies these requirements, and can generate some examples for >us. Examples don't need to implement all of the subcategories; examples >that satisfy any one of them are acceptable! > >If you can help, please send email to Chris Brown. I cc'ed him on this >message so that you will all have his email address. Chris will need to >obtain at a minimum the certificate or CRL, but a path associated with the >certificate would be even more helpful. Please specify >which implementation was used to generate the example(s). > >When the path validation tests are complete, we will be looking for >volunteers to execute those tests as well. I will update the list on that >part of the testing once we are ready to go. > >Thanks, > >Tim Polk > > > >------------------------------- remaining features for RFC 3280 and 3281 >---------------------- > >CERTIFICATE FIELD #1: Names (subject or issuer acceptable) > Need one example each for names including the following attributes >a) dNqualifier >b) givenName >c) initials >d) pseudonym >e) generationQualifier > > >CERTIFICATE FIELD #3: SubjectPublicKey >a) DSA public key with parameters omitted >b) elliptic key with parameters present >c) elliptic curve key with NULL parameters (need 1 example: have Entrust) >d) Diffie-Hellman > >CERTIFICATE FIELD #4: Signature field >* ECDSA signature (need 1 example: have Entrust) > >CERTIFICATE FIELD #6: SubjectAltName >a) IPv6 addresses (need 1 example) > >CERTFICATE FIELD #7: CRL distribution points >b) CRLissuer field that has other name form (2 examples) > > >CERTIFICATE FIELD #9: subject information access >a) id-ca-repository and > 1. location is URI > 2. location is DAP > 3. location is rfc822 > >CRL FIELD #1: SignatureAlgorithm >* ECDSA with parameters NULL (1 example ­ have Entrust) > >CRL FIELD #2: Issuer Name >a) Distinguished name qualifier, state or province name, common name, >serial number (1 example ­ have OpenSSL) >b) Locality, title, surname(2 examples), given name, initials, >pseudonym, generation qualifier (1 example ­ have OpenSSL) >c) Use BMPString (2 examples) >d) Use UTF8String (2 examples) > >CRL FIELD #3: This Update >* Date >= 2050, encoded as GeneralizedTime (2 examples) > >CRL FIELD #4: Next Update >* Date >= 2050, encoded as GeneralizedTime (2 examples) > >CRL FIELD #5: Issuer Alternative Name >a) IpV4 address (1 example -- have openSSL) >b) IpV6 address, other name (2 examples) > > >CRL #6: CRL Number >a) Delta and CRLs on the same scope must share one numbering sequence >(1 example ­ have iPlanet) >b) Delta and CRL on same scope issued at same time must have same >number (2 examples) > >CRL #7: Delta Indicator >* (need 2 examples) >a) MUST list as removeFromHold in delta if held since base but now >not held >b) MUST list as removeFromCRL if certificate has expired and was revoked >c) MUST include revoked and expired certificate on delta until it >appears on at least one full CRL >* (1 example ­ have iPlanet) >d) All referenced base CRLs must be full CRLs >e) Delta CRLs MUST contain this extension as crititcal >f) Base and Delta MUST omit CDP or have identical CDPs >g) Use same key for Base and Delta CRLs >h) MUST include cert on delta if status changed since base > >CRL #9: Freshest CRL >* All tests (2 examples) >a) Extension must be non-critical >b) Extension must not be present in delta CRLs >c) Omit reasons and CRLIssuer from extension > >CRL #10: CRL Entry Extensions >a) Hold Instruction Code (1 example ­ have OpenSSL) >b) Certificate Issuer (2 examples) From owner-ietf-pkix@mail.imc.org Mon Feb 3 14:15:13 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17934 for ; Mon, 3 Feb 2003 14:15:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13Iihm07913 for ietf-pkix-bks; Mon, 3 Feb 2003 10:44:43 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Iifd07909 for ; Mon, 3 Feb 2003 10:44:42 -0800 (PST) Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id h13IiXH10043; Mon, 3 Feb 2003 19:44:33 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Mon Feb 3 19:44:33 2003 Subject: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Mon, 3 Feb 2003 19:03:39 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 03.02.2003 19:44:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: While reading the introduction of Peters draft I got the feeling that OCSP is flawed as it is only able to assure the presence of a revocation but not the opposite. I looked up the OCSP specification and found that it delivers three different reponses, with "good" indicating that the certificate is definitely not revoked. Which has to be interpreted as "I have enough information to perform the revocation check, and the check returned not revoked." I understand that "unknown" is indicating that information avaliable is insufficient to decide the question. This, of course, can mean anything. I think that "yes", "no", or "don't know" is a perfect choice of answers for an agent answering the question "is this certificate revoked?. OCSP is not flawed (at least not here). I suggest Peter to review the introduction on this topic to avoid misunderstandings. The main difference between RTCS and standard OCSP is that RTCS is answering a different question and thus is providing different information. It is a white list check and a black list check. It answers the question "Is this certificate issued correctly AND not revoked ?" The most specific answer here is "yes" which means that the certificate is known in the cert repository and there is no revocation indication present. In the short form of the response "no" is ambigous. It can mean 1. that the cert is not in the repository (but should be there, indication of a CA key compromise, cert invalid), 2. the cert is in the repository and marked as revoked (cert invalid), or 3. the repository to look at is not available to the responder (cert state unknown, maybe valid, ask someone else). Looking at the available list of responses in the extended RTCS Response, I cannot map the response codes given there directly to the listed cases. The first and third case map to StatusUnknown, the second case to StatusRevoked. I suggest to provide more response codes to have a one-on-one mapping of the different cases to codes. The debate will probably continue on the topic "Do we really need a white list check?". In the common PKIX (and X.509) paradigm "CA key security is perfect" the answer probably is "no". A certificate carrying a signature of a trusted CA is valid, no need to ask the CA again. In Germany the german signature law is identifying a fourth case: 4. the cert is in the repository, but not active yet (cert invalid, maybe valid in the future) This case is required (by law) if a CA issues not only certificates but private keys as well to the end user. Think of a bank producing and delivering a smartcard with keys and certificates on it to you. As long as you did not confirm the receipt of the card to the CA the CA must protect you by having the certificate "on hold" so during transport no valid signatures can be created. This may be handled by an "onHold" status on a CRL but is currently deployed in Germany using white list technology. The second reason why german electronic signature technology is requiring a white list check is another obligation by law, namely that it is not allowed to render correctly issued user certificates invalid due to a CA key compromise (or any other kind of CA ceases operation). This is again achieved with white list technology and status information signed by a key with independent security. RTCS would fit well in here. pgut001@cs.auckla nd.ac.nz (Peter An: Denis.Pinkas@bull.net, pgut001@cs.auckland.ac.nz Gutmann) Kopie: anders.rundgren@telia.com, ietf-pkix@imc.org, kent@bbn.com Gesendet von: Thema: Re: Real-time Certificate Status Facility for OCSP - (RTCS) owner-ietf-pkix@m ail.imc.org 31.01.2003 10:51 [A bit of a flame, sorry folks] Denis Pinkas writes: >"invalid without being revoked" does not mean anything. So you're saying the only way a certificate can ever be regarded as invalid is if it's formally revoked by a CA? >>and can be valid but OCSP can't tell you that because it can only say "not >>revoked", which doesn't mean "valid" - see the endless debate on this over the >>years). > >There is no such an endless debate, except from your side. Anyone who bothers to search the PKIX archives can see how accurate Denis' claims are. (It's amazing you can even make such a claim, when anyone who's been on the PKIX list for more than a few months has seen the OCSP-status debate crop up at least once. You've even taken part in them yourself... a 30-second search of the archives dug up: Subject: Re: German Law and OCSP From: Denis Pinkas Date: Thu, 10 Feb 2000 16:59:24 +0100 as one example (I don't have the '01 archives becuase they're too big, that was the last one from '00)). >[Blah blah blah, lots more bogus whining and moaning] for example: Because the hash of a certificate is not included in the CRL, so using CRLs only would not be possible. and then right after it you quote the very text which refutes your claim: > memcpy( response.certHash, request.certHash, 20 ); and so on and so on. Look, I'm sorry, but you're grasping at any available (or imaginary) straw here in an attempt to criticse RTCS. It's obvious from your messages (and others have commented on this as well) that you've barely read the RTCS draft (if at all), and even then only to pick out bits to complain about. The posting of obviously incorrect claims such as the ones cited above aren't helping your credibility much either. It's simply a waste of time me even responding to stuff like this - the excerpt above shows that not only have you barely read RTCS, you're not reading the replies either, except to pick out bits to criticise. In the meantime I welcome intelligent debate with anyone else (the cert-HTTP draft has been considerably improved by recent user feedback). Peter. From owner-ietf-pkix@mail.imc.org Tue Feb 4 05:23:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15182 for ; Tue, 4 Feb 2003 05:23:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h149oWU21533 for ietf-pkix-bks; Tue, 4 Feb 2003 01:50:32 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h149oUd21524 for ; Tue, 4 Feb 2003 01:50:30 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 1EC6110F715; Tue, 4 Feb 2003 10:50:21 +0100 (CET) From: "Simon Tardell" To: , "'Peter Gutmann'" Cc: Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Tue, 4 Feb 2003 10:50:12 +0100 Message-ID: <052c01c2cc32$cfc76ea0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The second reason why german electronic signature technology > is requiring a white list check is another obligation by law, > namely that it is not allowed to render correctly issued user > certificates invalid due to a CA key compromise (or any other > kind of CA ceases operation). This is again achieved with > white list technology and status information signed by a key > with independent security. RTCS would fit well in here. Ah, yes, the German OCSP-turned-into-a-certificate-notary. Too late to change, but if you back up a bit isn't the problem that you don't want the EE *keys* rendered useless by a CA key compromise? That is perfectly valid concern: The EE keys are not compromised themselves, just the binding to the identity (through the CA key compromise). Reissuing smart cards, especially loads of them, is painfull and takes time, not to say costs a lot of money. A simple solution that would not have mandated inventing a new protocol ("German OCSP") that is uninteroperable with just anything else would have been to mandate that each EE key be certified with at least two independent CAs. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Tue Feb 4 21:28:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11597 for ; Tue, 4 Feb 2003 21:28:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1524lK04719 for ietf-pkix-bks; Tue, 4 Feb 2003 18:04:47 -0800 (PST) Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1524kd04715 for ; Tue, 4 Feb 2003 18:04:46 -0800 (PST) Received: from [10.5.14.21] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04089; Tue, 4 Feb 2003 21:04:51 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 4 Feb 2003 21:02:31 -0500 To: Olaf.Schlueter@secartis.com From: Stephen Kent Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, > > >In Germany the german signature law is identifying a fourth case: > >4. the cert is in the repository, but not active yet (cert invalid, maybe >valid in the future) > >This case is required (by law) if a CA issues not only certificates but >private keys as well to the end user. Think of a bank producing and >delivering a smartcard with keys and certificates on it to you. As long as >you did not confirm the receipt of the card to the CA the CA must protect >you by having the certificate "on hold" so during transport no valid >signatures can be created. This may be handled by an "onHold" status on a >CRL but is currently deployed in Germany using white list technology. This seems an unnecessary complication. The CA could simply wait to post the cert to a directory until the user acknowledges receipt. I'm not in favor of adding complexity when there are other, simpler solutions to a problem. >The second reason why german electronic signature technology is requiring a >white list check is another obligation by law, namely that it is not >allowed to render correctly issued user certificates invalid due to a CA >key compromise (or any other kind of CA ceases operation). This is again >achieved with white list technology and status information signed by a key >with independent security. RTCS would fit well in here. My response to Simon addresses this issue, i.e., German law seems to have mandated a solution to a problem that is not technically justified, given the alternatives. PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised. Steve From owner-ietf-pkix@mail.imc.org Tue Feb 4 21:28:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11598 for ; Tue, 4 Feb 2003 21:28:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1524JD04699 for ietf-pkix-bks; Tue, 4 Feb 2003 18:04:19 -0800 (PST) Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1524Bd04692 for ; Tue, 4 Feb 2003 18:04:17 -0800 (PST) Received: from [10.5.14.21] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04067; Tue, 4 Feb 2003 21:03:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <052c01c2cc32$cfc76ea0$0a01a8c0@stl> References: <052c01c2cc32$cfc76ea0$0a01a8c0@stl> Date: Tue, 4 Feb 2003 21:01:35 -0500 To: "Simon Tardell" From: Stephen Kent Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: , "'Peter Gutmann'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:50 AM +0100 2/4/03, Simon Tardell wrote: > > The second reason why german electronic signature technology >> is requiring a white list check is another obligation by law, >> namely that it is not allowed to render correctly issued user >> certificates invalid due to a CA key compromise (or any other >> kind of CA ceases operation). This is again achieved with >> white list technology and status information signed by a key >> with independent security. RTCS would fit well in here. > >Ah, yes, the German OCSP-turned-into-a-certificate-notary. Too late to >change, but if you back up a bit isn't the problem that you don't want >the EE *keys* rendered useless by a CA key compromise? That is perfectly >valid concern: The EE keys are not compromised themselves, just the >binding to the identity (through the CA key compromise). Reissuing smart >cards, especially loads of them, is painfull and takes time, not to say >costs a lot of money. > >A simple solution that would not have mandated inventing a new protocol >("German OCSP") that is uninteroperable with just anything else would >have been to mandate that each EE key be certified with at least two >independent CAs. > There are many ways to address the concerns raised by CA key compromise. Relying on a secure directory to confirm the validity of an EE cert (not keys) is one approach, but too often it seems to be based on a very questionable assumption, i.e., that by using two authorities (the CA and the directory operator) and two keys to verify cert status, that this is necessarily more secure that relying on the CA only. Thios overlooks the possibility that the CA uses multi-party controls for its keys, e.g., analogous to the way that SetCo did for the SET root CA. Mandating use of a secure directory is only one possible way of addressing a valid concern, and to codify this approach as THE solution is unjustifiable. Steve From owner-ietf-pkix@mail.imc.org Wed Feb 5 03:52:17 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14652 for ; Wed, 5 Feb 2003 03:52:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h158Tr201415 for ietf-pkix-bks; Wed, 5 Feb 2003 00:29:53 -0800 (PST) Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h158Tod01404 for ; Wed, 5 Feb 2003 00:29:51 -0800 (PST) Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id h158d6805951; Wed, 5 Feb 2003 09:39:06 +0100 (MET) Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAACYaWNl; Wed, 5 Feb 03 09:39:05 +0100 Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h158Tdw18900; Wed, 5 Feb 2003 09:29:40 +0100 (MET) Message-ID: <3E40CB73.2FB94FDF@trustcenter.de> Date: Wed, 05 Feb 2003 09:29:39 +0100 From: Juergen Brauckmann Organization: TC TrustCenter AG X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Olaf.Schlueter@secartis.com CC: ietf-pkix@imc.org Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Olaf.Schlueter@secartis.com wrote: > In Germany the german signature law is identifying a fourth case: Just a short note: All these issues with the German Signature Law "only" relate to qualified certificates. > 4. the cert is in the repository, but not active yet (cert invalid, maybe > valid in the future) > > This case is required (by law) if a CA issues not only certificates but > private keys as well to the end user. Think of a bank producing and > delivering a smartcard with keys and certificates on it to you. [...] > This may be handled by an "onHold" status on a > CRL but is currently deployed in Germany using white list technology. Or by simply not publishing it. Otherwise you will get a somewhat oversized CRL if your bank decides to issue 2 million new banking cards, all with "on hold" certificates. Makes validation a little bit slower than normal :-) Juergen From owner-ietf-pkix@mail.imc.org Wed Feb 5 08:48:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24965 for ; Wed, 5 Feb 2003 08:48:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15DBk803204 for ietf-pkix-bks; Wed, 5 Feb 2003 05:11:46 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15DBid03200; Wed, 5 Feb 2003 05:11:44 -0800 (PST) Received: by fw1.gdm.de (8.11.6/8.11.6) id h15DBVS13616; Wed, 5 Feb 2003 14:11:31 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Wed Feb 5 14:11:31 2003 Subject: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Stephen Kent Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, pgut001@cs.auckland.ac.nz (Peter Gutmann) X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Wed, 5 Feb 2003 12:54:41 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 05.02.2003 14:11:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, >> >> >>In Germany the german signature law is identifying a fourth case: >> >>4. the cert is in the repository, but not active yet (cert invalid, maybe >>valid in the future) >> >>This case is required (by law) if a CA issues not only certificates but >>private keys as well to the end user. Think of a bank producing and >>delivering a smartcard with keys and certificates on it to you. As long as >>you did not confirm the receipt of the card to the CA the CA must protect >>you by having the certificate "on hold" so during transport no valid >>signatures can be created. This may be handled by an "onHold" status on a >>CRL but is currently deployed in Germany using white list technology. >This seems an unnecessary complication. The CA could simply wait to >post the cert to a directory until the user acknowledges receipt. >I'm not in favor of adding complexity when there are other, simpler >solutions to a problem. To withhold the certificate from the directory is exactly the solution that is applied by existing service providers currently. But that means that RPs are forced to check the existance of a given certificate in the directory to examine validity of a signature, i.e. a white-list check. This is in compliance with the law (great) but not with PKIX (uups). Currently OCSP (the german style) is used to perform that check. And I agree that RFC OCSP has not been built for that. We (i.e. those people that discussed which specifications to go for to implement law-compliant PKIs) adopted OCSP as a solution to this problem while it was in draft. And we totally missed the basic idea that OCSP should be a responder capable of working on CRLs alone. We interpreted it as a white-list service from the very beginning. When the draft was finished and promoted to an RFC we had to realize that we created something different. Peters RTCS in its current shape would deliver the needed functionality as well. I understand your suggestion as setting up an LDAP-directory that allows queries for matches for a given certificate. That would be an alternative and simple way to implement a white-list, but it would still be a white-list. (Issues like obtaining trust into the response of the directory and obtaining information on the point in time the certificate was inserted into the directory have still to be resolved.) And white-list checks are IMHO not in compliance with PKIX path validation. We would love to see someone demonstrating to us that the legal obligations already explained maybe implemented one way or the other in compliance with PKIX. From owner-ietf-pkix@mail.imc.org Wed Feb 5 09:20:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26224 for ; Wed, 5 Feb 2003 09:20:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15DoZT06567 for ietf-pkix-bks; Wed, 5 Feb 2003 05:50:35 -0800 (PST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15DoYd06561 for ; Wed, 5 Feb 2003 05:50:34 -0800 (PST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h15DmR3k008686; Wed, 5 Feb 2003 05:48:27 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Feb 2003 05:50:19 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Stephen Kent'" , Olaf.Schlueter@secartis.com Cc: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Wed, 5 Feb 2003 05:50:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C2CCF3.9A89DA40" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2CCF3.9A89DA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > My response to Simon addresses this issue, i.e., German law seems to > have mandated a solution to a problem that is not technically > justified, given the alternatives. PKIX is not in the habit of > setting standards to accommodate national level laws that may be ill > advised. It seems somewhat unusual to see a national law mandate a particular technology. Legislators are usually anxious to avoid specifying implementations. The statement 'we must do X' is preceeded by a requirement. So what is it that the law actually says, does it really say you must do X or does it actually specify the requirements? The OnHold requirement appears to me to be an authorization requirement, not an authentication requirement. It is in any case possible to address the requirement in other ways. The CA compromise requirement is somewhat strange. If a CA key is compromised the end entity certs signed under that key are compromised. I don't think that OCSP is going to help since the signing key of the OCSP responder would normally chain to the same root - unless we are going to deploy a second set of roots of trust. Furthermore which CA key are we talking about here? The root of trust or the intermediate CA that signs the end entity certificate? If the root of trust is compromised but not the intermediate you simply sign yourself a new root of trust. If the intermediate is compromised the end entity cert is compromised regardless of what opinion German law might have or appear to have on the matter. Phil ------=_NextPart_000_0000_01C2CCF3.9A89DA40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIwNTEz NTAxNlowIwYJKoZIhvcNAQkEMRYEFBYTB+9KzqZaISpIKw8eVPsDYOUBMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAoe7/bUiunJgS/taV6yiLU7Ldpdaat6nusHdg5iPQQ2ae0rfG Sj+31YATA/JSp5fqcJcqlXzV4+l/FLgU6kh4b2WS0VoVzW5ie7nh3Y1lCf/W3c6TpWQtuxLLO3nn ji57CJZxDxbct8zsqkVZzeHYn/FlCLQjFvevNfQsFehJ2SoAAAAAAAA= ------=_NextPart_000_0000_01C2CCF3.9A89DA40-- From owner-ietf-pkix@mail.imc.org Wed Feb 5 11:12:08 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29830 for ; Wed, 5 Feb 2003 11:12:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15FcfA14288 for ietf-pkix-bks; Wed, 5 Feb 2003 07:38:41 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15Fcdd14284 for ; Wed, 5 Feb 2003 07:38:40 -0800 (PST) Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Stephen Kent Cc: ietf-pkix@imc.org, Olaf.Schlueter@secartis.com, pgut001@cs.auckland.ac.nz (Peter Gutmann) X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 5 Feb 2003 08:37:46 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/05/2003 10:40:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: i would claim in order to activate a digital signature, that the user needs to perform the RA function ... sending a signed message ... nominally containing a copy of the public key and some other identification information ... and this needs to be done regardless of whether the private kye originates with the user or is pushed out to the user. in the pre-push case, just because a private key push agency .... also acting as a CA, happens to pre-push a copy of the certificate prior to the RA function is an anomoly of the process. in effect, what binds/activiates the digital signature process is the RA operation .... not the certificate .... the existance of a certificate is an implementation anomoly of the overall business process. my bias has always been that the digital signature binding process is represented by the binding in the RA process .... independent of any existance of a certificate used in scenarios for trusted key distribution for offline environments ... aka the RA binding for the digital signature proccess is independent of the existance of a certificate as one means of representing that the RA business process has occured. in my AADS claims, online metthods of indicating that valid RA process has been satisfied can be superior to generation of certificates as a representation of a valid RA business process. I would claim that the direct equating of certificates to valid digital signatures contributes to the confusion. the RA binding process is what is used for establishing the basis for valid digital signatures. certificates (should be) just one method of representing that such a RA binding business process has occured. The confusion isn't that an agency can generate a private key and a certificate and push both out to the end user .... the confusion is the automatic acceptance that because a certificate exists ... it is equivalent to a valid digital signature binding process; the certificate should be just considered one way of representing a RA-binding process having been performaned. of course, random refs: http://www.garlic.com/~lynn/index.html#aads as noted in other recent threads there is sometimes confusion of asymmetric cryptography with the business processes of information hiding/secrecy and the business process of digital signature authentication. frequently for digital signatures, the business process may require that the private key never be known by anybody (and can only exist in a unique hardware token) .... while at the same time information hiding/secrecy will require private keys be escrowed (access to valuable corporate assets only accessable via a specific private key will mandate escrow for business continuity purposes). the technology is the same in both business processes .... but there are different secrecy requirements with regard to the treatment of the private key. asymmetric crypto vis-a-vis public key business process ... hiding/secrecy and authentication/digital signature: http://www.garlic.com/~lynn/2001g.html#14 Public key newbie question http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure) http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family? http://www.garlic.com/~lynn/2002i.html#78 Does Diffie-Hellman schema belong to Public Key schema family? http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ? http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision http://www.garlic.com/~lynn/2003b.html#30 Public key encryption http://www.garlic.com/~lynn/2003b.html#41 Public key encryption http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for use with Outlook -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm kent@bbn.com on 2/4/2003 7:02 pm wrote: Olaf, > > >In Germany the german signature law is identifying a fourth case: > >4. the cert is in the repository, but not active yet (cert invalid, maybe >valid in the future) > >This case is required (by law) if a CA issues not only certificates but >private keys as well to the end user. Think of a bank producing and >delivering a smartcard with keys and certificates on it to you. As long as >you did not confirm the receipt of the card to the CA the CA must protect >you by having the certificate "on hold" so during transport no valid >signatures can be created. This may be handled by an "onHold" status on a >CRL but is currently deployed in Germany using white list technology. This seems an unnecessary complication. The CA could simply wait to post the cert to a directory until the user acknowledges receipt. I'm not in favor of adding complexity when there are other, simpler solutions to a problem. >The second reason why german electronic signature technology is requiring a >white list check is another obligation by law, namely that it is not >allowed to render correctly issued user certificates invalid due to a CA >key compromise (or any other kind of CA ceases operation). This is again >achieved with white list technology and status information signed by a key >with independent security. RTCS would fit well in here. My response to Simon addresses this issue, i.e., German law seems to have mandated a solution to a problem that is not technically justified, given the alternatives. PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised. Steve From owner-ietf-pkix@mail.imc.org Thu Feb 6 04:40:50 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10060 for ; Thu, 6 Feb 2003 04:40:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h168qgV09730 for ietf-pkix-bks; Thu, 6 Feb 2003 00:52:42 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h168qed09715 for ; Thu, 6 Feb 2003 00:52:40 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA22458; Thu, 6 Feb 2003 09:54:39 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id IAA05893; Thu, 6 Feb 2003 08:46:13 +0100 Message-ID: <3E4221A1.10705@bull.net> Date: Thu, 06 Feb 2003 09:49:37 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Olaf.Schlueter@secartis.com CC: Stephen Kent , ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit See comments at the end. > Olaf, >>> >>>In Germany the german signature law is identifying a fourth case: >>> >>>4. the cert is in the repository, but not active yet (cert invalid, maybe >>>valid in the future) >>> >>>This case is required (by law) if a CA issues not only certificates but >>>private keys as well to the end user. Think of a bank producing and >>>delivering a smartcard with keys and certificates on it to you. As long >> > as > >>>you did not confirm the receipt of the card to the CA the CA must protect >>>you by having the certificate "on hold" so during transport no valid >>>signatures can be created. This may be handled by an "onHold" status on a >>>CRL but is currently deployed in Germany using white list technology. >> > >>This seems an unnecessary complication. The CA could simply wait to >>post the cert to a directory until the user acknowledges receipt. >>I'm not in favor of adding complexity when there are other, simpler >>solutions to a problem. > > > To withhold the certificate from the directory is exactly the solution that > is applied by existing service providers currently. But that means that RPs > are forced to check the existance of a given certificate in the directory > to examine validity of a signature, i.e. a white-list check. This is in > compliance with the law (great) but not with PKIX (uups). > > Currently OCSP (the german style) is used to perform that check. And I > agree that RFC OCSP has not been built for that. We (i.e. those people > that discussed which specifications to go for to implement law-compliant > PKIs) adopted OCSP as a solution to this problem while it was in draft. And > we totally missed the basic idea that OCSP should be a responder capable of > working on CRLs alone. We interpreted it as a white-list service from the > very beginning. When the draft was finished and promoted to an RFC we had > to realize that we created something different. Peters RTCS in its current > shape would deliver the needed functionality as well. > > I understand your suggestion as setting up an LDAP-directory that allows > queries for matches for a given certificate. That would be an alternative > and simple way to implement a white-list, but it would still be a > white-list. (Issues like obtaining trust into the response of the directory > and obtaining information on the point in time the certificate was inserted > into the directory have still to be resolved.) And white-list checks are > IMHO not in compliance with PKIX path validation. This is correct. > We would love to see > someone demonstrating to us that the legal obligations already explained > maybe implemented one way or the other in compliance with PKIX. As Steve already mentioned, "PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised". There is indeed a real technical problem in case of a CA key compromise, but the German Law mandates a solution whereas it should have stated requirements only, instead of a technical solution. There exists a solution to the problem, but of course it cannot fit with the current text from the German Law: a few sentences from the German Law should be changed. Denis From owner-ietf-pkix@mail.imc.org Thu Feb 6 07:06:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14907 for ; Thu, 6 Feb 2003 07:06:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16BbvN26541 for ietf-pkix-bks; Thu, 6 Feb 2003 03:37:57 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Bbtd26531 for ; Thu, 6 Feb 2003 03:37:55 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 0104610F8F0; Thu, 6 Feb 2003 12:37:49 +0100 (CET) From: "Simon Tardell" To: , "'Peter Gutmann'" Cc: Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Thu, 6 Feb 2003 12:37:24 +0100 Message-ID: <00a601c2cdd4$1e51bfb0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 4. the cert is in the repository, but not active yet (cert > invalid, maybe valid in the future) My interpretation that the problem that you try to cover for here is if the card AND the PIN code envelope both gets lost en route from the issuer to the intended end issuer, the card should not be usable. Well, why not issue the certs after the card has been (in a trusted manner) been delivered to the intended recipient? Again, it obviates the need for a custom design protocol. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Thu Feb 6 07:07:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14948 for ; Thu, 6 Feb 2003 07:07:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16BUEN26371 for ietf-pkix-bks; Thu, 6 Feb 2003 03:30:14 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16BUBd26366 for ; Thu, 6 Feb 2003 03:30:12 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 92AE910F8F0; Thu, 6 Feb 2003 12:30:03 +0100 (CET) From: "Simon Tardell" To: "'Hallam-Baker, Phillip'" , "'Stephen Kent'" , Cc: , Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Thu, 6 Feb 2003 12:29:41 +0100 Message-ID: <009e01c2cdd3$0a5d37b0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit > The CA compromise requirement is somewhat strange. If a CA key is > compromised the end entity certs signed under that key are > compromised. I don't think that OCSP is going to help since > the signing key of the OCSP responder would normally chain to > the same root - unless we are going to deploy a second set of > roots of trust. > > Furthermore which CA key are we talking about here? The root > of trust or the intermediate CA that signs the end entity certificate? The CA that signs the EE certs. > If the root of trust is compromised but not the intermediate > you simply sign yourself a new root of trust. If the > intermediate is compromised the end entity cert is > compromised regardless of what opinion German law might have > or appear to have on the matter. "German OCSP", that is OCSP as modified by the SigI (German industry interoperability specification for systems based on SigG/V) is not just a revocation responder answering on delegation for the CA. It is an independent notary. That is, it vouches for that the certificate existed at a certain point in time. It is also independent from the CA it answers for. It does indeed solve the problem, but at the cost of inventing mechanism and protocols that the rest of the world does not know about. I have my doubts of the actual robustness of the solution as well. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Thu Feb 6 07:28:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15496 for ; Thu, 6 Feb 2003 07:28:43 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16Bwba27229 for ietf-pkix-bks; Thu, 6 Feb 2003 03:58:37 -0800 (PST) Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16BwYd27225 for ; Thu, 6 Feb 2003 03:58:35 -0800 (PST) Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id H9VYML03.ALI for ; Thu, 6 Feb 2003 12:59:09 +0100 Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15 gibson Mar 14 2002 21:29:48) with ESMTP id H9VYNH00.Y8T for ; Thu, 6 Feb 2003 12:59:41 +0100 Subject: Path validation decision based on notAfter To: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: luciano.medina@safelayer.com Date: Fri, 7 Feb 2003 13:00:30 +0100 X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.9a |January 7, 2002) at 07/02/2003 13:00:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is it legal for a certificate to have a longer validity period than its CA certificate? In other words: Should not a path validation algorithm (according to RFC 3280) reject an alleged CA certificate if its notAfter value is lower than the one in the certificate (supposedly) issued by it? The standard does not say a word about it, but I think it is quite reasonable to include this condition in the path validation algorithm. Unless I am missing something and there are cases (cross-certification maybe?) where it is necessary to allow such certification chains. Luciano Medina From owner-ietf-pkix@mail.imc.org Thu Feb 6 07:42:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15984 for ; Thu, 6 Feb 2003 07:42:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16C9Bp27584 for ietf-pkix-bks; Thu, 6 Feb 2003 04:09:11 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16C98d27580 for ; Thu, 6 Feb 2003 04:09:09 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id FAA24864; Tue, 11 Feb 2003 05:46:45 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h16C8u930317; Thu, 6 Feb 2003 13:08:56 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E425055.9020804@authentidate.de> Date: Thu, 06 Feb 2003 13:08:53 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Denis Pinkas , Olaf.Schlueter@secartis.com CC: Stephen Kent , ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <6667697.1044528058081.JavaMail.root@email.authentidate.de> In-Reply-To: <6667697.1044528058081.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h16C99d27581 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Denis, Olaf, et al., > As Steve already mentioned, "PKIX is not in the habit of setting standards > to accommodate national level laws that may be ill advised". > > There is indeed a real technical problem in case of a CA key compromise, > but the German Law mandates a solution whereas it should have stated > requirements only, instead of a technical solution. There exists a solution > to the problem, but of course it cannot fit with the current text from > the German Law: a few sentences from the German Law should be changed. Please do not take the following as an offence, I am really asking open minded and with the fact in mind, that I may not have read the German law thouroughly enough: Where do you think the German law does mandate a technical solution? (Olaf seems to state this and Denis even shrinks it to a few sentences.) From my point of view the most important difference between certificate handling conformant to German Electronic Siganture Act (SigG in short) and PKIX (even X.509) is the requirement that an EE cert may not be affected by the revocation of a CA cert. This is not even formulated literally within the law's text. It is a conclusion from such a formulation. To make this clear, I would like to cite it (§ 19, (5) SigG): "Die Gültigkeit der von einem Zertifizierungsdiensteanbieter ausgestellten qualifizierten Zertifikate bleibt von der Untersagung des Betriebes und der Einstellung der Tätigkeit sowie der Rücknahme und dem Widerruf einer Akkreditierung unberührt." I try my best to translate it (without adding or dropping anything): "The validity of those qualified certificates issued by a certificate authority is not affected by the interdiction of the business of this certificate authority nor by the closing of it nor by the revocation of its accreditation." This sentence resides within the context of §19, which defines the power of the national root authority (RegTP) over local certification authorities. This paragraph is intended to give RegTP the power (among other empowerments mentioned there) to close a CA if good reasons justify this. It also describes the consequences from this. Is it this, what you are referencing (Denis?, Olaf?). From my point of view there is no technical requirement in there. But yes, some can be concluded from this. For instance, §19, (5) SigG indirectly means: the CA certs will be revoked by the RegTP when (for instance) there exists strong evidence that a CA did not perform their operations trustworthy enough, but the EE certs will not be revoked. This obviously creates the need for the ability to validate EE certificates after CA certificates have been revoked. BUT: Neither SigG nor any ordinance related to it (as far as I know them -- I am no lawyer!) mandate any technical implementation how to achieve this. The currently deployed technical implementation is the validity model called "chain model", which fulfills the above requirement by demanding a white list check for certificates as well. SigG requires the CA to archive a lot of documentation securely whenever they issue a certificate. These can be used to reconstruct the white list (and put it on line protected by another CA key) when a CA key gets revoked. BUT: It could have been deployed differently (and perhaps it will at some point in time). I am convinced that other models like EE certs signed by two independent CAs could fit as well. Kind regards, Torsten P.S.: As far as I understand it, §19 (5) SigG was written this way under the vision to ease the creation of non repudation style signatures for end entities by the cost of making life a little harder for CAs and validation software providers: When EEs use qualified certifiactes, they are asured, they have the control, at what time their certificate becomes invalid (either because they lost their smart card or because they revoke it). This way they can digitally sign contracts without the fear, that their signature becomes invalid by an accident they did not cause (key compromise of a CA). I suspect, this way the need should be eleminated, that with PKIX digitally signed contracts need to be archived by an entrusted third party, which guarantees to bring the non repudiateable proof at any point in the future, that the signature has been valid at a special point in time. -- Torsten Hentschel [The positions described above are not neccessarily those of my employer.] From owner-ietf-pkix@mail.imc.org Thu Feb 6 07:49:53 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16184 for ; Thu, 6 Feb 2003 07:49:53 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16CMFl28210 for ietf-pkix-bks; Thu, 6 Feb 2003 04:22:15 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16CMDd28206 for ; Thu, 6 Feb 2003 04:22:13 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA09496; Thu, 6 Feb 2003 13:24:15 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA07291; Thu, 6 Feb 2003 12:15:43 +0100 Message-ID: <3E4252BB.1090202@bull.net> Date: Thu, 06 Feb 2003 13:19:07 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Torsten Hentschel CC: Olaf.Schlueter@secartis.com, Stephen Kent , ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <6667697.1044528058081.JavaMail.root@email.authentidate.de> <3E425055.9020804@authentidate.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h16CMEd28207 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Torsten, > Hi Denis, Olaf, et al., > >> As Steve already mentioned, "PKIX is not in the habit of setting >> standards >> to accommodate national level laws that may be ill advised". >> >> There is indeed a real technical problem in case of a CA key compromise, >> but the German Law mandates a solution whereas it should have stated >> requirements only, instead of a technical solution. There exists a >> solution >> to the problem, but of course it cannot fit with the current text from >> the German Law: a few sentences from the German Law should be changed. > > Please do not take the following as an offence, I am really asking > open minded and with the fact in mind, that I may not have read > the German law thouroughly enough: This is fine. > Where do you think the German law does mandate a technical solution? > (Olaf seems to state this and Denis even shrinks it to a few sentences.) I have already spent (too) much time on this issue. This list is to discuss PKIX issues, not to fix the German Law which is currently based on a model which is incompatible both with PKIX and X.509. Let us leave the bandwith of this list for other topics. Denis > From my point of view the most important difference between certificate > handling conformant to German Electronic Siganture Act (SigG in short) > and PKIX (even X.509) is the requirement that an EE cert may not be > affected by the revocation of a CA cert. This is not even > formulated literally within the law's text. It is a conclusion from > such a formulation. To make this clear, I would like to cite it > (§ 19, (5) SigG): "Die Gültigkeit der von einem > Zertifizierungsdiensteanbieter ausgestellten > qualifizierten Zertifikate bleibt von der Untersagung des Betriebes > und der Einstellung der Tätigkeit sowie der Rücknahme und dem Widerruf > einer Akkreditierung unberührt." I try my best to translate it > (without adding or dropping anything): "The validity of those > qualified certificates issued by a certificate authority > is not affected by the interdiction of the business of this > certificate authority nor by the closing of it nor by the > revocation of its accreditation." > This sentence resides within the context of §19, which > defines the power of the national root authority (RegTP) over > local certification authorities. This paragraph is intended > to give RegTP the power (among other empowerments mentioned > there) to close a CA if good reasons justify this. > It also describes the consequences from this. > > Is it this, what you are referencing (Denis?, Olaf?). > > From my point of view there is no technical requirement in there. > But yes, some can be concluded from this. For instance, > §19, (5) SigG indirectly means: the CA certs will be revoked > by the RegTP when (for instance) there exists strong evidence > that a CA did not perform their operations trustworthy enough, > but the EE certs will not be revoked. This obviously creates > the need for the ability to validate EE certificates > after CA certificates have been revoked. > > BUT: Neither SigG nor any ordinance related to it (as far > as I know them -- I am no lawyer!) mandate > any technical implementation how to achieve this. > > The currently deployed technical implementation is the validity > model called "chain model", which fulfills the above requirement > by demanding a white list check for certificates as well. > SigG requires the CA to archive a lot of documentation > securely whenever they issue a certificate. These can be used > to reconstruct the white list (and put it on line protected by > another CA key) when a CA key gets revoked. > > BUT: It could have been deployed differently (and perhaps it > will at some point in time). I am convinced that other models > like EE certs signed by two independent CAs could fit as well. > > Kind regards, > > Torsten > > P.S.: As far as I understand it, §19 (5) SigG was written this way > under the vision to ease the creation of non repudation style > signatures for end entities by the cost of making life a little > harder for CAs and validation software providers: When EEs use > qualified certifiactes, they are asured, they have the control, > at what time their certificate becomes invalid (either because > they lost their smart card or because they revoke it). This way > they can digitally sign contracts without the fear, that their > signature becomes invalid by an accident they did not cause > (key compromise of a CA). I suspect, this way the need should > be eleminated, that with PKIX digitally signed contracts need to > be archived by an entrusted third party, which guarantees to > bring the non repudiateable proof at any point in the future, > that the signature has been valid at a special point in time. > From owner-ietf-pkix@mail.imc.org Thu Feb 6 08:58:25 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17933 for ; Thu, 6 Feb 2003 08:58:24 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16DNl505675 for ietf-pkix-bks; Thu, 6 Feb 2003 05:23:47 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16DNid05670 for ; Thu, 6 Feb 2003 05:23:45 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA38192; Thu, 6 Feb 2003 14:25:27 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id NAA07678; Thu, 6 Feb 2003 13:17:21 +0100 Message-ID: <3E42612D.9030104@bull.net> Date: Thu, 06 Feb 2003 14:20:45 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: luciano.medina@safelayer.com CC: ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Luciano, > Is it legal for a certificate to have a longer validity period than its CA > certificate? In other words: Should not a path validation algorithm > (according to RFC 3280) reject an alleged CA certificate if its notAfter > value is lower than the one in the certificate (supposedly) issued by it? > The standard does not say a word about it, Extract from RFC 3280: 6.1.3 Basic Certificate Processing The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below. (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: (snip) (2) The certificate validity period includes the current time. Denis > but I think it is quite > reasonable to include this condition in the path validation algorithm. > Unless I am missing something and there are cases (cross-certification > maybe?) where it is necessary to allow such certification chains. > > Luciano Medina From owner-ietf-pkix@mail.imc.org Thu Feb 6 09:39:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19497 for ; Thu, 6 Feb 2003 09:39:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16ECZZ11261 for ietf-pkix-bks; Thu, 6 Feb 2003 06:12:35 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16ECXd11257 for ; Thu, 6 Feb 2003 06:12:33 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id HAA32283; Tue, 11 Feb 2003 07:50:20 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h16ECX931610; Thu, 6 Feb 2003 15:12:33 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E426D4D.1050707@authentidate.de> Date: Thu, 06 Feb 2003 15:12:29 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Denis Pinkas CC: Olaf.Schlueter@secartis.com, ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <6667697.1044528058081.JavaMail.root@email.authentidate.de> <3E425055.9020804@authentidate.de> <3910009.1044538746500.JavaMail.root@email.authentidate.de> In-Reply-To: <3910009.1044538746500.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Denis, >> Please do not take the following as an offence, I am really asking >> open minded and with the fact in mind, that I may not have read >> the German law thouroughly enough: > > > This is fine. > >> Where do you think the German law does mandate a technical solution? >> (Olaf seems to state this and Denis even shrinks it to a few sentences.) > > > I have already spent (too) much time on this issue. Wouldn't have expected that. 8-/ > This list is to > discuss PKIX issues, not to fix the German Law which is currently based > on a model which is incompatible both with PKIX and X.509. > Let us leave the bandwith of this list for other topics. Here I disagree. Again: it is not the law, it may be an implementation that is not in all points compatible. (Sometimes the implementation used by RegTP (Germany's root CA) is mixed with "requirements enforced by law".) As this is the PKIX list: Why shouldn't it be discussed here, how the current implementations in Germany do use and profile PKIX to be compatible to PKIX to the extent they can and where they are not. "Looking over the border" sometimes helps improving, doesn't it? Regards, Torsten -- Torsten Hentschel [Positions outlined by me above are not neccessarily those of my employer.] From owner-ietf-pkix@mail.imc.org Thu Feb 6 09:57:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20177 for ; Thu, 6 Feb 2003 09:57:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16EXej11867 for ietf-pkix-bks; Thu, 6 Feb 2003 06:33:40 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16EXdd11863 for ; Thu, 6 Feb 2003 06:33:39 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19072; Thu, 6 Feb 2003 09:30:01 -0500 (EST) Message-Id: <200302061430.JAA19072@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-certstore-http-04.txt Date: Thu, 06 Feb 2003 09:30:01 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP Author(s) : P. Gutmann Filename : draft-ietf-pkix-certstore-http-04.txt Pages : 0 Date : 2003-2-5 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 Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-certstore-http-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-certstore-http-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-5140302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certstore-http-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certstore-http-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5140302.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Thu Feb 6 10:05:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20538 for ; Thu, 6 Feb 2003 10:05:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16EZ8811933 for ietf-pkix-bks; Thu, 6 Feb 2003 06:35:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16EZ6d11925 for ; Thu, 6 Feb 2003 06:35:06 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08898; Thu, 6 Feb 2003 07:35:07 -0700 (MST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h16EZ6M16730; Thu, 6 Feb 2003 09:35:06 -0500 (EST) Message-ID: <3E427221.ACEBD514@sun.com> Date: Thu, 06 Feb 2003 09:33:05 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <3E42612D.9030104@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This does not address Luciano's question. Luciano is asking (I think) whether it's OK to have an end-entity certificate whose notAfter date is January 1, 2005 if the preceding CA certificate has a notAfter date of June 30, 2004 (for example). Assume that the current date is February 6, 2003. The answer is that this is fine. The validation algorithm does not prohibit it and that's a good thing. It's not unusual for the CA that issues an end-entity certificate to have several CA certificates, with varying validity periods. Cross-certificates with that CA as the subject, for instance. As long as all of the certificates in a path have a validity period that includes the current time, there's no problem. Steve Hanna Denis Pinkas wrote: > > Luciano, > > > Is it legal for a certificate to have a longer validity period than its CA > > certificate? In other words: Should not a path validation algorithm > > (according to RFC 3280) reject an alleged CA certificate if its notAfter > > value is lower than the one in the certificate (supposedly) issued by it? > > The standard does not say a word about it, > > Extract from RFC 3280: > > 6.1.3 Basic Certificate Processing > > The basic path processing actions to be performed for certificate i > (for all i in [1..n]) are listed below. > > (a) Verify the basic certificate information. The certificate > MUST satisfy each of the following: > > (snip) > > (2) The certificate validity period includes the current time. > > Denis > > > but I think it is quite > > reasonable to include this condition in the path validation algorithm. > > Unless I am missing something and there are cases (cross-certification > > maybe?) where it is necessary to allow such certification chains. > > > > Luciano Medina From owner-ietf-pkix@mail.imc.org Thu Feb 6 10:35:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22431 for ; Thu, 6 Feb 2003 10:35:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16F7ke12843 for ietf-pkix-bks; Thu, 6 Feb 2003 07:07:46 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16F7Yd12835 for ; Thu, 6 Feb 2003 07:07:34 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA15284; Thu, 6 Feb 2003 16:09:34 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA08158; Thu, 6 Feb 2003 15:01:03 +0100 Message-ID: <3E42797A.2030908@bull.net> Date: Thu, 06 Feb 2003 16:04:26 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Steve Hanna CC: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <3E42612D.9030104@bull.net> <3E427221.ACEBD514@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, > This does not address Luciano's question. Luciano is asking > (I think) whether it's OK to have an end-entity certificate Luciano was not raising that question. He was not speaking specifically of an end-entity certificate. > whose notAfter date is January 1, 2005 if the preceding CA > certificate has a notAfter date of June 30, 2004 (for example). > Assume that the current date is February 6, 2003. > > The answer is that this is fine. The validation algorithm > does not prohibit it and that's a good thing. Now, to answer your question, this is not fine if you assume that the current date is November 30, 2004. So it is useless (but not prohibited) to place such a date in an end-entity certificate. Denis > It's not > unusual for the CA that issues an end-entity certificate > to have several CA certificates, with varying validity periods. > Cross-certificates with that CA as the subject, for instance. > > As long as all of the certificates in a path have a validity > period that includes the current time, there's no problem. > > Steve Hanna > > Denis Pinkas wrote: > >>Luciano, >> >> >>>Is it legal for a certificate to have a longer validity period than its CA >>>certificate? In other words: Should not a path validation algorithm >>>(according to RFC 3280) reject an alleged CA certificate if its notAfter >>>value is lower than the one in the certificate (supposedly) issued by it? >>>The standard does not say a word about it, >> >>Extract from RFC 3280: >> >>6.1.3 Basic Certificate Processing >> >> The basic path processing actions to be performed for certificate i >> (for all i in [1..n]) are listed below. >> >> (a) Verify the basic certificate information. The certificate >> MUST satisfy each of the following: >> >> (snip) >> >> (2) The certificate validity period includes the current time. >> >>Denis >> >> >>>but I think it is quite >>>reasonable to include this condition in the path validation algorithm. >>>Unless I am missing something and there are cases (cross-certification >>>maybe?) where it is necessary to allow such certification chains. >>> >>>Luciano Medina >> > From owner-ietf-pkix@mail.imc.org Thu Feb 6 11:15:10 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24163 for ; Thu, 6 Feb 2003 11:15:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16FZer13839 for ietf-pkix-bks; Thu, 6 Feb 2003 07:35:40 -0800 (PST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16FZdd13833 for ; Thu, 6 Feb 2003 07:35:39 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07293; Thu, 6 Feb 2003 07:35:34 -0800 (PST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h16FZYM23943; Thu, 6 Feb 2003 10:35:34 -0500 (EST) Message-ID: <3E42804D.3216C765@sun.com> Date: Thu, 06 Feb 2003 10:33:33 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <3E42612D.9030104@bull.net> <3E427221.ACEBD514@sun.com> <3E42797A.2030908@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > > This does not address Luciano's question. Luciano is asking > > (I think) whether it's OK to have an end-entity certificate > > Luciano was not raising that question. He was not speaking > specifically of an end-entity certificate. I'll leave it to Luciano to explain what his question was. My answer applies equally well if the second certificate in the path is a CA certificate. It's just easier to describe if one is a CA certificate and the other is an end-entity certificate. > > whose notAfter date is January 1, 2005 if the preceding CA > > certificate has a notAfter date of June 30, 2004 (for example). > > Assume that the current date is February 6, 2003. > > > > The answer is that this is fine. The validation algorithm > > does not prohibit it and that's a good thing. > > Now, to answer your question, this is not fine if you assume that the > current date is November 30, 2004. So it is useless (but not prohibited) to > place such a date in an end-entity certificate. Certainly, that path would not be valid on November 30, 2004. But the path is valid on February 6, 2003 (and for more than a year after that). The CA in question may have several CA certificates issued for it (cross-certificates from various parties). Some of these CA certificates may only be valid for a few more months. But this should not prevent the CA from issuing an end-entity certificate with a validity period that extends far into the future. The cross-certificates may be reissued with a later notAfter date. But even if they aren't, relying parties that don't need the expired cross-certificates will still be able to validate the end-entity certificate for a long time. RPs that have the CA in question as their trust anchor, for instance. Or RPs that use other cross-certificates to reach that CA. So it is not useless for a CA to issue an end-entity cert whose validity period extends beyond the validity period of a CA certificate whose subject is that CA. Thanks, Steve From owner-ietf-pkix@mail.imc.org Thu Feb 6 11:21:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24393 for ; Thu, 6 Feb 2003 11:21:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16FpuC15361 for ietf-pkix-bks; Thu, 6 Feb 2003 07:51:56 -0800 (PST) Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Fpsd15353 for ; Thu, 6 Feb 2003 07:51:54 -0800 (PST) Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id H9W9FK01.FMB for ; Thu, 6 Feb 2003 16:52:32 +0100 Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15 gibson Mar 14 2002 21:29:48) with ESMTP id H9W9GE01.QEL; Thu, 6 Feb 2003 16:53:02 +0100 Subject: Re: Path validation decision based on notAfter To: Steve Hanna Cc: Denis Pinkas , ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: luciano.medina@safelayer.com Date: Fri, 7 Feb 2003 16:53:48 +0100 X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.9a |January 7, 2002) at 07/02/2003 16:53:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I'll leave it to Luciano to explain what his question was. Yes, Steve, my question was what you understood. Your answer seems reasonable, and actually all the trouble arised when I started to play around with cross-certificates. Thanks to all who replied. Luciano Medina Steve Hanna com> cc: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter 06/02/2003 16:33 Denis Pinkas wrote: > > This does not address Luciano's question. Luciano is asking > > (I think) whether it's OK to have an end-entity certificate > > Luciano was not raising that question. He was not speaking > specifically of an end-entity certificate. I'll leave it to Luciano to explain what his question was. My answer applies equally well if the second certificate in the path is a CA certificate. It's just easier to describe if one is a CA certificate and the other is an end-entity certificate. > > whose notAfter date is January 1, 2005 if the preceding CA > > certificate has a notAfter date of June 30, 2004 (for example). > > Assume that the current date is February 6, 2003. > > > > The answer is that this is fine. The validation algorithm > > does not prohibit it and that's a good thing. > > Now, to answer your question, this is not fine if you assume that the > current date is November 30, 2004. So it is useless (but not prohibited) to > place such a date in an end-entity certificate. Certainly, that path would not be valid on November 30, 2004. But the path is valid on February 6, 2003 (and for more than a year after that). The CA in question may have several CA certificates issued for it (cross-certificates from various parties). Some of these CA certificates may only be valid for a few more months. But this should not prevent the CA from issuing an end-entity certificate with a validity period that extends far into the future. The cross-certificates may be reissued with a later notAfter date. But even if they aren't, relying parties that don't need the expired cross-certificates will still be able to validate the end-entity certificate for a long time. RPs that have the CA in question as their trust anchor, for instance. Or RPs that use other cross-certificates to reach that CA. So it is not useless for a CA to issue an end-entity cert whose validity period extends beyond the validity period of a CA certificate whose subject is that CA. Thanks, Steve From owner-ietf-pkix@mail.imc.org Thu Feb 6 11:25:14 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24517 for ; Thu, 6 Feb 2003 11:25:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16FrMT15434 for ietf-pkix-bks; Thu, 6 Feb 2003 07:53:22 -0800 (PST) Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16FrLd15429 for ; Thu, 6 Feb 2003 07:53:21 -0800 (PST) Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <0H9W00G0198W4Y@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:49:34 +0000 (GMT) Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <0H9W00DJ59AFN0@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:49:27 +0000 (GMT) Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) id <0H9W00K018JZUP@namems01.sugar-land.oilfield.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:48:33 +0000 (GMT) Received: from SCHLUMBE-OITRVU.parsippany.sns.slb.com (vpnpool296.houston.sinet.slb.com [163.188.125.40]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) with ESMTP id <0H9W007QS8XSF4@namems01.sugar-land.oilfield.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:41:55 +0000 (GMT) Content-return: prohibited Date: Thu, 06 Feb 2003 10:41:11 -0500 From: "Joel S. Kazin" Subject: Re: Path validation decision based on notAfter In-reply-to: <3E42612D.9030104@bull.net> X-Sender: jkazin@163.188.150.131 To: ietf-pkix@imc.org Cc: ietf-pkix@imc.org Message-id: <5.1.1.1.2.20030206102834.00abf5f0@163.188.150.131> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT The RFC may be ambiguous. If the CA certificate expires next week and the end entity certificate expires a year from now and I check the certificate today it will pass. However, if I check it in a month the certificate will fail. If the CA certificate is renewed tomorrow and I check the certificate a month from now it will pass. Note that if the CA re-keys its signing certificate the EE certificate will not pass if it is checked in a month. The reason that I and others would reject such a certificate is that the CA is making a statement about actions it may take in the future, re-certifying an existing key as opposed to a current or past action. Neither Entrust nor Microsoft will issue such a problematic certificate. At 02:20 PM 2/6/2003 +0100, Denis Pinkas wrote: >Luciano, > >>Is it legal for a certificate to have a longer validity period than its CA >>certificate? In other words: Should not a path validation algorithm >>(according to RFC 3280) reject an alleged CA certificate if its notAfter >>value is lower than the one in the certificate (supposedly) issued by it? >>The standard does not say a word about it, > >Extract from RFC 3280: > >6.1.3 Basic Certificate Processing > > The basic path processing actions to be performed for certificate i > (for all i in [1..n]) are listed below. > > (a) Verify the basic certificate information. The certificate > MUST satisfy each of the following: > > (snip) > > (2) The certificate validity period includes the current time. > >Denis > >>but I think it is quite >>reasonable to include this condition in the path validation algorithm. >>Unless I am missing something and there are cases (cross-certification >>maybe?) where it is necessary to allow such certification chains. >>Luciano Medina > > Senior Consultant Technical Consulting Practice, Northeast Region Schlumberger Network Solutions jkazin@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 914-769-8780 Mobile +1 914-645-5598 From owner-ietf-pkix@mail.imc.org Thu Feb 6 12:25:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26873 for ; Thu, 6 Feb 2003 12:25:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16GsVm20851 for ietf-pkix-bks; Thu, 6 Feb 2003 08:54:31 -0800 (PST) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16GsTd20846 for ; Thu, 6 Feb 2003 08:54:29 -0800 (PST) Received: from salford.ac.uk ([80.7.98.74]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030206165426.SIFM3191.mta07-svc.ntlworld.com@salford.ac.uk>; Thu, 6 Feb 2003 16:54:26 +0000 Message-ID: <3E42937C.6752352E@salford.ac.uk> Date: Thu, 06 Feb 2003 16:55:24 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: Tony Bartoletti , pgut001@cs.auckland.ac.nz, anders.rundgren@telia.com, lynn.wheeler@firstdata.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP References: Content-Type: multipart/mixed; boundary="------------6DFB3B83616C3D4B2A4844A8" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6DFB3B83616C3D4B2A4844A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Phil Bit late to come in on this discussion. Ironically the reason why is because we are currently very busy modifying OpenLDAP to solve the very sorts of problem identified by you below, and others (eg Peter G) in later messages, namely, the ability to search in LDAP directories for certificates that meet key,value pairs. But actually your mail contains a lot of misguided comments as well, and in some cases just plain ignorance of the facts about LDAP and X.500. It also contains some quite comical bits e.g. > the client wants to ask is 'what is the email address of > lynn.wheeler@firstdata.com' what the directory wants to be asked Seems like the client already knows the answer!! So why ask for something you already know? I guess it must have been a typo on your part, but not quite sure what the mistake was. But seriously, the problem LDAP had/still has, is that matching rules for PKI certificates have never been defined/standardised, which means that LDAP users can not search for certificates. Full stop. LDAP has always been able to search for email addresses, indeed this was one of the main reasons why many companies purchased LDAP directories in the first place - to search for email addresses. Had matching rules for certificates been defined by LDAP early on (they were for X.500, but never mapped accross to LDAP) and implemented, then you would have been able to do queries such as "find me the cert with key usage equals NR, and subjectAltName email address is a.b@X.com"; indeed any key,value pair from any cert or CRL field would have been searchable. However, to implement such matching rules in LDAP is complex. I and Steven Legg have authored a couple of PKIX drafts which specified these matching rules (for PKI and PMI). We also started to implement them. Steven completed his in his X.500 based server, but we found it difficult in a pure LDAP server (such as openLDAP), the difference being that X.500 servers understood ASN.1 inherently, whereas LDAP tries to minimise its understanding of ASN.1 as much as possible. And since certs are completely ASN.1 based, they dont naturally fit with LDAP's way of doing things. Consequently we have now adopted the approach of Gietz and KLasen, and are splitting the PKI certs and CRLs up into LDAP attributes, storing the attributes in the conventional LDAP servers, and allowing the users to search on these. And since these attributes use existing LDAP matching rules and syntaxes, the conventional LDAP servers wont need modifying. Our modifications to OpenLDAP will allow the modified OpenLDAP server to sit in front of conventional corporate LDAP servers, parse and split up the PKI certs, store them in the conventional LDAP server as leaf entries, and then users will be able to search their conventional LDAP servers for PKI certs. Meanwhile the CA will talk to the modified OpenLDAP server as now, with no changes needed to it. There will be some limitations in the searching capability, but it should fulfil the vast majority of user requirements. One final footnote. Just to show that I am not an "LDAP is the answer to everything, now what is the question" type of person, I have a paper being published in Comms of the ACM in April this year entitled "Deficiencies in LDAP when used to support Public Key Infrastructures". Watch out for it, and read it. It should help to dispell some of your LDAP ignorance. Answers to specific points you make below David "Hallam-Baker, Phillip" wrote: > > > The hierachical organization of the directory does not help > the email application at all. Not true at a corporate level. The DIT structure is irrelevant to the email application since it typically searches the whole corporate directory. At the internet level, the question becomes, how do I find the right corporate directory to search. SRV records are solving this one. > The other practical problem with directories is that they will > never reach beyond the enterprise firewall. Whereas the web clearly has no problem at all with firewalls, since everything is tunnelled through port 80, thereby blowing the concept of a firewall entirely away. From a security perspective I would say that LDAP is not a problem for firewalls, but the web is. A plus point for LDAP from a security perspective, is that directories actually use a different port to the web, so administrators can control this traffic more easily. And if one uses an LDAP application proxy in the firewall as well, even better, you can have very tight control. (We built one such proxy years ago and presented the results at 1997 NDSS in San Diego) > >abstractions of sensitive > data on external IT services whose principal purpose is providing > indexing and searching functions. Two points here. Firstly you are now acknowledging that LDAP servers DO provide searching facilities, which you seemed to imply they did not do earlier. Secondly, what is sensitive about a PUBLIC key certificate? Perhaps the email address inside it? regards David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 01484 532930 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------6DFB3B83616C3D4B2A4844A8 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------6DFB3B83616C3D4B2A4844A8-- From owner-ietf-pkix@mail.imc.org Thu Feb 6 12:31:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27111 for ; Thu, 6 Feb 2003 12:31:05 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16Gjma20653 for ietf-pkix-bks; Thu, 6 Feb 2003 08:45:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Gjgd20641 for ; Thu, 6 Feb 2003 08:45:42 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16334; Thu, 6 Feb 2003 09:45:43 -0700 (MST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h16GjhM03182; Thu, 6 Feb 2003 11:45:43 -0500 (EST) Message-ID: <3E4290BE.D8127491@sun.com> Date: Thu, 06 Feb 2003 11:43:42 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Joel S. Kazin" CC: ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <5.1.1.1.2.20030206102834.00abf5f0@163.188.150.131> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I see no ambiguity in the RFC. Could you be more explicit in explaining what's ambiguous? Also, I don't think Entrust or Microsoft can avoid issuing such a "problematic" certificate. The CA that issues the end-entity certificate (let's call it Andrew) may not know about all CA certificates that have Andrew as the subject. Even if the CA somehow knew of all such CA certificates at the time it issued the end-entity certificate, it couldn't prevent another CA from later issuing a short-lived CA certificate with Andrew as the subject. So Andrew cannot prevent this situation from happening. And, as I described in my earlier email, the situation is perfectly fine. As long as all certs in the path are valid, there should be no need for each cert to have an earlier notAfter date than the preceding cert. If we add such a requirement, what's next? Will we require the subject names to be in alphabetical order? ;-) Steve "Joel S. Kazin" wrote: > > The RFC may be ambiguous. > > If the CA certificate expires next week and the end entity certificate > expires a year from now and I check the certificate today it will pass. > However, if I check it in a month the certificate will fail. > > If the CA certificate is renewed tomorrow and I check the certificate > a month from now it will pass. > > Note that if the CA re-keys its signing certificate the EE certificate will > not pass if it is checked in a month. > > The reason that I and others would reject such a certificate is that the > CA is making a statement about actions it may take in the future, > re-certifying an existing key as opposed to a current or past action. > > Neither Entrust nor Microsoft will issue such a problematic certificate. > > At 02:20 PM 2/6/2003 +0100, Denis Pinkas wrote: > > >Luciano, > > > >>Is it legal for a certificate to have a longer validity period than its CA > >>certificate? In other words: Should not a path validation algorithm > >>(according to RFC 3280) reject an alleged CA certificate if its notAfter > >>value is lower than the one in the certificate (supposedly) issued by it? > >>The standard does not say a word about it, > > > >Extract from RFC 3280: > > > >6.1.3 Basic Certificate Processing > > > > The basic path processing actions to be performed for certificate i > > (for all i in [1..n]) are listed below. > > > > (a) Verify the basic certificate information. The certificate > > MUST satisfy each of the following: > > > > (snip) > > > > (2) The certificate validity period includes the current time. > > > >Denis > > > >>but I think it is quite > >>reasonable to include this condition in the path validation algorithm. > >>Unless I am missing something and there are cases (cross-certification > >>maybe?) where it is necessary to allow such certification chains. > >>Luciano Medina > > > > > > Senior Consultant > Technical Consulting Practice, Northeast Region > Schlumberger Network Solutions > > jkazin@parsippany.sns.slb.com > www.slb.com/nws > > 35 Waterview Blvd. > Suite 210 > Parsippany, NJ 07054-1200 > USA > > Phone +1 914-769-8780 > Mobile +1 914-645-5598 From owner-ietf-pkix@mail.imc.org Thu Feb 6 13:02:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28442 for ; Thu, 6 Feb 2003 13:02:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16HLGQ21464 for ietf-pkix-bks; Thu, 6 Feb 2003 09:21:16 -0800 (PST) Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16HLEd21456; Thu, 6 Feb 2003 09:21:14 -0800 (PST) Received: from [198.202.64.211] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24804; Thu, 6 Feb 2003 12:21:19 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 6 Feb 2003 12:21:01 -0500 To: Olaf.Schlueter@secartis.com From: Stephen Kent Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, pgut001@cs.auckland.ac.nz (Peter Gutmann) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:54 PM +0100 2/5/03, Olaf.Schlueter@secartis.com wrote: >Olaf, > >>> >>> >>>In Germany the german signature law is identifying a fourth case: >>> >>>4. the cert is in the repository, but not active yet (cert invalid, maybe >>>valid in the future) >>> >>>This case is required (by law) if a CA issues not only certificates but >>>private keys as well to the end user. Think of a bank producing and >>>delivering a smartcard with keys and certificates on it to you. As long >as >>>you did not confirm the receipt of the card to the CA the CA must protect >>>you by having the certificate "on hold" so during transport no valid >>>signatures can be created. This may be handled by an "onHold" status on a >>>CRL but is currently deployed in Germany using white list technology. > >>This seems an unnecessary complication. The CA could simply wait to >>post the cert to a directory until the user acknowledges receipt. >>I'm not in favor of adding complexity when there are other, simpler >>solutions to a problem. > >To withhold the certificate from the directory is exactly the solution that >is applied by existing service providers currently. But that means that RPs >are forced to check the existance of a given certificate in the directory >to examine validity of a signature, i.e. a white-list check. This is in >compliance with the law (great) but not with PKIX (uups). > >Currently OCSP (the german style) is used to perform that check. And I >agree that RFC OCSP has not been built for that. We (i.e. those people >that discussed which specifications to go for to implement law-compliant >PKIs) adopted OCSP as a solution to this problem while it was in draft. And >we totally missed the basic idea that OCSP should be a responder capable of >working on CRLs alone. We interpreted it as a white-list service from the >very beginning. When the draft was finished and promoted to an RFC we had >to realize that we created something different. Peters RTCS in its current >shape would deliver the needed functionality as well. > >I understand your suggestion as setting up an LDAP-directory that allows >queries for matches for a given certificate. That would be an alternative >and simple way to implement a white-list, but it would still be a >white-list. (Issues like obtaining trust into the response of the directory >and obtaining information on the point in time the certificate was inserted >into the directory have still to be resolved.) And white-list checks are >IMHO not in compliance with PKIX path validation. We would love to see >someone demonstrating to us that the legal obligations already explained >maybe implemented one way or the other in compliance with PKIX. My suggestion is not at all what you suggest. Two issues were cited as the rationale for using a white list for verifying cert validity: - dealing with activation for postal delivery of smart cards - dealing with CA key compromise, again with emphasis on smart cards, where the costs of cert reissuance are very significant I said was that using any white list scheme to validate a cert, e.g., directory presence, is just one approach to solving concerns re CA key compromise or smart card activation. As such it probably does not merit standardization, since other schemes for addressing this concern are invisible from a standards perspective. Steve From owner-ietf-pkix@mail.imc.org Thu Feb 6 15:41:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03618 for ; Thu, 6 Feb 2003 15:41:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16KEoS29387 for ietf-pkix-bks; Thu, 6 Feb 2003 12:14:50 -0800 (PST) Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16KEnd29382 for ; Thu, 6 Feb 2003 12:14:49 -0800 (PST) Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h16KE4ml027895; Thu, 6 Feb 2003 21:14:04 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <01c301c2ce1a$f2146690$0500a8c0@arport> From: "Anders Rundgren" To: "David Chadwick" , "Hallam-Baker, Phillip" Cc: "Tony Bartoletti" , , , , References: <3E42937C.6752352E@salford.ac.uk> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Thu, 6 Feb 2003 21:04:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit But the _real_ problem with the X.500 model is that it builds on the assumption that organizations want to publish information for others to search. If you go to most major corporation (in contrast to academia) and check their home-pages for personal e-mail addresses, you will have to look very hard find anything, and _never_ a view allowing outsiders to search for employees. Authenticating to directories become ridiculous when organizations have hundreds of thousands of employees are "authorized". How many encrypted messages did you receive lately? Anders From owner-ietf-pkix@mail.imc.org Thu Feb 6 17:37:46 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07160 for ; Thu, 6 Feb 2003 17:37:45 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16MA7S03017 for ietf-pkix-bks; Thu, 6 Feb 2003 14:10:07 -0800 (PST) Received: from nb2.stroeder.com (cxxix.yapay.inka.de [193.197.185.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16MA3d03013 for ; Thu, 6 Feb 2003 14:10:04 -0800 (PST) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B04874E720 for ; Thu, 6 Feb 2003 23:07:39 +0100 (CET) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id BBF01231AF for ; Thu, 6 Feb 2003 23:07:38 +0100 (CET) Message-ID: <3E42DCAA.1070106@stroeder.com> Date: Thu, 06 Feb 2003 23:07:38 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP References: <3E42937C.6752352E@salford.ac.uk> <01c301c2ce1a$f2146690$0500a8c0@arport> In-Reply-To: <01c301c2ce1a$f2146690$0500a8c0@arport> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > But the _real_ problem with the X.500 model is that it builds > on the assumption that organizations want to publish information > for others to search. Again: This is not a specific problem with the X.500 model. It's a general problem with certificate retrieval across organizational boundaries. Using a 'web service' (whatever we might agree in the future if ever on what that really is) will just migrate the very same problems to another service. That's what folks should understand *before* trying to solve problems by defining yet another standard with yet another buzz-word. And I also agree with David that web services just circumvents firewalls by simple HTTP tunneling. That's not a solution, it's a real security risk making content filtering and very complex proxying necessary in the long run. Web services' promoters simply keep quite about that and security people are still too busy repairing the rest of the brave new web world, the weird mess we already have. > If you go to most major corporation (in > contrast to academia) and check their home-pages for personal > e-mail addresses, you will have to look very hard find anything > and _never_ a view allowing outsiders to search for employees. Yes, this is the privacy problem. So what? It's completely independent of the X.500 model and LDAP. Is that news to you? This is a really hard issue to solve even *within* large companies no matter which technology you're using. There's no general solution and I doubt there will be one in a forseeable future. > How many encrypted messages did you receive lately? PKI acceptance is yet another issue independent of X.500 directories. If someone's to blame for lack of PKI acceptance it's this WG for not reaching consensus on very basic issues (feel free to check the mailing list archive *excluding* the dumb X.500 bashing of last three months) and inventing new competing, even more complex standards all the time. Implementors simply can't follow reading the relevant RFCs to determine what to implement and what to leave aside. Not to speak of ambigous wording leading to many broken implementations. And no, the problems will not automagically be solved by XML, XKMS, . Ciao, Michael. From owner-ietf-pkix@mail.imc.org Thu Feb 6 18:16:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08327 for ; Thu, 6 Feb 2003 18:16:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16Mr1j04027 for ietf-pkix-bks; Thu, 6 Feb 2003 14:53:01 -0800 (PST) Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Mqxd04023 for ; Thu, 6 Feb 2003 14:52:59 -0800 (PST) Received: from localhost (212.247.5.91) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 6 Feb 2003 23:49:17 +0100 Date: Thu, 06 Feb 2003 23:45:31 +0100 (CET) Message-ID: <20030206.234531.130618309.levitte@lp.se> To: anders.rundgren@telia.com CC: d.w.chadwick@salford.ac.uk, pbaker@verisign.com, azb@llnl.gov, pgut001@cs.auckland.ac.nz, lynn.wheeler@firstdata.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP From: Richard Levitte - VMS Whacker In-Reply-To: <01c301c2ce1a$f2146690$0500a8c0@arport> References: <3E42937C.6752352E@salford.ac.uk> <01c301c2ce1a$f2146690$0500a8c0@arport> X-URL: http://www.lp.se/ X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1 X-Mew: See http://www.mew.org/ X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) MIME-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit In message <01c301c2ce1a$f2146690$0500a8c0@arport> on Thu, 6 Feb 2003 21:04:22 +0100, "Anders Rundgren" said: anders.rundgren> But the _real_ problem with the X.500 model is that anders.rundgren> it builds on the assumption that organizations want anders.rundgren> to publish information for others to search. If you anders.rundgren> go to most major corporation (in contrast to anders.rundgren> academia) and check their home-pages for personal anders.rundgren> e-mail addresses, you will have to look very hard anders.rundgren> find anything, and _never_ a view allowing outsiders anders.rundgren> to search for employees. For those organizations, it would seem obvious that you'll get whatever certificate you may need when someone from said corporation gets in touch with you, not the other way around. anders.rundgren> How many encrypted messages did you receive lately? As I recall, that shouldn't be a problem in this context. Maybe you meant "signed" rather than "encrypted", and in that case (IIRC), you'll usually get the signators certificate in the same mail. As far as I'm concerned, there's a different type of data that's rather crucial to have more or less publically available: the CA certificates, and I'm sure most organizations wouldn't avoid having those publically available, or? It's pretty late, and I suffer a bit from lack of sleep, so if the above didn't make sense, I'll probably have to reiterate my comment tomorrow... -- Richard Levitte | http://richard.levitte.org/ | Spannv. 38, I Levitte Programming | http://www.lp.se/ | S-168 35 Bromma T: +46-708-26 53 44 | | SWEDEN "Price, performance, quality... choose the two you like" From owner-ietf-pkix@mail.imc.org Fri Feb 7 02:05:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26700 for ; Fri, 7 Feb 2003 02:05:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h176WgJ14031 for ietf-pkix-bks; Thu, 6 Feb 2003 22:32:42 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h176Wed14027 for ; Thu, 6 Feb 2003 22:32:40 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Feb 2003 22:32:42 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Feb 2003 22:32:37 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Feb 2003 22:32:39 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Feb 2003 22:32:41 -0800 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3760.0); Thu, 6 Feb 2003 22:32:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Path validation decision based on notAfter Date: Thu, 6 Feb 2003 22:32:38 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD063338D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Path validation decision based on notAfter Thread-Index: AcLN+dh5jJGn7V2YTR+UwWb1btbikAAdm7zA From: "Trevor Freeman" To: "Joel S. Kazin" , Cc: X-OriginalArrivalTime: 07 Feb 2003 06:32:41.0897 (UTC) FILETIME=[B7702990:01C2CE72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h176Wfd14028 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Joel, The motivation why we chose not to issue such a certificate has nothing with path validation. As Steve rightly points out, a CA may have been certified several times resulting in multiple paths for any certificate it issues. Each path can have different validity ranges, but all that counts is each certificate valid at the time you validate the certificate. Our decision to limit the CA to issuing certificate within the lifetime of its own certificate is purely to simplify the certificate lifecycle management issue by ensuring that if a CAs certificate expires, them all certificate issued by that CA have also expired. Trevor -----Original Message----- From: Joel S. Kazin [mailto:jkazin@parsippany.sns.slb.com] Sent: Thursday, February 06, 2003 7:41 AM To: ietf-pkix@imc.org Cc: ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter The RFC may be ambiguous. If the CA certificate expires next week and the end entity certificate expires a year from now and I check the certificate today it will pass. However, if I check it in a month the certificate will fail. If the CA certificate is renewed tomorrow and I check the certificate a month from now it will pass. Note that if the CA re-keys its signing certificate the EE certificate will not pass if it is checked in a month. The reason that I and others would reject such a certificate is that the CA is making a statement about actions it may take in the future, re-certifying an existing key as opposed to a current or past action. Neither Entrust nor Microsoft will issue such a problematic certificate. At 02:20 PM 2/6/2003 +0100, Denis Pinkas wrote: >Luciano, > >>Is it legal for a certificate to have a longer validity period than its CA >>certificate? In other words: Should not a path validation algorithm >>(according to RFC 3280) reject an alleged CA certificate if its notAfter >>value is lower than the one in the certificate (supposedly) issued by it? >>The standard does not say a word about it, > >Extract from RFC 3280: > >6.1.3 Basic Certificate Processing > > The basic path processing actions to be performed for certificate i > (for all i in [1..n]) are listed below. > > (a) Verify the basic certificate information. The certificate > MUST satisfy each of the following: > > (snip) > > (2) The certificate validity period includes the current time. > >Denis > >>but I think it is quite >>reasonable to include this condition in the path validation algorithm. >>Unless I am missing something and there are cases (cross-certification >>maybe?) where it is necessary to allow such certification chains. >>Luciano Medina > > Senior Consultant Technical Consulting Practice, Northeast Region Schlumberger Network Solutions jkazin@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 914-769-8780 Mobile +1 914-645-5598 From owner-ietf-pkix@mail.imc.org Fri Feb 7 03:52:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01942 for ; Fri, 7 Feb 2003 03:52:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h178XJw01854 for ietf-pkix-bks; Fri, 7 Feb 2003 00:33:19 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h178XGd01846 for ; Fri, 7 Feb 2003 00:33:17 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id DC08710F8F0; Fri, 7 Feb 2003 09:33:10 +0100 (CET) From: "Simon Tardell" To: "'Torsten Hentschel'" , "'Denis Pinkas'" , Cc: "'Stephen Kent'" , Subject: RE: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Fri, 7 Feb 2003 09:32:48 +0100 Message-ID: <01c101c2ce83$80c4e460$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E425055.9020804@authentidate.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h178XHd01848 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Torsten, > P.S.: As far as I understand it, §19 (5) SigG was written this way > under the vision to ease the creation of non repudation style > signatures for end entities by the cost of making life a little > harder for CAs and validation software providers: When EEs use > qualified certifiactes, they are asured, they have the control, > at what time their certificate becomes invalid (either because > they lost their smart card or because they revoke it). This way > they can digitally sign contracts without the fear, that their > signature becomes invalid by an accident they did not cause > (key compromise of a CA). I suspect, this way the need should > be eleminated, that with PKIX digitally signed > contracts need to > be archived by an entrusted third party, which guarantees to > bring the non repudiateable proof at any point in the future, > that the signature has been valid at a special point in time. Sometimes I think people attribute too much to certificates. You sign with the keys, not with the certificates. The binding between the key and identity can in principal be established after the signature has been made. Having the certs before the point of signature *verification* does indeed the hassle for the verifier, but until then they don't matter too much. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Fri Feb 7 06:18:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05271 for ; Fri, 7 Feb 2003 06:18:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17AnrX20980 for ietf-pkix-bks; Fri, 7 Feb 2003 02:49:53 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Anpd20974 for ; Fri, 7 Feb 2003 02:49:51 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id EAA01067; Wed, 12 Feb 2003 04:28:05 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h17Ann911549; Fri, 7 Feb 2003 11:49:49 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E438F4A.4030007@authentidate.de> Date: Fri, 07 Feb 2003 11:49:46 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Simon Tardell CC: ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <2962226.1044606665221.JavaMail.root@email.authentidate.de> In-Reply-To: <2962226.1044606665221.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h17Anqd20975 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Simon, Simon Tardell wrote: > Torsten, > > >>P.S.: As far as I understand it, §19 (5) SigG was written this way >> under the vision to ease the creation of non repudation style >> signatures for end entities by the cost of making life a little >> harder for CAs and validation software providers: When EEs use >> qualified certifiactes, they are asured, they have the control, >> at what time their certificate becomes invalid (either because >> they lost their smart card or because they revoke it). This way >> they can digitally sign contracts without the fear, that their >> signature becomes invalid by an accident they did not cause >> (key compromise of a CA). I suspect, this way the need should >> be eleminated, that with PKIX digitally signed >>contracts need to >> be archived by an entrusted third party, which guarantees to >> bring the non repudiateable proof at any point in the future, >> that the signature has been valid at a special point in time. > > > Sometimes I think people attribute too much to certificates. You sign > with the keys, not with the certificates. The binding between the key > and identity can in principal be established after the signature has > been made. Having the certs before the point of signature *verification* > does indeed the hassle for the verifier, but until then they don't > matter too much. Thanks for this aspect. I already catched it from your earlier postings and it made me think the direction you outline here. So you already made me aware of the fact, that key and certificate can be considered independent. I think it really is nice. When I read your earlier lines, it became aware, that SigG may have gone a step too far when it demands that certificates may not become invalid just by a CA cert revocation. For the intent the writers had in mind (as I suspect it), it would have been sufficient to demand the following things: a) The key may not become useless by a CA cert revocation. (Somebody has to issue and distribute new certs for these keys. A cert on a smart card can be replaced easily.) b) Signatures intended for long term non repudiation must have been completed with validation information (RFC 3116 style; "ES-X long" wraped by "ES-A") shortly after creation. Indeed, b) is demanded by SigG in a relaxed way already. A different point using current practice: When you create RFC 3116 style ES-X containers, then PKIX signatures can become the same weight as the signatures required by SigG. But it is obvious that long term non repudiation signatures become more expensive and complicated to create. The question is, what is more economic. Compatibilty with the rest of the world must be respected in the calculations of the German government for the answer as well. Perhaps there is the root of the problem. Kind regards, Torsten -- Torsten Hentschel [The poisitions described by me above are not neccessarily those of my employer.] From owner-ietf-pkix@mail.imc.org Fri Feb 7 10:08:27 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13056 for ; Fri, 7 Feb 2003 10:08:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17EcTB04225 for ietf-pkix-bks; Fri, 7 Feb 2003 06:38:29 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17EcRd04215 for ; Fri, 7 Feb 2003 06:38:27 -0800 (PST) Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Torsten Hentschel Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, Simon Tardell X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 7 Feb 2003 07:40:13 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/07/2003 09:40:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: not only the key and the certificate independent .... but the certificate is actually just some representation of a process of RA and certification. in that sense ... anologous to other certificates &/or license ... aka say a driver's license .... representing the test you took to drive. if your driver's license goes thru the wash (and/or some other process and is destroyed) ... that doesn't mean that you need to retake the driver's test to get a new license. your ability to drive is independent of the certification process ... and the certification/license issue to represent the test of your ability to drive. typically if some license/certificate is lost/destroyed ... it is just re-issued. in the aads model ... it is even taken further. it isn't even necessary to have a certificate to sign something with a key. it allows for some online facility that can make a real-time representation to the RA and certification process. this is somewhat taken from financial transaction model .... where something is used for authentication .... but there is a real-time access to representation .... especially in a business model where the business process transaction contains the complete real-time representation that is something specific to the business process at hand with higher quality information (aka rather than providing the lower quality information that a certificate might represent about individual having a bank account .... the real-time transaction says that there is actual funds available for the transactions and the movement of money has actually occured). In that case, the key can be sufficient for the bank to know that it is one of their customers .... and the merchant doesn't care particularly any details about you ... they just care whether they get their money. http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/index.html#aads -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm the@authentidate.de on 12/7/2003 3:49 am wrote: Hi Simon, Simon Tardell wrote: .. snip .. Thanks for this aspect. I already catched it from your earlier postings and it made me think the direction you outline here. So you already made me aware of the fact, that key and certificate can be considered independent. I think it really is nice. From owner-ietf-pkix@mail.imc.org Fri Feb 7 10:14:23 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13149 for ; Fri, 7 Feb 2003 10:14:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17Ee6c04263 for ietf-pkix-bks; Fri, 7 Feb 2003 06:40:06 -0800 (PST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Ee5d04259 for ; Fri, 7 Feb 2003 06:40:05 -0800 (PST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53] (may be forged)) by pigeon.verisign.com (8.12.1/) with ESMTP id h17EcDrT024485; Fri, 7 Feb 2003 06:38:14 -0800 (PST) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <133B4AZN>; Fri, 7 Feb 2003 06:40:05 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: David Chadwick , "Hallam-Baker, Phillip" Cc: Tony Bartoletti , pgut001@cs.auckland.ac.nz, anders.rundgren@telia.com, lynn.wheeler@firstdata.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 7 Feb 2003 06:39:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001A_01C2CE49.7FBB48F0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C2CE49.7FBB48F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Bit late to come in on this discussion. Ironically the reason why is > because we are currently very busy modifying OpenLDAP to > solve the very > sorts of problem identified by you below, and others (eg Peter G) in > later messages, namely, the ability to search in LDAP directories for > certificates that meet key,value pairs. There is no way you can modify the directory to do certificate path discovery in a bridge CA without doing severe violence to the directory model Furthermore future developments in the directory space are of no relevance to PKI. We have already deployed XKMS. Regardless of whether one believes the future has angle brackets or OIDs the certificate repository of choice will be XKMS or OCSP/SCPV/DPVD [henceforth OCSPVD] Been there, done that, moved on. If Steve Kent is upset that I appear to be reinventing PKIX with angle brackets he can at least have the consolation that as Oscar Wilde observed, to be reinvented with angle brackets is better than not being reinvented with angle brackets. Whatever else UDDI might do it is not going to be a certificate repository. > But actually your mail contains a lot of misguided comments > as well, and > in some cases just plain ignorance of the facts about LDAP > and X.500. It > also contains some quite comical bits e.g. I don't think your experience of the PKI field is sufficient to go arround patronising people. Even if you are an academic. I think that it is you who are plain ignorant of the capabilities that PKI applications require of repositories, the trust structures in use in commercial and government deployments and the role that directories play. To give an example, to discover your (somewhat sparse) publication record with its obsessive concentration on X.500 I did not consult a 'directory', I used a search engine called Google accessed by a somewhat more successful protocol called HTTP that I helped to write. If you had performed the same degree of rudimentary research yorself you would have found the following article in the early hits: http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2879127,00.h tml Phill ------=_NextPart_000_001A_01C2CE49.7FBB48F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIwNzA2 MzczOVowIwYJKoZIhvcNAQkEMRYEFAtPfhxXqtfn9Pe4BI8OVShMvR1NMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAU+yuaWuXnZcojxhBACNs1ZnnVhqcB3RrTVo4KFh1/ESrCUP8 /oLf56RnhPYQsS4WW4Odh+C1Ed2eHy8pOTSj2ZlZ7z7TDZ4AdxWHlVupNU6D/Vcnjr+os4WcqzVd zaa2dcGxLed0dWZCkj9U48Bz5IArWmIEzCfpc3ALNyZLNnQAAAAAAAA= ------=_NextPart_000_001A_01C2CE49.7FBB48F0-- From owner-ietf-pkix@mail.imc.org Fri Feb 7 10:27:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13339 for ; Fri, 7 Feb 2003 10:27:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17F5YX04990 for ietf-pkix-bks; Fri, 7 Feb 2003 07:05:34 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17F5Wd04985 for ; Fri, 7 Feb 2003 07:05:32 -0800 (PST) Received: by fw1.gdm.de (8.11.6/8.11.6) id h17F59X11758; Fri, 7 Feb 2003 16:05:09 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Fri Feb 7 16:05:09 2003 Subject: Antwort: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Torsten Hentschel Cc: Denis Pinkas , ietf-pkix@imc.org, Stephen Kent X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Fri, 7 Feb 2003 11:34:37 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 07.02.2003 16:04:48 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The statement of Thomas is a very exact and detailled view on the problem. Thanks, Thomas. From owner-ietf-pkix@mail.imc.org Fri Feb 7 10:34:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13574 for ; Fri, 7 Feb 2003 10:34:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17F5WT04983 for ietf-pkix-bks; Fri, 7 Feb 2003 07:05:32 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17F5Ud04976 for ; Fri, 7 Feb 2003 07:05:31 -0800 (PST) Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id h17F5Bq11782; Fri, 7 Feb 2003 16:05:11 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Fri Feb 7 16:05:10 2003 Subject: A challenge To: Denis Pinkas Cc: ietf-pkix@imc.org, Stephen Kent X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Fri, 7 Feb 2003 15:59:23 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 07.02.2003 16:04:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Introductory note (hello, stephen, please read): I am not asking for updates, changes to or extensions of existing specs and standards. I just put those specs to a challenge and want to see how they respond. And I changed the topic, as we are now far away enough from discussing RTCS. The german law does not really mandate a white list check. It mandates maintaining the ability of end users to sign after a CA key compromise. Thomas has explained the law in detail. The intention of the law is to keep the user unharmed by CA key compromise. It would be fine to have at least a solution that satisfies the intention. And large-scale card issuers have as well an interest in a scheme that does not force them to replace huge volumes of smartcards in a very short period of time. And unlikely as it may be one needs a persuading emergency plan for CA key compromise if several million smartcards in the field are relying on this key security. The "chain model" that is currently in use in Germany and has the white-list mechanism in it is satisfying the requirements, but it is not compliant with PKIX and has some other problems as well (the need for online-transactions for signature validation is increased, not law-aware applications produce deviating (wrong in the sense of the law) validity statements). We are looking for alternate solutions to satisfy the requirements. The optimal solution would be the one - that will cause PKIX-compliant applications to produce the validity statements on signatures as required by the law - without requiring private or proprietary extended validation mechanisms in the client applications - and would not require end user certificate and token updates in the field in case of emergency. Simon Tardell is suggesting a scheme with redundant user certificates issued by independently secured CA keys. We will have a closer look at that. I think PKIX is interested to provide specifications that solve problems. Here is one. Hopefully it is now clear enough explained. Can it be solved within the framework of existing PKIX specifications ? Denis response indicates there is one solution. A pointer to it would be fine. If it really requires just changing a few words in the law, well the law has not been given by God. It would be helpful to know which words. Denis Pinkas Kopie: Stephen Kent , ietf-pkix@imc.org Thema: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - 06.02.2003 09:49 (RTCS) See comments at the end. > We would love to see > someone demonstrating to us that the legal obligations already explained > maybe implemented one way or the other in compliance with PKIX. As Steve already mentioned, "PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised". There is indeed a real technical problem in case of a CA key compromise, but the German Law mandates a solution whereas it should have stated requirements only, instead of a technical solution. There exists a solution to the problem, but of course it cannot fit with the current text from the German Law: a few sentences from the German Law should be changed. Denis From owner-ietf-pkix@mail.imc.org Fri Feb 7 12:01:42 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15520 for ; Fri, 7 Feb 2003 12:01:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17GZOb12088 for ietf-pkix-bks; Fri, 7 Feb 2003 08:35:24 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17GZNd12082 for ; Fri, 7 Feb 2003 08:35:23 -0800 (PST) Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h17GYxOQ004968; Fri, 7 Feb 2003 17:34:59 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <00b901c2cec5$82aa6740$0500a8c0@arport> From: "Anders Rundgren" To: "Denis Pinkas" , Cc: , "Stephen Kent" References: Subject: Re: A challenge Date: Fri, 7 Feb 2003 17:25:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Olaf, To have redundant certificates in case the CA goes haywire seems like a very peculiar solution and will force users to select the proper certificate. Which is? There is really only one reasonable cure: To manage CA keys and compromises the way most other CAs would. If a CA has a key compromise it may not even be aware of it... BTW, I don't see that CA key protection can be that hard. Proper procedures (TONS of such have been written) and HW crypto should do the trick. Identity impersonation and its consequences is something that you should really bother about. And liabilities in case of such. Regarding cards: make them upgradable over the net. You must anyway be prepared for distributing certificates over net in order to address the "Mobile Internet". Anders ----- Original Message ----- From: To: "Denis Pinkas" Cc: ; "Stephen Kent" Sent: Friday, February 07, 2003 15:59 Subject: A challenge Introductory note (hello, stephen, please read): I am not asking for updates, changes to or extensions of existing specs and standards. I just put those specs to a challenge and want to see how they respond. And I changed the topic, as we are now far away enough from discussing RTCS. The german law does not really mandate a white list check. It mandates maintaining the ability of end users to sign after a CA key compromise. Thomas has explained the law in detail. The intention of the law is to keep the user unharmed by CA key compromise. It would be fine to have at least a solution that satisfies the intention. And large-scale card issuers have as well an interest in a scheme that does not force them to replace huge volumes of smartcards in a very short period of time. And unlikely as it may be one needs a persuading emergency plan for CA key compromise if several million smartcards in the field are relying on this key security. The "chain model" that is currently in use in Germany and has the white-list mechanism in it is satisfying the requirements, but it is not compliant with PKIX and has some other problems as well (the need for online-transactions for signature validation is increased, not law-aware applications produce deviating (wrong in the sense of the law) validity statements). We are looking for alternate solutions to satisfy the requirements. The optimal solution would be the one - that will cause PKIX-compliant applications to produce the validity statements on signatures as required by the law - without requiring private or proprietary extended validation mechanisms in the client applications - and would not require end user certificate and token updates in the field in case of emergency. Simon Tardell is suggesting a scheme with redundant user certificates issued by independently secured CA keys. We will have a closer look at that. I think PKIX is interested to provide specifications that solve problems. Here is one. Hopefully it is now clear enough explained. Can it be solved within the framework of existing PKIX specifications ? Denis response indicates there is one solution. A pointer to it would be fine. If it really requires just changing a few words in the law, well the law has not been given by God. It would be helpful to know which words. Denis Pinkas Kopie: Stephen Kent , ietf-pkix@imc.org Thema: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - 06.02.2003 09:49 (RTCS) See comments at the end. > We would love to see > someone demonstrating to us that the legal obligations already explained > maybe implemented one way or the other in compliance with PKIX. As Steve already mentioned, "PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised". There is indeed a real technical problem in case of a CA key compromise, but the German Law mandates a solution whereas it should have stated requirements only, instead of a technical solution. There exists a solution to the problem, but of course it cannot fit with the current text from the German Law: a few sentences from the German Law should be changed. Denis From owner-ietf-pkix@mail.imc.org Fri Feb 7 13:31:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17469 for ; Fri, 7 Feb 2003 13:31:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17I19O15618 for ietf-pkix-bks; Fri, 7 Feb 2003 10:01:09 -0800 (PST) Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17I18d15614 for ; Fri, 7 Feb 2003 10:01:08 -0800 (PST) Received: from smtp2.pacifier.net (smtp2 [64.255.237.172]) by mx4.pacifier.net (Postfix) with ESMTP id 28B2B6A63E; Fri, 7 Feb 2003 10:01:10 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id D4A3A6A44C; Fri, 7 Feb 2003 10:01:08 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Russ Housley'" , "'Bert Kaliski'" Cc: Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Date: Fri, 7 Feb 2003 09:59:13 -0800 Message-ID: <003301c2ce82$18efe340$0a0000c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Internet Mail Service (5.5.2653.19) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Gentlemen, 1. Can you make the title of the document another line longer? 2. Please consider adding the following textto section 1.2 p 3. "Note: It is not possible to restict the use of a key either RSASSA-PSS and anything else. The same is true of RSAES-OAEP." 3. In section 1.2 p 2 last sentence. I think it should be "signature and/or key transport". 4. In section 2.1, there is a par of paragraphs about the use of NULL or ABSENT in encoding the hash functions. There appears to be a conflict between the two paragraphs. The first says use ABSENT. The second says use NULL. One or the other should be omitted, I would perfer the second as the first is the "standard" way of doing things. The second would require changes in my encoder/decoder utility functions. 5. Section 3, para 1, last sentence: It appears to me that there should potentially be two different statements on conforming CAs. Some CAs will using RSASSA-PSS as the signing algorithm, while other will just encode a certificate with the RSASSA-PSS public key. Should these be seperated in conformant statements? 6. Section 3.1 maskGenAlgorithm. Please remove the statement "It MUST be an algorithm identifier". This is a tautology. 7. Section 3.2. I would like to see a different OID used for a signature value from that used to encode the public key. This makes it easier to process for encode/decode as there are not two structures with the same OID. 8. RSASSA-PSS-params and signature processing. I am confused about what should be done by a signature verifier/producer in checking the parameters of a signature againist the parameters of a signature. My first assumption was that all of the fields mattered and should be "equivalent". From reading the text I find that this is not the case and the saltLength is encoded in the certificate parameters but is wildcarded against the signature parameters. This type of behavior makes implementation difficult. My first assumption on this implemenation was a binary comparison. This would not work for a number of reasons the first being saltLength, the second being the requirements that I need to be able to match a defaulted parameter against an existing parameter (i.e. sha1Identifier present vs absent). 9. Section 3.1 maskGenAlgorithm. The text at the end of the paragraph is missing some cases that would seem to be logical. The following should be matched: ABSENT {id-mgf1} {id-mgf1, {id-sha1}} {id-mgf1, {id-sha1, NULL}} It would be MUCH simplier if the "stupid" cases could be removed, but I don't know if that would match your worldview. 10. Section 3.1 saltLength. There seems to be a mis-match between the default value in the ASN.1 structure and that in the text. The structure definition says 20. The description says the length of the hash output value. This implies that if I were to use md5 as in the hashAlgorithm field, the default value of the ASN.1 structure for saltLength would suddenly be 16 not 20. 11. Section 4.1, para 1 - missing id- from RSAES-OAEP in the first sentence. 12. Section 4.1, maskGenFunc - see comment 9. 13. Section 4.1, RSAES-OAEP-params comparison function. This comparison has some of the same problems as that of RSASSA-PSS. I don't know the proper way to compare pSourceFunc. I believe that the comparison here is dependent on the value of pSourceFunc.Algorithm. For a value of id-pSpecified, this field should be ignored. Are there other values (such as if nullOctetString is not of 0 length based on para 6 of the security considerations section). 14. Section 5. Please change "the parameters MUST be NULL" to "the parameters MUST be ABSENT". This matches SHA-1 convention. 15. ASN.1 Module: Organization: It helps if the parameters structure is in the same section as the OID that uses the structure. Looking from the top to the very bottom for the parameters is messy. 16. ASN.1 Module: All of the rSASSA-PSS-*-Identifier structures need to be changed to rSASSA-PSS-*-Identifier AlgorithmIdentifier ::= { id-RSASSA-PSS, rSASSA-PSS-*-params } rSASSA-PSS-*-params RSASSA-PSS-params ::= { *-hash, mgf1*Identifier, 20, 1} The second level of initialization cannot be done in 1988 because the structure is an ANY. 17. Section 7.1 [P1v2.1] Remove the first J. and the first comma. Jim From owner-ietf-pkix@mail.imc.org Fri Feb 7 23:54:14 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01575 for ; Fri, 7 Feb 2003 23:54:14 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h184QOd07468 for ietf-pkix-bks; Fri, 7 Feb 2003 20:26:24 -0800 (PST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h184QId07461 for ; Fri, 7 Feb 2003 20:26:18 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id XAA28650; Fri, 7 Feb 2003 23:26:18 -0500 (EST) Message-ID: <3E4486E3.4010500@mit.edu> Date: Fri, 07 Feb 2003 23:26:11 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlisle Adams , Stephen Farrell CC: ietf-pkix@imc.org, "Steven M. Bellovin" Subject: AD Review of draft-ietf-pkix-rfc2510bis-07.txt X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27613703C0B88490DDAC97C5" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27613703C0B88490DDAC97C5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am in the process of reviewing draft-ietf-pkix-rfc2510bis-07.txt. This review isn't yet complete, but far enough along to give you two key pieces of feedback. I will also request a formal IETF Wide Last Call, so that it can happen in parallel while you work on edits. 1. You need to split the References section into two sections. One labeled "Normative References" and the other "Informational References." The IESG has been asked by the RFC Editor to require this on all submissions. Normative references are those which describe some portion of feature of the protocol such that a protocol developer must read the normative reference in order to implement the protocol. A normative references is also one which directly influences the protocols in the referencing document such that a change in the document references would have an impact on the protocol being defined. 2. Section 2.2.2 states "and EE equipment MUST support the second scheme listed below." Can you more clearly define this, as in a references to a section number. Note: Below is not a formal comment Today one of the common ways of issuing certificates is via a user's web browser. Both Netscape/Mozilla and Internet Explorer have a mechanism for submitting a form that contains a public key (in some form of self signed object, aka a PKCS10 object) to a server, presumably a CA, which can then download either immediately or at some other time, a user's certificate. Typically a secret value is also transmitted with form post that is used to authenticate the user. Presumably this secret pass phrase has been delivered in a secure fashion. If this transaction occurs via an SSL connection, doesn't this provide sufficient strength to initially authenticate the user. The transaction itself doesn't need to be enciphered via a shared secret key, SSL provides the necessary protection. So my question is: "How does this fit in with this document?" (or did I miss something because I haven't read the whole document in detail yet). Thanks. -Jeff --------------enig27613703C0B88490DDAC97C5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+RIbp8CBzV/QUlSsRArzSAJoD2Apnw3FSg6MW5hg0FEt2yDVnTQCeJM3S ND4923oj2CgEw5pejvOelWw= =7kv+ -----END PGP SIGNATURE----- --------------enig27613703C0B88490DDAC97C5-- From owner-ietf-pkix@mail.imc.org Sat Feb 8 00:17:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01978 for ; Sat, 8 Feb 2003 00:17:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h184wv808114 for ietf-pkix-bks; Fri, 7 Feb 2003 20:58:57 -0800 (PST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h184wud08110 for ; Fri, 7 Feb 2003 20:58:56 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id XAA28814; Fri, 7 Feb 2003 23:56:42 -0500 (EST) Message-ID: <3E448E09.90108@mit.edu> Date: Fri, 07 Feb 2003 23:56:41 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Myers , Carlisle Adams , Dave Solo , David Kemp CC: IETF PKIX WG List , "Steven M. Bellovin" Subject: AD Review of draft-ietf-pkix-rfc2511bis-05.txt X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5A817ED5C34D4B748462A1C" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5A817ED5C34D4B748462A1C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have completed my review of this document and will request an IETF Wide Last Call. However as is the case with 2510bis, it needs to have its References section split into Normative and Non-Normative references. This can happen in parallel with the IETF Last Call, but I will expect a new Internet Draft with the references split. Thanks. -Jeff --------------enigD5A817ED5C34D4B748462A1C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+RI4J8CBzV/QUlSsRAkRrAKCk5eOpr9FrkHGFbh2PUIwev8El7gCgt4+J lNS5+6U6s/3tw4mZVf8WI40= =1x5b -----END PGP SIGNATURE----- --------------enigD5A817ED5C34D4B748462A1C-- From owner-ietf-pkix@mail.imc.org Sat Feb 8 17:48:06 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02435 for ; Sat, 8 Feb 2003 17:48:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h18MAAt12705 for ietf-pkix-bks; Sat, 8 Feb 2003 14:10:10 -0800 (PST) Received: from trinity.spray.se (trinity.spray.se [212.78.193.150]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h18MA1d12698 for ; Sat, 8 Feb 2003 14:10:02 -0800 (PST) Received: from Laptop.spray.se (1Cust119.tnt4.stk3.swe.da.uu.net [213.116.231.119]) by trinity.spray.se (Postfix) with ESMTP id 412D182FA18; Sat, 8 Feb 2003 23:09:52 +0100 (MET) Message-Id: <5.2.0.9.0.20030208225238.00bd3db0@pop.spray.se> X-Sender: stefan.retrospekt@spray.se@pop.spray.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 08 Feb 2003 23:05:45 +0100 To: Olaf.Schlueter@secartis.com, Denis Pinkas From: Stefan Santesson Subject: Re: A challenge Cc: ietf-pkix@imc.org, Stephen Kent In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, The moment you introduce RTCS you have obsoleted the whole concept of using X.509 certificates. The function of a certificate is to provide proof over time, during which, status service is provided. OCSP can relay the information of a CRL and has therefore a place in this structure as a service that can be provided by someone other than the CA. It seams that RTCS must be provided by the CA. If the CA is compromised, you can't trust the RTCS either (unless complex key structure is used), so no benefits there. If the CA is not compromised, the certificate is actually made obsolete since you don't use the certificate for any trust decission you don't require on-line from the CA at time of verificatrion. The whole concept of using certificates can thus be replaced with an on-line request for the subject public key, attributes and parameters from the CA at time of validation. It would be interesting to know the wording of the German Law requiring RTCS. It seams that it requires som other technology than X.509 certificates and thus would not be a subject for PKIX. /Stefan At 15:59 2003-02-07 +0100, Olaf.Schlueter@secartis.com wrote: >Introductory note (hello, stephen, please read): I am not asking for >updates, changes to or extensions of existing specs and standards. I just >put those specs to a challenge and want to see how they respond > >And I changed the topic, as we are now far away enough from discussing >RTCS > >The german law does not really mandate a white list check. It mandates >maintaining the ability of end users to sign after a CA key compromise >Thomas has explained the law in detail. The intention of the law is to keep >the user unharmed by CA key compromise. It would be fine to have at least >a solution that satisfies the intention. And large-scale card issuers have >as well an interest in a scheme that does not force them to replace huge >volumes of smartcards in a very short period of time. And unlikely as it >may be one needs a persuading emergency plan for CA key compromise if >several million smartcards in the field are relying on this key security > >The "chain model" that is currently in use in Germany and has the >white-list mechanism in it is satisfying the requirements, but it is not >compliant with PKIX and has some other problems as well (the need for >online-transactions for signature validation is increased, not law-aware >applications produce deviating (wrong in the sense of the law) validity >statements). We are looking for alternate solutions to satisfy the >requirements > >The optimal solution would be the one > >- that will cause PKIX-compliant applications to produce the validity >statements on signatures as required by the law >- without requiring private or proprietary extended validation mechanisms >in the client applications >- and would not require end user certificate and token updates in the field >in case of emergency > >Simon Tardell is suggesting a scheme with redundant user certificates >issued by independently secured CA keys. We will have a closer look at >that > >I think PKIX is interested to provide specifications that solve problems >Here is one. Hopefully it is now clear enough explained. Can it be solved >within the framework of existing PKIX specifications ? > >Denis response indicates there is one solution. A pointer to it would be >fine. If it really requires just changing a few words in the law, well the >law has not been given by God. It would be helpful to know which words > > > > > > Denis > Pinkas > > Olaf.Schlueter@secartis.com > ll.net> Kopie: Stephen Kent > , ietf-pkix@imc.org > Thema: Re: Antwort: Re: > Antwort: Re: Real-time Certificate Status Facility for OCSP - > 06.02.2003 > 09:49 (RTCS) > > > > > > > > > > >See comments at the end > > > > We would love to see > > someone demonstrating to us that the legal obligations already explained > > maybe implemented one way or the other in compliance with PKIX > >As Steve already mentioned, "PKIX is not in the habit of setting standards >to accommodate national level laws that may be ill advised" > >There is indeed a real technical problem in case of a CA key compromise, >but the German Law mandates a solution whereas it should have stated >requirements only, instead of a technical solution. There exists a solution >to the problem, but of course it cannot fit with the current text from >the German Law: a few sentences from the German Law should be changed > >Denis From owner-ietf-pkix@mail.imc.org Sun Feb 9 16:48:20 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07125 for ; Sun, 9 Feb 2003 16:48:20 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h19LMNe27891 for ietf-pkix-bks; Sun, 9 Feb 2003 13:22:23 -0800 (PST) Received: from mail4.it-norr.com (mail4.it-norr.com [80.244.64.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h19LMLd27887 for ; Sun, 9 Feb 2003 13:22:21 -0800 (PST) Received: from HansPC ([217.211.59.24]) by mail4.it-norr.com (IT-NORR Mail Cluster v2003) with SMTP id FJE37084 for ; Sun, 09 Feb 2003 22:22:13 +0100 From: "Hans Nilsson" To: Subject: RE: A challenge Date: Sun, 9 Feb 2003 22:22:04 +0100 Message-ID: <000c01c2d081$4e260bb0$6400a8c0@HansPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Olaf, You are explaining the German chain model witht the example of handling CA key compromise. Although allowing signing after CA key comprise is a case "handled" by the German law, I think a more important, and certainly more likely case, is the case of the CA just loosing their status as licensed/accredited CA from RegTP. In this case RegTP will revoke the CA certificate, but the user certificate should remain valid. In this very likely scenario, the users should be able of continuing using their key/certificate/smart card. And thus the chain model was invented. Incidentally, I guess that all commercial CA hierarchies face the same problem, but most ignore that. Have we ever seen an intermediate CA in the Micrsoft tree or other browser-installed tree having its CA certificate revoked because they no longer fulfill the Root CAs requirements in some way or another? I do not think so, because you would get a lot of angry peopole out there, who signatures suddenly would start become invalid. Once a CA is in there, it stays there :-) But the Germans draw the right conclusion, saying that if you issue a license, you must also have a method of withdrawing it. I have always argued that the Germans correctly identified the problem, but took the wrong solution to the solving it. Instead of revoking the CA certificate and declaring the EE certificates to still be valid, they *should not revoke* the CA certificates. By using the CA certificate not only as a statement of the fact that a certain CA holds a certain key, but also as a "certificate of license" that can be revoked at any time, they have "made their bed" in this ugly fashion. It is really a question of what semantics a CA certificate carries. I think it should only state the binding of identity/key (just like an EE certificate), nothing more. The status of the CA (licensed/accredited/supervised...) should be distributed in some other fashion (which is the subject of a European project within ETSI). Hans Nilsson > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of > Olaf.Schlueter@secartis.com > Sent: Friday, February 07, 2003 3:59 PM > To: Denis Pinkas > Cc: ietf-pkix@imc.org; Stephen Kent > Subject: A challenge > > > > > > > > Introductory note (hello, stephen, please read): I am not > asking for updates, changes to or extensions of existing > specs and standards. I just put those specs to a challenge > and want to see how they respond. > > And I changed the topic, as we are now far away enough from > discussing RTCS. > > The german law does not really mandate a white list check. It > mandates maintaining the ability of end users to sign after a > CA key compromise. Thomas has explained the law in detail. > The intention of the law is to keep the user unharmed by CA > key compromise. It would be fine to have at least a solution > that satisfies the intention. And large-scale card issuers > have as well an interest in a scheme that does not force them > to replace huge volumes of smartcards in a very short period > of time. And unlikely as it may be one needs a persuading > emergency plan for CA key compromise if several million > smartcards in the field are relying on this key security. > > The "chain model" that is currently in use in Germany and has > the white-list mechanism in it is satisfying the > requirements, but it is not compliant with PKIX and has some > other problems as well (the need for online-transactions for > signature validation is increased, not law-aware applications > produce deviating (wrong in the sense of the law) validity > statements). We are looking for alternate solutions to > satisfy the requirements. > > The optimal solution would be the one > > - that will cause PKIX-compliant applications to produce the > validity statements on signatures as required by the law > - without requiring private or proprietary extended > validation mechanisms in the client applications > - and would not require end user certificate and token > updates in the field in case of emergency. > > Simon Tardell is suggesting a scheme with redundant user > certificates issued by independently secured CA keys. We will > have a closer look at that. > > I think PKIX is interested to provide specifications that > solve problems. Here is one. Hopefully it is now clear enough > explained. Can it be solved within the framework of existing > PKIX specifications ? > > Denis response indicates there is one solution. A pointer to > it would be fine. If it really requires just changing a few > words in the law, well the law has not been given by God. It > would be helpful to know which words. > > > > > > > Denis Pinkas > > > Olaf.Schlueter@secartis.com > > ll.net> Kopie: > Stephen Kent , ietf-pkix@imc.org > > Thema: Re: > Antwort: Re: Antwort: Re: Real-time Certificate Status > Facility for OCSP - > 06.02.2003 09:49 (RTCS) > > > > > > > > > > > > > > See comments at the end. > > > > We would love to see > > someone demonstrating to us that the legal obligations already > > explained maybe implemented one way or the other in compliance with > > PKIX. > > As Steve already mentioned, "PKIX is not in the habit of > setting standards to accommodate national level laws that may > be ill advised". > > There is indeed a real technical problem in case of a CA key > compromise, but the German Law mandates a solution whereas it > should have stated requirements only, instead of a technical > solution. There exists a solution to the problem, but of > course it cannot fit with the current text from the German > Law: a few sentences from the German Law should be changed. > > Denis > > > > > > From owner-ietf-pkix@mail.imc.org Sun Feb 9 22:34:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13941 for ; Sun, 9 Feb 2003 22:34:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A33Rn04243 for ietf-pkix-bks; Sun, 9 Feb 2003 19:03:27 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A33Qd04238 for ; Sun, 9 Feb 2003 19:03:26 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1A33KMI024473; Mon, 10 Feb 2003 16:03:20 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1A33KF15484; Mon, 10 Feb 2003 16:03:20 +1300 Date: Mon, 10 Feb 2003 16:03:20 +1300 Message-Id: <200302100303.h1A33KF15484@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Olaf.Schlueter@secartis.com, pgut001@cs.auckland.ac.nz Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies for the late reply, I've got a large pile of conference papers to work through] Olaf.Schlueter@secartis.com writes: >The main difference between RTCS and standard OCSP is that RTCS is answering >a different question and thus is providing different information. It is a >white list check and a black list check. It answers the question "Is this >certificate issued correctly AND not revoked ?" I want to emphasise yet again that it does this purely because that's all that an authenticated dictionary is capable of. This is not a Conspiracy to Undermine PKIX or a Communist Plot to Annoy Denis, it works that way because that's all the technology allows - if you're running queries straight from a live CA store (or more likely a snapshot thereof), all you can say is "present" or "not present". The converse holds from a CRL-based source. >The debate will probably continue on the topic "Do we really need a white >list check?". In the common PKIX (and X.509) paradigm "CA key security is >perfect" the answer probably is "no". A certificate carrying a signature of >a trusted CA is valid, no need to ask the CA again. I wasn't really that concerned with CA key compromise (if that happens in an X.509 PKI, you're pretty much screwed no matter what), but more with things like manufactured-cert and -CRL attacks. This is fairly simple with most widely-used PKI software: - Implicit universal cross-certification in MSIE/Netscape/CryptoAPI/etc means any CA can issue certs claiming to be from any other CA. Since the other CA never issued them (it doesn't even know that they exist), they can't be invalidated via a CRL. - In practice it's even easier than that. From the NANOG list: It's even worse, a fake certificate from a man in the middle causes a trustworthy warning! If a certificate is not co-signed by any of the Browser compiled-in authorities, the Browsers will just ask: "...do you want to trust ". The hacker is completely free to fill in when he creates his own certificate on the server side (using plain openssl). This will be the only popup as the fake certificate will match the faked URL. Did M$ expect people to say "no" to the fake question "Do you want to trust Citibank" when they are in fact trying to connect to the real Citibank site? The default behavior of a browser should be to reject unsigned certificates and not even ask the question. Currently, there is even no warning that was learned from an unsigned certificate. - Someone else (who probably doesn't want his name dragged into this) has pointed out that this can be extended, via section 4.2.1.14 of RFC 3280, into a manufactured-CRL attack in which you can revoke any arbitrary cert (including the other CA's root). These are attacks that RTCS will help with, not specifically CA key compromise (or sale to a third party, which is a far more common occurrence). >In Germany the german signature law [...] I ploughed through the exact text for this on the weekend. By coincidence the status values appear to be identical to the RTCS ones. I'd never read that text until a few days ago, so RTCS was no attempt to copy the German law requirements. Peter. From owner-ietf-pkix@mail.imc.org Sun Feb 9 22:35:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13967 for ; Sun, 9 Feb 2003 22:35:25 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A36Xg04272 for ietf-pkix-bks; Sun, 9 Feb 2003 19:06:33 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A36Ud04268 for ; Sun, 9 Feb 2003 19:06:31 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1A36TMI024591; Mon, 10 Feb 2003 16:06:29 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1A36P917144; Mon, 10 Feb 2003 16:06:25 +1300 Date: Mon, 10 Feb 2003 16:06:25 +1300 Message-Id: <200302100306.h1A36P917144@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, michael@stroeder.com Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: =?ISO-8859-1?Q?Michael_Str=F6der?= writes: >Using a 'web service' (whatever we might agree in the future if ever on what >that really is) will just migrate the very same problems to another service. >That's what folks should understand *before* trying to solve problems by >defining yet another standard with yet another buzz-word. Good point. >And I also agree with David that web services just circumvents firewalls by >simple HTTP tunneling. That's not a solution, it's a real security risk >making content filtering and very complex proxying necessary in the long run. It depends what your definition of "web services" is. You're referring to something like SOAP (let's call it "active HTTP" here). Things like the HTTP certstore interface are just a straight HTTP GET ("passive/pure HTTP"), which fits the classic HTTP model, so you need to distinguish between these two types. As a security (rather than just PKI) person, I agree that active HTTP is going to be a severe problem, and I'd never allow it onto any of my networks or systems. >If someone's to blame for lack of PKI acceptance it's this WG for not >reaching consensus on very basic issues [...] and inventing new competing, >even more complex standards all the time. Let me offer another view. To paraphrase Steve Kent, "Let 10,000 RFCs bloom". We have > 1,400 pages of PKIX RFCs and drafts already, the majority of which are completely ignored outside the community that pushed for their adoption, so eventually by a process of natural selection we'll see what survives. Experience has shown that implementors will implement what they want to implement and disregard the rest, and the results are remarkably consistent - most implementations end up ignoring the same RFCs, and sections of RFCs, without any overt advance agreement to do so, and regardless of whether it's standards-track or nothing-track, MUST or MAY. Here's how this would work: Make all PKIX RFCs (no exception) "Experimental". After 18 months, try and find 3 independant implementations from competing vendors in different countries (to reduce false positives from things like 3 German vendors creating Sig*-compliant software). If less than 3 implementations are found, leave it as "Experimental" (raining fire and brimstone on the RFC authors is left as an optional extra). If >= 3 implementations that fit the bill are found, mark it "Informational". If >= 5 implementations are found, with at least one being open-source (to reduce false positives where "implementations" consist of press releases from members of a vendor consortium), mark it "Standards-track". That's at the macroscopic level. At the microscopic level, do the same thing with MAY, etc. This will cause no change in the implementation status quo, but ensures that the published RFCs at least contain some vague approximation to reality. Peter. From owner-ietf-pkix@mail.imc.org Sun Feb 9 23:15:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14588 for ; Sun, 9 Feb 2003 23:15:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A3tUJ05213 for ietf-pkix-bks; Sun, 9 Feb 2003 19:55:30 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A3tTd05209 for ; Sun, 9 Feb 2003 19:55:29 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1A3tRMI025454; Mon, 10 Feb 2003 16:55:27 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1A3tTK11181; Mon, 10 Feb 2003 16:55:29 +1300 Date: Mon, 10 Feb 2003 16:55:29 +1300 Message-Id: <200302100355.h1A3tTK11181@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jkazin@parsippany.sns.slb.com, steve.hanna@sun.com Subject: Re: Path validation decision based on notAfter Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hanna writes: >Also, I don't think Entrust or Microsoft can avoid issuing such a >"problematic" certificate. The CA that issues the end-entity certificate >(let's call it Andrew) may not know about all CA certificates that have >Andrew as the subject. Even if the CA somehow knew of all such CA >certificates at the time it issued the end-entity certificate, it couldn't >prevent another CA from later issuing a short-lived CA certificate with >Andrew as the subject. When I looked at this, it seemed like a coin-flip decision: There was no clear opinion on the list as to which was better. I asked a few users, and they couldn't identify any strong reason to do it one way or the other either. In the end I decided to do validity-period nesting because (again based on user feedback) it would cause less confusion and make cert management easier if the EE validity was constrained to that of the CA cert that issued it - you don't get users confused over why their cert has expired even though the validity period shows it hasn't, and you know that all the EE certs will automatically roll over once the CA cert rolls over. Peter. From owner-ietf-pkix@mail.imc.org Mon Feb 10 05:57:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04056 for ; Mon, 10 Feb 2003 05:57:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AAVOi16770 for ietf-pkix-bks; Mon, 10 Feb 2003 02:31:24 -0800 (PST) Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AAVMd16755 for ; Mon, 10 Feb 2003 02:31:22 -0800 (PST) Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id h1AAeZD07100; Mon, 10 Feb 2003 11:40:35 +0100 (MET) Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAAiaW2n; Mon, 10 Feb 03 11:40:01 +0100 Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h1AAUVw04044; Mon, 10 Feb 2003 11:30:32 +0100 (MET) Message-ID: <3E477F47.A5BF7909@trustcenter.de> Date: Mon, 10 Feb 2003 11:30:31 +0100 From: Juergen Brauckmann Organization: TC TrustCenter AG X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson CC: ietf-pkix@imc.org Subject: Re: A challenge References: <5.2.0.9.0.20030208225238.00bd3db0@pop.spray.se> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by venus.trustcenter.de id h1AAUVw04044 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1AAVNd16764 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Stefan Santesson wrote: > It would be interesting to know the wording of the German Law requiring > RTCS. It seams that it requires som other technology than X.509 > certificates and thus would not be a subject for PKIX. > > /Stefan I found an english translation here: http://www.kuner.com/data/sig/sig_august_16.html Interesting paragraph: §19(6) Here you can find an unofficial translation of the accompanying ordinance, which is also important: http://www.sng.it/acrobat/it%20security/Leggi/Signaturverordnung%20neu%20(English%20unofficial%20version).pdf §15(3) says: "The information according to sentence 1 must include whether the checked qualified certificates were present at the given time in the directory of qualified certificates, and not locked." (locked => revoked) Regards, Juergen From owner-ietf-pkix@mail.imc.org Mon Feb 10 11:16:22 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14036 for ; Mon, 10 Feb 2003 11:16:22 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AFZQM02043 for ietf-pkix-bks; Mon, 10 Feb 2003 07:35:26 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AFZMd02037 for ; Mon, 10 Feb 2003 07:35:24 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id C25EC10F6DF; Mon, 10 Feb 2003 16:35:14 +0100 (CET) From: "Simon Tardell" To: "'Anders Rundgren'" , "'Denis Pinkas'" , Cc: , "'Stephen Kent'" Subject: RE: A challenge Date: Mon, 10 Feb 2003 16:35:04 +0100 Message-ID: <032f01c2d119$fbf12e30$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00b901c2cec5$82aa6740$0500a8c0@arport> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Anders, > To have redundant certificates in case the CA goes haywire > seems like a very peculiar solution and will force users to > select the proper certificate. Which is? Not at all. A signature is made with a key, not a certificate. As long as the identity of the certificate is not signed into the message, any certificate that corresponds to the right key can be used to validate the signature. The certificate may be sent with the signed message or obtained from somewhere else. It is largely the headache of the verifier. The certificate that is used to verify the signature may even be issued after the signature is made. (And in fact, this would be a reasonable possible consequence of having CA redundancy -- after some time it could happen that both CAs that certify a certain key-identity-binding are replacement CAs deployed after the first signatures were made with the card) For some reason the common paradigm is to let users chose a certificate associated with a key to imply the key. This practice requires the certificate to be present at the client. Or rather, *a* certificate. The certificate could be e.g. a self-signed cert (issued by the smart card itself at production time just to supply a GUI handle to applications looking for, and to supply a subject name for the end entity to claim, if the application needs one). This would remove the need to ever update the smart card. Or, as Sun would say, the network is the computer. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Mon Feb 10 12:02:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15794 for ; Mon, 10 Feb 2003 12:02:27 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AGRYC04415 for ietf-pkix-bks; Mon, 10 Feb 2003 08:27:34 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AGRWd04411 for ; Mon, 10 Feb 2003 08:27:32 -0800 (PST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1AGQuCq025326; Mon, 10 Feb 2003 08:26:56 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <133CKR30>; Mon, 10 Feb 2003 08:27:34 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= , ietf-pkix@imc.org Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Mon, 10 Feb 2003 08:27:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0036_01C2D0F7.676C8560"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C2D0F7.676C8560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Anders Rundgren wrote: > > But the _real_ problem with the X.500 model is that it builds > > on the assumption that organizations want to publish information > > for others to search. > > Again: This is not a specific problem with the X.500 model. > It's a general > problem with certificate retrieval across organizational boundaries. I don't see this as an objection to the X.500/LDAP architecture. However it is a severe restriction on deployment. Since the argument for reuse of LDAP is that it is deployed and the excuse for reuse of X.500 is that it is going to be deployed the fact that enterprises will not allow public access to anything that looks like a directory is very relevant. Not making your directory world readable is probably more important as an enterprise security measure than firewall deployment. > > Using a 'web service' (whatever we might agree in the future > if ever on what > that really is) will just migrate the very same problems to > another service. First off, there is considerable agreement on the definition of Web services. They are machine/machine protocols that are encapsulated in SOAP messaging. Note that there is no requirement to run over HTTP. I think that in the long run we will move to DIME or something similar. > That's what folks should understand *before* trying to solve > problems by > defining yet another standard with yet another buzz-word. Take a look at the XKMS specs. The problem is really well understood at this point. > And I also agree with David that web services just > circumvents firewalls by simple HTTP tunneling. That is a misconception, although several folk like Bruce the sage of Minnessota have been plugging away at it. First off Web Services need not be layered on HTTP. In fact DIME is a much cleaner interface. But HTTP has some near term advantages. Secondly a large part of the Web Services architecture is all about how to route messages through firewalls, the visibility that messages must have, etc. etc. There is an assumption that the firewall does somewhat more than simply block certain ports. > PKI acceptance is yet another issue independent of X.500 directories. No, the X.500 linkage is the single biggest barrier. It has led to more failed PKI deployments in my experience than any other. The customers have wanted to deploy a PKI, they are captured by a directory vendor. They spend three years arguing over theri DIT instead and erroneously conclude that PKI is hard to deply. For PKI deployment to succeed you have to take X.500 and LDAP deployment out of the critical path. > If someone's to blame for lack of PKI acceptance it's this WG for not > reaching consensus on very basic issues No, that is not a factor in PKI deployment. This list is no longer a factor in the development of the PKI world. The basic certificate standards are already deployed in Windows 2000, Java and the rest. The job of this group is to document the reality that has been created. This group cannot influence changes in the PKI infrastructure, that has already happened. This by the way is the IETF way. HTTP was only standardized some six years after the protocol was ubiquitous. > (feel free to check the mailing list > archive *excluding* the dumb X.500 bashing of last three months) and Was there a previous X.500 bashing thread? I don't think so. We have only been on this thread since the new year. > And no, the problems will not automagically be solved by XML, > XKMS, favourite buzz-words here...>. The XML syntax is neither here nor there. I used it simply because if I ask an engineer to learn ASN.1 they start preparing their resume, engineers ask me if they can learn XML. Whether or not XML is actually superior it has won by any empirical standard. Choosing to use ASN.1 at this point is like choosing to use EBSDIC instead of ASCII. I hope that we put rather more into the design of XKMS than simply rehashing PKIX in XML. In fact that was the one thing that the original charter did not allow us to do. Phill ------=_NextPart_000_0036_01C2D0F7.676C8560 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxMDE2 MjczM1owIwYJKoZIhvcNAQkEMRYEFHWKtB07tZqatJZNH+UpyoJ1jjkbMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAh2E5sTdGZwFr2oHChhMkPfUwaSSE7XCIXn/7fVY3zuDGeYZY KipPhZFXixfKUilboLZA47TheT7TPXWGxkmaFeMqLaJbmh3W4MgNM+uN/YAcIqjnjt5tWobeZEva g2aJ4b125FB9miuQTTzwdtEaJzAXs9YqkLW7tZLevCbCvR0AAAAAAAA= ------=_NextPart_000_0036_01C2D0F7.676C8560-- From owner-ietf-pkix@mail.imc.org Mon Feb 10 16:14:45 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26158 for ; Mon, 10 Feb 2003 16:14:44 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AKmup17978 for ietf-pkix-bks; Mon, 10 Feb 2003 12:48:56 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AKmtd17974 for ; Mon, 10 Feb 2003 12:48:55 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24887; Mon, 10 Feb 2003 15:45:14 -0500 (EST) Message-Id: <200302102045.PAA24887@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Certificate Management Protocols to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 2003 15:45:14 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Certificate Management Protocols as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-07.txt From owner-ietf-pkix@mail.imc.org Mon Feb 10 16:16:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26211 for ; Mon, 10 Feb 2003 16:16:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AKwru18263 for ietf-pkix-bks; Mon, 10 Feb 2003 12:58:53 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AKwqd18258 for ; Mon, 10 Feb 2003 12:58:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25424; Mon, 10 Feb 2003 15:55:12 -0500 (EST) Message-Id: <200302102055.PAA25424@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 2003 15:55:11 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-05.txt From owner-ietf-pkix@mail.imc.org Mon Feb 10 19:37:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02413 for ; Mon, 10 Feb 2003 19:37:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1B0G6A23740 for ietf-pkix-bks; Mon, 10 Feb 2003 16:16:06 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B0G4d23736 for ; Mon, 10 Feb 2003 16:16:04 -0800 (PST) Subject: RE: A challenge To: "Simon Tardell" Cc: "'Anders Rundgren'" , "'Denis Pinkas'" , ietf-pkix@imc.org, "'Stephen Kent'" , Olaf.Schlueter@secartis.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Mon, 10 Feb 2003 17:18:09 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/10/2003 07:17:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: in fact ... any trusted source for the key can be used to validate the signature. a major point of the certificate is a business process that binds something else to the meaning of the signature (especially in an offline environment when there aren't recourse to online authoritative reference). in the asuretee scenario ... the same hardware token (key) can be registered (aka the registration authority business process) with multiple different authoritative agencies .... potentially providing different bindings for signatures based on the context that the signature is used in. in the encryption scenario (as opposed to the digital signature case), the sender already needs to have a table of public keys (which may or may not be in certificate form .... or stored already in un-encoded form for convinient usage) ... and must select the recipient's public key from the table. a similar process is also possible in the digital signature case for something like a x9.59 financial transaction .... the financial instituion can have pre-decoded the certificate and stored it in the account record at the time the consumer registers the account. It is then no longer necessary for the client to transmit the certificate as part of a digitally signed x9.59 financial transaction. discussion of previously registered certification .... as well as (digital signature) certificates that have been compressed to zero bytes http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 Relying-Party Certification Business Practices -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm "Simon Tardell" on 2/10/2003 8:35 am wrote: Anders, > To have redundant certificates in case the CA goes haywire > seems like a very peculiar solution and will force users to > select the proper certificate. Which is? Not at all. A signature is made with a key, not a certificate. As long as the identity of the certificate is not signed into the message, any certificate that corresponds to the right key can be used to validate the signature. The certificate may be sent with the signed message or obtained from somewhere else. It is largely the headache of the verifier. The certificate that is used to verify the signature may even be issued after the signature is made. (And in fact, this would be a reasonable possible consequence of having CA redundancy -- after some time it could happen that both CAs that certify a certain key-identity-binding are replacement CAs deployed after the first signatures were made with the card) For some reason the common paradigm is to let users chose a certificate associated with a key to imply the key. This practice requires the certificate to be present at the client. Or rather, *a* certificate. The certificate could be e.g. a self-signed cert (issued by the smart card itself at production time just to supply a GUI handle to applications looking for, and to supply a subject name for the end entity to claim, if the application needs one). This would remove the need to ever update the smart card. Or, as Sun would say, the network is the computer. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Tue Feb 11 07:32:31 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01190 for ; Tue, 11 Feb 2003 07:32:31 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BBnh113818 for ietf-pkix-bks; Tue, 11 Feb 2003 03:49:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BBnfd13814 for ; Tue, 11 Feb 2003 03:49:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28650; Tue, 11 Feb 2003 06:45:58 -0500 (EST) Message-Id: <200302111145.GAA28650@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldap-crl-schema-00.txt Date: Tue, 11 Feb 2003 06:45:58 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs Author(s) : D. Chadwick, M. Sahalayev Filename : draft-ietf-pkix-ldap-crl-schema-00.txt Pages : 0 Date : 2003-2-10 This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry. An object class is defined for this CRL entry. Each attribute type uses an existing LDAP syntax, so that new matching rules do not need to be defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldap-crl-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10132959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-crl-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132959.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Tue Feb 11 09:47:12 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06825 for ; Tue, 11 Feb 2003 09:47:11 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BECdf21821 for ietf-pkix-bks; Tue, 11 Feb 2003 06:12:39 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BECbd21815 for ; Tue, 11 Feb 2003 06:12:37 -0800 (PST) Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id h1BECWJ02049; Tue, 11 Feb 2003 15:12:32 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Tue Feb 11 15:12:32 2003 Subject: Antwort: Re: A challenge To: Stefan Santesson Cc: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Tue, 11 Feb 2003 14:31:49 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 11.02.2003 15:12:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, first, to avoid confusion: RTCS is Peter's idea and he invented it for a different purpose. Second, you are right, a white list check if applied every time is obsoleting the signature on the certificate. The signature in the certificate allows you to decide whether to rely on the certificate integrity and correct issuance. Normally. But if the CA's public key is no longer trustworthy you are in trouble, you have to reject all certificates of that CA then as you no longer can distinguish correct certificates from forged certificates. In that case a white list check (and that is how it is applied in some systems in Germany today) provides a second resort. The (German)OCSP response you get is protected by another still trustworthy key with independent security. A signed (German)OCSP response with status for a specific certificate is a "kind of" certificate on its own. Once you have obtained it you can reuse it later on for checking as long as the OCSP responder's signing key remains trustworthy (at least to check signatures that have been created before the point in time the OCSP response has been created), To check later signatures you can use a PKIX-compliant OCSP responder, as the fact that a certificate is on a white list will never change (but revocation state may do). As far as I understand RTCS in its current shape could be used the same way. I do not really favour introducing white list checking into PKI systems.The introduction of white list checking into PKIX would be an alteration of the PKIX model. It would cause confusion as with white list checking in PKIX you would have two different ways to verify a certificate: one way based on local trusted key repositories and CRLs, another way extended by a white list. This is probably the reason why most people on this list are rejecting the idea. I just want to illustrate that the idea of a white list is not as senseless and paradox as it looks on first sight. And unfortunately the real German system is not exactly behaving the way as described above. At the root-level the independent key security is not given, or more exactly, most law-aware applications do not treat the root directory key as an independent trusted key. They ask for a certificate of this key signed by the root key. Stefan Santesson t@spray.se> Kopie: ietf-pkix@imc.org, Stephen Kent Thema: Re: A challenge 08.02.2003 23:05 Olaf, The moment you introduce RTCS you have obsoleted the whole concept of using X.509 certificates. The function of a certificate is to provide proof over time, during which, status service is provided. OCSP can relay the information of a CRL and has therefore a place in this structure as a service that can be provided by someone other than the CA. It seams that RTCS must be provided by the CA. If the CA is compromised, you can't trust the RTCS either (unless complex key structure is used), so no benefits there. If the CA is not compromised, the certificate is actually made obsolete since you don't use the certificate for any trust decission you don't require on-line from the CA at time of verificatrion. The whole concept of using certificates can thus be replaced with an on-line request for the subject public key, attributes and parameters from the CA at time of validation. It would be interesting to know the wording of the German Law requiring RTCS. It seams that it requires som other technology than X.509 certificates and thus would not be a subject for PKIX. /Stefan At 15:59 2003-02-07 +0100, Olaf.Schlueter@secartis.com wrote: >Introductory note (hello, stephen, please read): I am not asking for >updates, changes to or extensions of existing specs and standards. I just >put those specs to a challenge and want to see how they respond > >And I changed the topic, as we are now far away enough from discussing >RTCS > >The german law does not really mandate a white list check. It mandates >maintaining the ability of end users to sign after a CA key compromise >Thomas has explained the law in detail. The intention of the law is to keep >the user unharmed by CA key compromise. It would be fine to have at least >a solution that satisfies the intention. And large-scale card issuers have >as well an interest in a scheme that does not force them to replace huge >volumes of smartcards in a very short period of time. And unlikely as it >may be one needs a persuading emergency plan for CA key compromise if >several million smartcards in the field are relying on this key security > >The "chain model" that is currently in use in Germany and has the >white-list mechanism in it is satisfying the requirements, but it is not >compliant with PKIX and has some other problems as well (the need for >online-transactions for signature validation is increased, not law-aware >applications produce deviating (wrong in the sense of the law) validity >statements). We are looking for alternate solutions to satisfy the >requirements > >The optimal solution would be the one > >- that will cause PKIX-compliant applications to produce the validity >statements on signatures as required by the law >- without requiring private or proprietary extended validation mechanisms >in the client applications >- and would not require end user certificate and token updates in the field >in case of emergency > >Simon Tardell is suggesting a scheme with redundant user certificates >issued by independently secured CA keys. We will have a closer look at >that > >I think PKIX is interested to provide specifications that solve problems >Here is one. Hopefully it is now clear enough explained. Can it be solved >within the framework of existing PKIX specifications ? > >Denis response indicates there is one solution. A pointer to it would be >fine. If it really requires just changing a few words in the law, well the >law has not been given by God. It would be helpful to know which words > > > > > > Denis > Pinkas > > Olaf.Schlueter@secartis.com > ll.net> Kopie: Stephen Kent > , ietf-pkix@imc.org > Thema: Re: Antwort: Re: > Antwort: Re: Real-time Certificate Status Facility for OCSP - > 06.02.2003 > 09:49 (RTCS) > > > > > > > > > > >See comments at the end > > > > We would love to see > > someone demonstrating to us that the legal obligations already explained > > maybe implemented one way or the other in compliance with PKIX > >As Steve already mentioned, "PKIX is not in the habit of setting standards >to accommodate national level laws that may be ill advised" > >There is indeed a real technical problem in case of a CA key compromise, >but the German Law mandates a solution whereas it should have stated >requirements only, instead of a technical solution. There exists a solution >to the problem, but of course it cannot fit with the current text from >the German Law: a few sentences from the German Law should be changed > >Denis From owner-ietf-pkix@mail.imc.org Tue Feb 11 11:50:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11146 for ; Tue, 11 Feb 2003 11:50:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BGMPw29922 for ietf-pkix-bks; Tue, 11 Feb 2003 08:22:25 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BGMLd29913 for ; Tue, 11 Feb 2003 08:22:21 -0800 (PST) Subject: RE: A challenge (addenda) To: "Simon Tardell" Cc: "'Anders Rundgren'" , "'Denis Pinkas'" , ietf-pkix@imc.org, "'Stephen Kent'" , Olaf.Schlueter@secartis.com, epay@ca0.net X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Tue, 11 Feb 2003 09:23:36 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/11/2003 11:23:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ref: http://www.garlic.com/~lynn/aadsm13.htm#13 in fact, i would assert that is one of the short comings of mistaken the certificate being the binding ... as opposed to representing the business process of having done the binding. in lots of businesses ... they will do their own binding business process .... based on their own business requirements. that is somewhat the appearance of the relying-party-only certificates as opposed to the earlier, one-size-fits-all, identity x509 certificates. the issue is that the relying-party-only certificates are very analogous to a bank issuing a payment card .... originally one for every account or type of account. this is in the old offline days .... the merchant (standing in for the bank) in an offline environment examined the card and checked it against a paper booklet negative list mailed out once a month or so. in the transition to the online environment, a magstripe was placed on the back of the certificate .... and online transactions were being performed directly with the bank. this representing somewhat of a schizophrenic identity for the piece of plastic .... since it now carried the characteristics of operating both in the offline environment (the plastic credential and the paper booklet) or in an online environment (the magstripe on the back). From a consumer perspective ... the incomplete migration to totally online .... has had a down side .... potentially tens of plastic cards needing to be carried around. The magstripe is just on the verge of not having to be unique. It still is shared-secret based (account number and pins) which standard security requires unique shared-secret for different security domains. A migration to totally online and a migration to non-shared-secret (say digital signature public key) would eliminate the security requirement for 1) unique physical certificate/credential that is used in offline situations by stand-in parties/merchants responsible for examining the validity of the (plastic) certificate and 2) unique shared-secret. The assertion is then that a single hardware token performing digital signature authentication can be used as binding device in multiple different contexts (since there is not the uniqueness security requirement that exists for shared-secret paradigms) and that the token would only require a certificate representing each of those binding contexts if the token were to be used in offline operations (requiring validation by 3rd parties not having access to the responsible binding authority). As long as the token was used in online transactions involving the business process that was also the binding authority .... or in business processes with entities that had online access to the binding authority ... then certificates representing such binding business processes are redundant and superfluous. So the scenario is some future environment that is extensively digitally signature authentication oriented with some token. Continuing to emulate the old offline paradigm where a unique token/certificate exists for each context potentially means that individuals carry hundreds of such tokens. This is somewhat analogous to the evolving copy protection paradigm of the early 80s where each application required that a unique floppy disk had to be inserted. If this were to continue into today's environment an individual would have hundreds of copy protection floppy disks .... and constantly swapping floppy disks ... simarily one could imagine having hundreds of hardware tokens and having to constantly swap them. Now there is some possibility of just returning to the simple, one-size-fits-all, identity x509 certificate. However, there is still the idea of binding a person to a specific bank account. Just because a person has a x509 identity certificate doesn't mean that they can draw money from every account at every bank (or the existance of a x509 certificate doesn't equate to being permitted to perform all possible business operations). If there is a single certificate ... and it represents all possible binding operations ... then either the information about all such bindings has to be carried in the same certificate ... or the bindings have to be available at some online location. So doing the mapping of the offline certificate paradigm to an online binding environment .... would imply that some value from the certificate is registered in the online binding registry/account-record. However, if some value is to be registered .... it is possible to have an account number and the binding registry directly registers the public key This bypasses the levels of indirection involved in registering something about a certificate which is offline representation of the business process of binding/registering something about the public key. If I were going to register something about a certificate in an online binding registry (say is a specific entity entitled to withdraw money from this specific bank account) .... and a public key certificate is just an offline representation of some other online binding registry/authority (that just possibly isn't always online or directly accessable) ... I assert that it is possible to register the public key directly and dispense with the levels of indirection related to registering anything about the certificate. So lots & lots of certificates ... each uniquely carrying some collection of possible binding attributes (like permissions, authorizations, etc). Or a few certificates .... that only carry a very few binding attributes related to a public key. Then individual operations carry online account records with the actual permissions and a mapping to some value in a certificate. However, it is possible in such situations to eliminate the indirection of registering the certificate that maps to the public key ... and just register the public key. Normally, levels of indirection help when they allow change w/o affecting all the binding registries .... aka in the internet domain name system .... I can use the host name www.something ... and not need to worry about it may having dozens of different ip addresses that can change over time. However, if i'm dealing with a certificate indirection infrastracture that I know is a direct mapping to a single public key and the same certificate will never mask a remapping to a totally different public key then I can bypass the certificate indirection and just record the public key. One such situation would be a generic employee certificate .... there are lots and lots of them .... all mapping to different public keys. There is an environment that doesn't have (or need) direcl access to the online employee binding registry and only cares whether somebody has a valid employee binding (represented by their generic employee certificate) but doesn't actually care who the employee is (and the situation is low-value enough that it doesn't require real-time access to the real employing binding registry). However, this has the down-side attribute that it represents the lots & lots of certificate paradigm. a unique generic certificate is required for each unique (low-value) domain (work, home, ISP login, specific website, etc). As soon as something like ISP login requires specific authorization information .... it is either in the certificate ... or in an online account record. If it needs to register a unique value from a certificate that is unique for each authorized public key ... then it can go ahead and register the public key directly and dispense with any registering of anything related to a certificate (and some other agency's binding operation). An ISP family certificate would work if it listed a dozen different public keys ... and the certificate could change the listed public keys in a trusted and reliable way that the ISP need never be aware that it was happeing. However, in the internet domain name scenario this works because it is an online registry .... there aren't these offline credentials (representing the binding process) with long lifetimes floating around that can go bad and potentially need constant checking for revokation. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix@mail.imc.org Tue Feb 11 12:01:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11549 for ; Tue, 11 Feb 2003 12:01:09 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BGTRl01131 for ietf-pkix-bks; Tue, 11 Feb 2003 08:29:27 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BGTNd01119 for ; Tue, 11 Feb 2003 08:29:24 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h1BGTBbF009494; Tue, 11 Feb 2003 17:29:11 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <00a401c2d1e9$5a3122f0$0500a8c0@arport> From: "Anders Rundgren" To: "Simon Tardell" , Cc: , "Torsten Hentschel" References: <032f01c2d119$fbf12e30$0a01a8c0@stl> Subject: Re: A challenge Date: Tue, 11 Feb 2003 17:19:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Simon, Aaah. So the cards would contain "redundant" certificates using the same keys. You also claim that one should not put certificates in signed messages as it is only the key that matters. That of course works from a cryptographic point of view. But RPs must have a way to associate they key with a name. A certificate does this function. "Something" must (or is usually assumed to) be asserted in signatures to notify where the issuer is to be found. Anyway, in Sweden this would *not* work as the 24h government uses the TTP-issued certificates to vouch for citizenship and citizen registration code. By doing that all authorities do not necessarily need to have the citizen-register on-line as the certificates themselves form sort of a "distributed citizen database". I also wonder if competing CAs actually "like" the idea to share EE-keys, be it an irrational consideration or not. ============================================ But frankly I see no future in smart cards of the type Germany is investing in. A mobile phone is such a tremendously more powerful "container" that allows users to do things that smart card owners cannot even _dream_ about. Since mobile phones are on-line by definition, static key and certificate schemes then become rather irrelevant. ============================================ Anders ----- Original Message ----- From: "Simon Tardell" To: "'Anders Rundgren'" ; "'Denis Pinkas'" ; Cc: ; "'Stephen Kent'" Sent: Monday, February 10, 2003 16:35 Subject: RE: A challenge Anders, > To have redundant certificates in case the CA goes haywire > seems like a very peculiar solution and will force users to > select the proper certificate. Which is? Not at all. A signature is made with a key, not a certificate. As long as the identity of the certificate is not signed into the message, any certificate that corresponds to the right key can be used to validate the signature. The certificate may be sent with the signed message or obtained from somewhere else. It is largely the headache of the verifier. The certificate that is used to verify the signature may even be issued after the signature is made. (And in fact, this would be a reasonable possible consequence of having CA redundancy -- after some time it could happen that both CAs that certify a certain key-identity-binding are replacement CAs deployed after the first signatures were made with the card) For some reason the common paradigm is to let users chose a certificate associated with a key to imply the key. This practice requires the certificate to be present at the client. Or rather, *a* certificate. The certificate could be e.g. a self-signed cert (issued by the smart card itself at production time just to supply a GUI handle to applications looking for, and to supply a subject name for the end entity to claim, if the application needs one). This would remove the need to ever update the smart card. Or, as Sun would say, the network is the computer. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Tue Feb 11 12:24:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12136 for ; Tue, 11 Feb 2003 12:24:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BH2FP02904 for ietf-pkix-bks; Tue, 11 Feb 2003 09:02:15 -0800 (PST) Received: from nalle.datum.nu ([217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BH2Dd02900 for ; Tue, 11 Feb 2003 09:02:13 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id C12C610F6DF; Tue, 11 Feb 2003 18:00:53 +0100 (CET) From: "Simon Tardell" To: "'Anders Rundgren'" , Cc: , "'Torsten Hentschel'" Subject: RE: A challenge Date: Tue, 11 Feb 2003 18:00:37 +0100 Message-ID: <03ea01c2d1ef$199613d0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00a401c2d1e9$5a3122f0$0500a8c0@arport> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Anders, > Simon, > Aaah. So the cards would contain "redundant" certificates using > the same keys. > > You also claim that one should not put certificates in signed > messages as it is only the key that matters. That of course > works from a cryptographic point of view. It works from an application point of view as well, I'd say. > But RPs must have a way to associate they key with > a name. A certificate does this function. "Something" must > (or is usually assumed to) be asserted in signatures to > notify where the issuer is to be found. Generally assumed to, yes. Must, no. The relying party only has to know what identity is claimed. That identity is used to look up certificates from whatever issuer the relying party trusts. It doesn't matter which issuer the client trusts, although it perhaps doesn't seem probable that there would be a certificate associated with the clients key that the client doesn't somehow trust the issuer of (but it is certainly possible). The clients' claimed identity can be encoded in a self-signed certificate, since not all signed formats have a separate field for "claimed identity". > Anyway, in Sweden this would *not* work as the 24h government > uses the TTP-issued certificates to vouch for citizenship and > citizen registration code. By doing that all authorities do > not necessarily need to have the citizen-register on-line as > the certificates themselves form sort of a "distributed > citizen database". That is of course utterly stupid. The authority pushes some of its processing complexity onto the client. On not onto the client machine, but the client human. Interestingly enough, in the physical world things are moving the other way. I renewed my passport recently and nowadays you don't have to bring a "personbevis" (a paper stating that there exists a person with my name and number). The police is online, they already know! > I also wonder if competing CAs actually "like" the idea to > share EE-keys, be it an irrational consideration or not. In the German case the idea was to force it on them by law. In a more general situation I can see that they would, issuing smart cards is a lot more expensive than issuing certs to a smart card issued by someone else. Simon. Simon Tardell, cell +46 70 3198319, simon@tardell.se From owner-ietf-pkix@mail.imc.org Wed Feb 12 02:05:28 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07980 for ; Wed, 12 Feb 2003 02:05:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C6V2r29654 for ietf-pkix-bks; Tue, 11 Feb 2003 22:31:02 -0800 (PST) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C6V1d29647 for ; Tue, 11 Feb 2003 22:31:01 -0800 (PST) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA12567 for ; Wed, 12 Feb 2003 17:30:54 +1100 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0htqm2; Wed Feb 12 17:30:29 2003 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA28203 for ; Wed, 12 Feb 2003 17:30:27 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0Q_lO_; Wed Feb 12 17:30:06 2003 Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA22408 for ; Wed, 12 Feb 2003 17:30:05 +1100 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Wed, 12 Feb 2003 16:29:36 +1000 Message-ID: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmail.telstra.com.au> Thread-Topic: I-D ACTION:draft-ietf-pkix-rsa-pkalgs-00.txt Thread-Index: AcK2YFPkqMGhILE6QFiPOQyHziK1EgbvYExg From: "Manger, James H" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1C6V2d29651 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Constraining the algorithms with which a key is used is good security practice so there is sense in including a constraint to this effect in a certificate. However, I am not sure that: a) the subjectPublicKeyInfo field should hold this constraint and b) the syntax for the constraint should be an Alg.Id. Jim Schaad's comments #8 and #13 (confusion about how to compare the parameters of a signature or encryption with the parameters from subjectPublicKeyInfo) are due to the constraint being specified with an Alg.Id, which is not quite appropriate (e.g. by including a saltLength field that is irrelevant). Consider other possible (& reasonable?) constraints that you may wish to express: 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 as the hash algorithm. [Cannot be expressed as RSASSA-PSS-params only has a single hashAlgorithm field] 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP encryption, but not with any other algorithms. [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] 3* Only use id-sha1-with-dss-signature for signing. [Cannot be expressed as this signature OID has NULL parameters, but {p, q, g} need to be specified.] 4* Tell your signing software only to use RSASSA-PSS with this key, but don't prevent some legacy apps from accepting your signature. [Cannot be expressed as legacy apps reject the cert as they don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, the constraint needs to be in a non-critical extension.] A better solution would be to define a new extension to hold the constraint. Mark it critical to guarantee enforcement of the constraint, or non-critical to supply the info but maintain some backward compatibility. algorithmConstraints EXTENSION ::= { SYNTAX AlgConstraintsSyntax IDENTIFIED By id-ce-algorithmConstraints } AlgConstraintsSyntax ::= ...???????... this is the hard bit A simple syntax would be: SEQUENCE OF OBJECT IDENTIFIER -- An Alg.Id is acceptable iff its OID is in the sequence. Or the same simple syntax with more complex semantics: SEQUENCE OF OBJECT IDENTIFIER -- An Alg.Id is acceptable iff its OID -- and all the OIDs of any other Alg.Ids -- in its parameters field (inc. defaults if absent) -- are all in the sequence Or something really generic: Filter -- see X.511 -- applied to a "virtual entry" containing just the Alg.Id in question Or... ---------- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Saturday, 8 February 2003 4:59 AM Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt ... ---------- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, 8 January 2003 12:30 AM Title : Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author(s) : R. Housley, B. Kaliski Filename : draft-ietf-pkix-rsa-pkalgs-00.txt Pages : 22 Date : 2003-1-6 This document supplements RFC 3279. It describes the conventions for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport algorithm, and additional one-way hash functions with the PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt From owner-ietf-pkix@mail.imc.org Wed Feb 12 03:52:51 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26398 for ; Wed, 12 Feb 2003 03:52:50 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C8WD617168 for ietf-pkix-bks; Wed, 12 Feb 2003 00:32:13 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C8WBd17158 for ; Wed, 12 Feb 2003 00:32:11 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id CAA10593; Mon, 17 Feb 2003 02:12:54 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1C8Vv902293; Wed, 12 Feb 2003 09:31:57 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E4A067C.9070905@authentidate.de> Date: Wed, 12 Feb 2003 09:31:56 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: A challenge References: <032f01c2d119$fbf12e30$0a01a8c0@stl> <2750407.1044980962718.JavaMail.root@email.authentidate.de> In-Reply-To: <2750407.1044980962718.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Anders, as of my knowledge some of your assumptions about "German way" / "German law" are wrong. > I also wonder if competing CAs actually "like" the idea to share > EE-keys, be it an irrational consideration or not. Perhaps you did not mean to refer to Germany with the statement above. But I answer it as if: EE-keys may not be shared. By law they are enforced to exist exactly once: in the control of its holder; nobody else may have enough information to reconstruct this key. As a consequence in practice the key resides on a mobile secure device: the smart card. Even if you wanted to talk about EE-certs (instead of EE-Keys): There is no requirement for CA Andrew to distribute the EE-certs issued by CA Berta within the directory of Andrew as well, unless the regulation authority explicitly tells to do so (this may only happen if Berta is closed due to misbehaviour or insolvency). > ============================================ > But frankly I see no future in smart cards of the type Germany > is investing in. A mobile phone is such a tremendously > more powerful "container" that allows users to do things > that smart card owners cannot even _dream_ about. Since > mobile phones are on-line by definition, static key and > certificate schemes then become rather irrelevant. > ============================================ Well, mobile phones contain smart cards, don't they? I do absolutely not see the dead end here. Kind regards, Torsten -- Torsten Hentschel [The positions of mine as outlined above are not neccessarily From owner-ietf-pkix@mail.imc.org Wed Feb 12 10:35:55 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06407 for ; Wed, 12 Feb 2003 10:35:54 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CEt3Z19930 for ietf-pkix-bks; Wed, 12 Feb 2003 06:55:03 -0800 (PST) Received: from ratatosk.pdc.kth.se (ratatosk.pdc.kth.se [193.10.159.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CEt0d19925 for ; Wed, 12 Feb 2003 06:55:00 -0800 (PST) X-Rcpt-To: unknown X-Mail-From: mulmo@pdc.kth.se X-Client: pb-d-128-141-47-136.cern.ch (128.141.47.136) Received: from fiololle.pdc.kth.se (pb-d-128-141-47-136.cern.ch [128.141.47.136]) (authenticated bits=0) by ratatosk.pdc.kth.se (8.12.6/8.12.6) with ESMTP id h1CEstuh214897; Wed, 12 Feb 2003 15:54:56 +0100 (CET) Reply-To: From: "Olle Mulmo" To: "Simon Tardell" , "'Anders Rundgren'" , Cc: , "'Torsten Hentschel'" Subject: RE: A challenge Date: Wed, 12 Feb 2003 15:54:49 +0100 Message-ID: <002d01c2d2a6$b0adf5f0$882f8d80@pdc.kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <03ea01c2d1ef$199613d0$0a01a8c0@stl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit What whitelist protocol did the police use? RTCS? :-) /Olle -----Original Message----- From: Simon Tardell Sent: den 11 februari 2003 18:01 [snip] Interestingly enough, in the physical world things are moving the other way. I renewed my passport recently and nowadays you don't have to bring a "personbevis" (a paper stating that there exists a person with my name and number). The police is online, they already know! From owner-ietf-pkix@mail.imc.org Wed Feb 12 16:07:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15685 for ; Wed, 12 Feb 2003 16:07:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CKjXL06038 for ietf-pkix-bks; Wed, 12 Feb 2003 12:45:33 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CKjTd06033 for ; Wed, 12 Feb 2003 12:45:29 -0800 (PST) Subject: Re: A challenge To: Torsten Hentschel Cc: Anders Rundgren , ietf-pkix@imc.org, epay@ca0.net X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 12 Feb 2003 13:47:08 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/12/2003 03:47:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I assert that the traditional smartcards are somewhat like dinosours ... the signal just hasn't reached the brain yet. I assert that the basic smartcard design point was during the '80s for a portable computing device .... that predated the availability of portable input/output capability. Basically you carried all the computing around in the 7816 smartcard form factor and used it at generic input/output stations. However, that market niche had disappeared sometime in the early 90s with the advent of portable input/output capability in the form of cellphones and PDAs. I would guess that up to that point there had been tens of billions of dollars in the technology that all had to be written off. To some extent the smartcard continues on with a little bit life of its own .... in part the investment has totally been written off .... and with zero-sum budgetting .... even if you only could leverage the earlier investment at a few cents on the dollar ... the technology continues to linger around. So one of the places to leverage essentially the 7816 investment was supporting transferrable personality for cellphones. However, in the past year or two there have been articles on the incremental cost that providing such a reader represents in cellphone manufactor. Furthermore, this transferrable personality implementation still has several gaps .... the phone can be lost/stolen, there can be physical/electronic failure in the smartcard, and even the contact interface represents additional points of failure for the cellphone. The story line went something like an online backup/restore of the personality subsumes all the function of the smartcard as well as addresses all the additional shortcomings .... while negating the need for having the additional cost of the smartcard interface (as well as eliminating a point of failure in the cellphone). The issue is that even with only needing a few cents on the dollar (compared to the original 7816 investment) .... the smartcard in the cellphone still can't address all the requirements .... and the online back/restore which does address all the requirements then, obsoletes the necessity for the smartcard. And, as per the cellphone business discussions, cellphone manufactors can save some additional pennies on the cellphone manufactor as well as eliminating a point-of-failure (the contact infrastructure for sliding the card in/out). There is a requirement to possibly uniquely identify the use of the cellphone. In the digital signature world ... that somewhat maps to a hardware token with an on-chip generated key-pair .... and the private key never leaves the device. This can be built into the cellphone .... either as ROM in an existing chip .... or as a separate chip somewhat like the TCPA strategy. So a scenario is that as part of online restore into a new cellphone .... either a previous key-pair is backed-up and restored .... or that the device unique key is then re-registered in all the places that the previous cell phone had been registered. And as per my previous post in the thread ... the registration/binding business process is actually independent of whether or not a certificate is issued ... aka the original certificate design point (from somewhat the same '80s era as original smartcard) was a way of representing the registration/binding business process for an offline environment (which had no direct access to the authoritative registry). http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) One problem is that even if the smartcard was purely restricted to the protection and digital signature use of a private key .... there still is the whole unresolved issue of lost/stolen devices ... and any moving parts (even just slipping card in/out past contacts) are more prone to failure than purely electronic operation. Note this is also given as one of the reasons for the migration to ISO 14443 and away from ISO 7816 is because of the mechanical failure issues ... especially in high-traffic areas. This brings up the whole issue of possible competing contactless technologies coming to bear .... 14443, 802.11, bluetooth, cellphone, etc. some tcpa related discussions http://www.garlic.com/~lynn/2002i.html#71 TCPA http://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card? also http://www.garlic.com/~lynn/index.html#aads has URL to a talk on assurance that i gave at the TCPA track at past intel developer's conference. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Torsten Hentschel on 2/12/2003 1:31 am wrote Hi Anders, ... snip ... > ============================================ > But frankly I see no future in smart cards of the type Germany > is investing in. A mobile phone is such a tremendously > more powerful "container" that allows users to do things > that smart card owners cannot even _dream_ about. Since > mobile phones are on-line by definition, static key and > certificate schemes then become rather irrelevant. > ============================================ Well, mobile phones contain smart cards, don't they? I do absolutely not see the dead end here. Kind regards, Torsten -- Torsten Hentschel [The positions of mine as outlined above are not neccessarily From owner-ietf-pkix@mail.imc.org Thu Feb 13 08:12:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11503 for ; Thu, 13 Feb 2003 08:12:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DCiiZ00733 for ietf-pkix-bks; Thu, 13 Feb 2003 04:44:44 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DCihd00729 for ; Thu, 13 Feb 2003 04:44:44 -0800 (PST) Received: from SJOSEPH (pcp239416pcs.elictc01.md.comcast.net [68.55.244.2]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan 7 2003)) with SMTP id <0HA80059IZEFDI@mtaout03.icomcast.net> for ietf-pkix@imc.org; Thu, 13 Feb 2003 07:44:39 -0500 (EST) Date: Thu, 13 Feb 2003 07:43:48 -0500 From: Al Arsenault Subject: Re: A challenge To: lynn.wheeler@firstdata.com, Torsten Hentschel Cc: Anders Rundgren , ietf-pkix@imc.org, epay@ca0.net Message-id: <008a01c2d35d$8e4d6010$6501a8c0@SJOSEPH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Lynn, Interesting message from you, as always. Fascinating predictions on the future. Only a few issues need to be raised, IMHO. :-) One of those issues relates to the whole "secure backup and restore" or "secure download" of credentials. That's currently an unsolved problem. Fortunately, IETF has a working group - SACRED - addressing that issue. While SACRED started out a couple of years ago with a lot of interest and enthusiasm, interest seems to have waned. There are only a few people actively participating, and the group is about to wrap up with its solution. While I am others hope that the proposed solution will succeed and solve parts of the problem, it's not a complete solution (e.g., it addresses only device - credential server interactions; it doesn't support device - device operation). So consider this message a plea for others interested in this area to get involved in this work. Until SACRED or some similar solution becomes widely implemented, smartcards - e.g., SIMs or WIMs in phones - aren't going away. The business model in many parts of the world relies on a large number of customers replacing their handsets frequently. In many areas I'm familiar with, it's common for a large set of people to replace their handsets every few months, so that they always have the latest, smallest, most colorful, "coolest" device. The whole notion of a smart card supports this model, by allowing the user to get a new handset and dispose of the old one while maintaining the same service WITHOUT INTERACTING with the mobile operator, because those interactions with the carbon-based life forms who staff the operator outlets represent one of the highest costs in the system. With a SIM/Smart card that can be moved from one handset to another, there's no need to involve any other carbon-based life form. Since there's now no way to securely move the credentials electronically that's widely interoperable (lots of us have our own, somewhat proprietary schemes), for most mobile operators/service providers the smart card remains the method of choice. An automated - read as "efficient and low cost" way to securely register new devices into the system is also a requirement, and it's also currently an unsolved problem. Oh, there are other standards groups working on it, but I'm not sure they're going to have good solutions any time soon. So it's nice to sit here and make statements that "this technology was just wrong, and 20 years from now everyone will acknowledge that it's obvious", but tell me Lynn, how many statements about ISO vs. TCP/IP did you make in 1983? Al Arsenault Diversinet Corp. From owner-ietf-pkix@mail.imc.org Thu Feb 13 12:53:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19884 for ; Thu, 13 Feb 2003 12:53:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHTUW16928 for ietf-pkix-bks; Thu, 13 Feb 2003 09:29:30 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DHTRd16918 for ; Thu, 13 Feb 2003 09:29:27 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Thu, 13 Feb 2003 10:22:53 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/13/2003 12:30:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: the article from the cellphone manufactors .... that it was less expensive to provide a mechanism to save the current personality and load it into a new phone than it was to manufactor the slot for the smartcard reader interface ... with a overall infrastructure cost savings. the corresponding assertion was that the current smartcard & smartcard interface was as inexpensive as it was because of the significant investment that was made for generic, unbiquitous smartcard use .... not solely restricted to cellphone personabilities. and finally people could use the personality save/restore to address issue where the smartcard is lost/stolen/damaged. My other assertion was that the existing operation may linger for some time .... since the original smartcard investment has appeared to be written off .... and smartcard use can essentially be had for a few cents on the dollar. The transition to save/restore requires new investment in the save/restore infrastructure .... which means that the cost savings in eliminating the smartcard reader in cellphones would have to cover the save/restore infrastructure investment (and/or people find the additional benefit of having lost/stolen/damaged coverage). Note that the cost savings of using a common smartcard infrastructure is so great that the cellphones and the simms share the same manufactoring components .... down to simms being manufactored as smartcards ... and then the simms punched out of the plastic smartcard form factor. If the other uses of smartcards migrate to various contactless/wireless paradigms for various reasons .... that could mean that cellphone market segment would carry more of the smartcard infrastructure costs (even at a few more cents on the dollar) making it easier to justify the funding of a save/restore infrastructure transition. I didn't say smartcards were wrong. I said that they had a design point based on the technology from the '80s ... and that changed by the early '90s .... effectively making the technology assumptions and requirements from the '80s no longer valid. I wasn't making them (OSI comments) very load in 1983 ... I was doing some other things, although there were jokes about OSI being from pre-1970s, telco, point-to-point copper, high error rate, low bandwidth design point "people" ... aka by the time OSI standard was passed it was also obsolete. While i was doing a little tcp/ip stuff in the 1983 era .... it wasn't a primary focus and I didn't get involved into any OSI issues into slightly later. I was starting to get more vocal about OSI by possible 1985 .... I was starting to become more vocal about it. By interop '88 I was pretty vocal .... there were all these things in there with OSI, x.400, complex monitoring. One of the things at interop '88 ... i would guess that there was even some significant percentage of the IETF community was supporting various of the alternate candidates to SNMP. I had a couple workstations in booth kiddy-corner from the booth where case was "officially" located ... and was able to get Case to install SNMP on the workstations to demo .... even tho large portions of the rest of the booths had various SNMP alternatives. I was also on the XTP technical advisory board and working on HSP. The majority of the people in X3S3.3 were giving us really bad time because X3S3.3 had responsibility for standards related to OSI levels 3&4 ... and the official charter is that you can't have standards that violate OSI levels 3&4. My response was 1) ISO & ANSI are already totally schizophrenic because ethernet standard thru IEEE and recognized as standard at ISO combined levels 1, 2, and part of 3 ... i.e. the MAC interface includes a portion of routing from level 3. HSP was going to go directly from transpart/level4 to LAN interface in the middle of level3. Core X3S3.3 basically said that you couldn't have protocol standard work in X3S3.3 that specified an interface to MAC/LAN .... because that violated OSI. I've had more than a few choice words about gosip also. slightly related .... my wife and I were operating a backbone at the time of NSFNET1/T1 bid ... and weren't allowed to bid ... but a NSF audit of our backbone claimed it was at least five years ahead of all the NSFNET1/T1 bids to build something new. We were also doing some interesting/non-traditional things with crypto at the time ... but that is another story. However we did come up also with 3-layer architecture .... somewhat grew out of a response that my wife wrote and presented to a certain TLA gov agency RFI for enterprise distributed computing environment. That got us into trouble from various factions that were trying to put the client/server genie back into the bottle: http://www.garlic.com/~lynn/subtopic.html#3tier OSI was possibly a bad choice to choose as an example. However, something that I was really agitated about in the early 1980s time-frame was that the traditional mainframe computing environment was starting to commoditize .... first with mid-range computers and then with PCs and workstations. Maybe another example is this thing called electronic commerce. lots of threads related to OSI "blech": http://www.garlic.com/~lynn/subnetwork.html#xtphsp some recent discussions about interop '88 http://www.garlic.com/~lynn/subnetwork.html#interop past threads about high speed networking in the '80s http://www.garlic.com/~lynn/subnetwork.html#hsdt http://www.garlic.com/~lynn/subnetwork.html#internet http://www.garlic.com/~lynn/subnetwork.html#bitnet random past specific mentions regarding gosip: http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model? http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model? http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files? http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom. http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet... http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet? http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private http://www.garlic.com/~lynn/2001e.html#17 Pre ARPAnet email? http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft http://www.garlic.com/~lynn/2001i.html#5 YKYGOW... http://www.garlic.com/~lynn/2001i.html#6 YKYGOW... http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet http://www.garlic.com/~lynn/2002m.html#59 The next big things that weren't http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card? -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Al Arsenault on 2/13/2003 5:43 am wrote: Lynn, Interesting message from you, as always. Fascinating predictions on the future. Only a few issues need to be raised, IMHO. :-) One of those issues relates to the whole "secure backup and restore" or "secure download" of credentials. That's currently an unsolved problem. Fortunately, IETF has a working group - SACRED - addressing that issue. While SACRED started out a couple of years ago with a lot of interest and enthusiasm, interest seems to have waned. There are only a few people actively participating, and the group is about to wrap up with its solution. While I am others hope that the proposed solution will succeed and solve parts of the problem, it's not a complete solution (e.g., it addresses only device - credential server interactions; it doesn't support device - device operation). So consider this message a plea for others interested in this area to get involved in this work. Until SACRED or some similar solution becomes widely implemented, smartcards - e.g., SIMs or WIMs in phones - aren't going away. The business model in many parts of the world relies on a large number of customers replacing their handsets frequently. In many areas I'm familiar with, it's common for a large set of people to replace their handsets every few months, so that they always have the latest, smallest, most colorful, "coolest" device. The whole notion of a smart card supports this model, by allowing the user to get a new handset and dispose of the old one while maintaining the same service WITHOUT INTERACTING with the mobile operator, because those interactions with the carbon-based life forms who staff the operator outlets represent one of the highest costs in the system. With a SIM/Smart card that can be moved from one handset to another, there's no need to involve any other carbon-based life form. Since there's now no way to securely move the credentials electronically that's widely interoperable (lots of us have our own, somewhat proprietary schemes), for most mobile operators/service providers the smart card remains the method of choice. An automated - read as "efficient and low cost" way to securely register new devices into the system is also a requirement, and it's also currently an unsolved problem. Oh, there are other standards groups working on it, but I'm not sure they're going to have good solutions any time soon. So it's nice to sit here and make statements that "this technology was just wrong, and 20 years from now everyone will acknowledge that it's obvious", but tell me Lynn, how many statements about ISO vs. TCP/IP did you make in 1983? Al Arsenault Diversinet Corp. From owner-ietf-pkix@mail.imc.org Thu Feb 13 12:55:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20036 for ; Thu, 13 Feb 2003 12:55:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHKbn15727 for ietf-pkix-bks; Thu, 13 Feb 2003 09:20:37 -0800 (PST) Received: from amatabogados.com ([213.229.156.25]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1DHKZd15718 for ; Thu, 13 Feb 2003 09:20:36 -0800 (PST) Received: from host [80.26.116.141] by amatabogados.com (SMTPD32-4.07) id A47AA62028C; Thu, 13 Feb 2003 18:23:06 +0100 Message-ID: <002701c2d37f$a8accf00$0200a8c0@host> From: "Pere Fiol" To: "ietf" Subject: RFC3161(TSP): doubts about tcp protocol Date: Thu, 13 Feb 2003 17:47:55 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C2D388.09DBADC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C2D388.09DBADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've developed a TSA but I have a doubt in TCP protocol: if a client = sends a request to TSA with invalid TCP message (for example with a flag = different of '00'H, with wrong number of bytes in length,...) What must = do a TSA in this situations?? RFC3161 mustn't talk something about it?? Thanks and Best Regards, Pere Fiol ------=_NextPart_000_0024_01C2D388.09DBADC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I've developed a TSA but I have a = doubt in TCP=20 protocol: if a client sends a = request to TSA=20 with invalid TCP message (for example with a flag different of = '00'H, with=20 wrong number of bytes in length,...) What must do a TSA in this situations?? RFC3161 = mustn't talk=20 something about it??
 
Thanks and Best Regards,
Pere Fiol
 
------=_NextPart_000_0024_01C2D388.09DBADC0-- From owner-ietf-pkix@mail.imc.org Thu Feb 13 13:04:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20448 for ; Thu, 13 Feb 2003 13:04:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHTRF16919 for ietf-pkix-bks; Thu, 13 Feb 2003 09:29:27 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DHTPd16910 for ; Thu, 13 Feb 2003 09:29:25 -0800 (PST) Subject: RE: A challenge To: epay@ca0.net Cc: "Anders Rundgren" , ietf-pkix@imc.org, "Torsten Hentschel" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Thu, 13 Feb 2003 09:27:04 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/13/2003 12:30:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: my previously post in this thread was more on the semantics of certificates http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) rather than the most recent post http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge which is about 7816 contact smartcard. one of the issues is that 7816 also pretty much dictates the packaging and form factor. migration away from 7816 contact to any of the contactless/wireless conventions also can totally open up the packaging and form factor issues. my certificate assertion wasn't that you can't have certificates representing a binding/association registration process, my assertion was that the certificates .... were actually that ... just a representation of a binding/association registration process (along with a side note that in an online environment the use of certificates as a representation of the binding/association registration process would frequently redundant and superfluous ... not that it wouldn't work). My primary points were 1) that it seems that sometimes that the certificates are mistaken for the binding/associationr registration business process ... as opposed to just a representation of the binding/association registration business process (originally targeted for recipients who would never have been involved in any binding/assication registration business process) .... and 2) that sometimes such semantic confusion can complicate processes with regard to which are addressing the binding/association registration business process and which are addressing just the management of things that represent that binding/association registration business process (especially in an online environment when having separate representations can be redundant and superflous). However, just because something may be redundant and superfluous doesn't mean that it can't work. The issue in something like login .... is supposedly something has been registered to allow login .... in the PKI/certificate case, presumably what has been registered is some information that is bound in a PKI certificate (name, serial number, etc) ... in addition, the login process has the public key registration of acceptable certification authorities (that can be used to validate acceptable certificates to the login process). I've never claimed that doesn't work ... I've just claimed that frequently it is possible to show semantic equivalence between the login process registration of some value out of a certificate and the login process registration of the public key directly; The PKI registration process provides a type of information mapping indirection (somewhat like DNS provides a real-time mapping between hostnames and ip-address) .... where the CA digital signature asserts to the equivalence of the information (like a person's name or userid) bound in a certificate and a public key. The login process then has a set of registered CA public keys. In the PKI scenario, the login process gets a signed message that has an appended digital signature and an appended certificate. The login process finds the registered CA public key and validates the certificate, it then uses the public key in the certificate to validate the signed message. At this point it presumably has a proven equivalence between the entity sending the message and some bound information in the certificate (like a name). The login process can then have its own registry that maps between names found in certificates and userids .... and uses that to establish a valid login for that userid. The informaiton assurance mapping goes I've never asserted that it doesn't work. I have asserted that in situation where the login process has its own registery and mapping; that directly registering an entity's public key bound to a userid .... can be equivalent to a entity registering their public key with a CA, the CA signing a certificate that equates a name in a certificate with that public key, and then the login process registering a name in a certificate bound to a userid. The issue isn't that the levels of PKI information indirection (between public key and userid) don't work, the point was purely that they may be superfluous and redundant. This is somewhat equivalent to the IETF pk-init draft for Kerberos which provides for both certificate (aka PKI) based registration as well as certificateless based registration .... aka directly registering the entity's public key. The business process of registering a name from a certificate as equivalent to a userid .... can be shown to be the same as directly registering a public key as equivalent to a userid. The issue then is whether all the additional business processes in support of the various registering process providing information indirection between the name in the certificate and the entity's public key provides real value or is purely redundant and superfluous (given that there has to be a complex infrastructure for not only creating the certificates .... but once created these certificates now also have to be managed). Now the intersection with certifications and smartcards (actually hardwoare token) .... was whether there was a unique token/certificate pair for every environment or whether there was one (or a very small number of) token(s) could be used across a multitude of environments. If the environment supported a registration process, then the above assertion that public key can be directly registered would support that the public key of a single token could be registered in multiple environments. The counter-argument is some future environment that has migrated to hardware token authentication potentially requiring a unique token per environment and an entity possibly having to manage hundreds of such tokens. So an additional assertion is an ideal place for certificates is where there isn't an additional registration process and the certificate is sufficent for establishing both authentication as well as permissions (aka all/any generic employee certificate gets an entity through the door). A corresponding scenario would be a system login that has no userid directory/registration and when presented with a login message with an attached certificate .... it is possible for the login process to establish the complete user environment from just the contents of the certificate (not requiring a userid directory/registration at all). The problem is that tends to require a unqiue certificate for each environment ... which may or may not imply a corresponding unique hardware token. If it requires a unique hardware token, then the future possibility is that people walk around with hundreds of hardware tokens. Moving it out of the digital signature domain but still in the area of authentication might be biometrics. There is the possibility that a login process directly registers a person's fingerprint in the userid directory. The person then types in their userid and applies their finger to a fingerprint sensor. I assert that the direct registration of a person's fingerprint in a userid directory is equivalent to the direct registration of a public key in the userid directory. However, the downside is that a person's fingerprint is, in effect, a shared-secret ... anybody copying the fingerprint representation and being able to regenerate it can impersonate that entity. The upside of public key registration is that it isn't a shared-secret, knowledge of the public key isn't sufficient to impersonate. So sort of a summary .... 1) understanding that the binding/registration process is indenpendent of certificates that represent that process can result in better designs dealing with the two sepaate issues and 2) when there are additional registries (like userid directories) it is possible to view certificates as a type of information indirection and that such levels of indirection may be redundant and superfluous (not that they can't work just that they are redundant and superfluous). some kerberos related threads: http://www.garlic.com/~lynn/subpubkey.html#kerberos and somewhat topic drift ... redundant and superfluous may represent additional complexity and cost that are hard to justify. From recent discussion about DNS, KISS, theory, and practice: http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm tjones@windows.microsoft.com on 2/12/2003 8:21 pm wrote: For better, or worse, the current sc logon to o/s's uses a cert in the sc. It could be argued that the sc really only needs to cache the user's name in an insecure manner, but the point is that a PKI is used to authenticate the user w/ the sc. It seems to work. It's hard to imagine how it could be improved by some structure other than a PKI. There is no biz rule associated w/ the authentication. I doubt that u can argue that it does not work. I am sure that a better sol'n is possible, that is always true. So, let's just use sc w/ cert for logon authN. Ok? ..tom From owner-ietf-pkix@mail.imc.org Thu Feb 13 17:18:59 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13149 for ; Thu, 13 Feb 2003 17:18:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DLiGB27617 for ietf-pkix-bks; Thu, 13 Feb 2003 13:44:16 -0800 (PST) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DLi4d27610 for ; Thu, 13 Feb 2003 13:44:10 -0800 (PST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h1DLcHpp012694 for ; Thu, 13 Feb 2003 16:38:17 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 13 Feb 2003 16:26:28 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: Re: A challenge Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hans, The message clarifying what seems to be the major focus of the German CA law is quite illuminating. I can understand the motivation behind the law in this form, but it is also very much different from what many have said, where the focus was on CA key compromise, vs. cessation of operation of a CA. The requirement stated here could be met in many ways through procedural means of "shutting down" a CA, without revoking its cert. For example, one might mandate that a TTP CA be required to use a separate key for CRL and/or OCSP response signing, and that this key be escrowed. Then one could destroy the cert signing key as a means of shutting down the CA, but still retain the ability to sign revocation status data structures for the lifetime of any certs issued by the CA. That would provide the separation that seems to be the crux of the law, completely within the scope of current PKIX standards, right? Steve From owner-ietf-pkix@mail.imc.org Fri Feb 14 10:07:02 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24242 for ; Fri, 14 Feb 2003 10:07:01 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EEXJS29511 for ietf-pkix-bks; Fri, 14 Feb 2003 06:33:19 -0800 (PST) Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EEXBd29483 for ; Fri, 14 Feb 2003 06:33:14 -0800 (PST) Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h1EEWtE03550; Fri, 14 Feb 2003 15:32:56 +0100 Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h1EEWt703546; Fri, 14 Feb 2003 15:32:55 +0100 Message-ID: <3E4CFE16.4090701@daasi.de> Date: Fri, 14 Feb 2003 15:32:54 +0100 From: Peter Gietz Organization: DAASI International GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: =?ISO-8859-1?Q?=27Michael_Str=F6der=27?= , ietf-pkix@imc.org, Peter Gutmann , David Chadwick Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1EEXEd29497 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi all, Sorry to join this thread so late. To summarize this thread it seems that following technologies have been proposed to publish X.509 certificates: LDAP/X.500, DNS, HTTP (CertStore) and XML (XKMS). A new draft on Web Services seems to be on its way. May be in different environments different such technologies might be usefull. What I am missing in this discussion is a clear list of requirements for certificate retrieval. That might be of help to evaluate the different proposals. May be we should write an I-D on this. If others also volunteer I would be willing to put effort into such an activity. Peter Gutman's document on "A Reliable, Scalable General-purpose Certificate Store" would definitely provide some usefull input for such a document. As to LDAP/X.500: Michael has shown that most arguments against LDAP/X.500, e.g. privacy issues, organisations not willing to publish information about their employess, etc. also hold true for the other technologies. I vote for LDAP, since it provides an established network protocol and data modell that is flexible and comes along with important features like authentication, replication and especially distribution of the database. LDAP BTW does not need PKI as killerapp, it is being used as corporate directory since a long time with a lot of different usages. Our proposal for storing certs in LDAP (draft-klasen-ldap-x509certificate-schema) provides the possibility to create a distributed certificate repository, where every CA can publish their certs in a DIT structure to their liking (inside an organisational structure together with white pages and yelow pages information or in a cert only repository). It also solves the problem of multiple certs of a user. With the help of an indexing system and the LDAP referral mechanism a service can be established that can refer an LDAP client to the LDAP server on which the certificate searched for is stored. The alternative using DNS SRV for locating servers has been mentioned in this thread already. David Chadwick's work on an LDAP server that sort of translates between the classical LDAP certificate storage in attributes like userCertificate and our model makes no changes necessary for current clients. But even without such an intermediate server, client modifications would be rather simple (changing the search filters). Peter Gu.: if you don't know whether to laugh or cry about our proposal, please consider that ldap:///?caCertificate?sub? (&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43% 5C83%5C78%5C25%5C70%5C52%5CE0%5C19)) is a bit more powerfull that the key/value pair you propose, e.g. you could also want to get back the cert's subject, its issuer, its valdity, etc. instead of the cert. BTW in that example it would be fairly safe to do without the "objectClass=x509certificate" bit. Anyway I don't see enough difference between the ldap URL and your http URL to get so high emotions. In combination with David's new draft on CRLs, an OCSP server can be implemented on top of an LDAP server very easily (to come back to the original thread). Your Certstore via an LDAP2Web gateway? again no problem. This is not like your "putting a pea on a fork example" it is more about management efficiancy (one data store and multiple usages for it). One last comment: X.500 bashing on this list is no new phenomenon, look at the pkix archives and you will find similiar, e.g. quote: From chandras@xxx.xxx Tue Mar 11 16:00:16 1997 [sic]: "Part of the recent success of X.509 in the internet space, given it lay on the internet doldrums for years, was its abandonment of X.500 as mandatory for theory or practice. One can, always add X.500 back in whenever one wants, of course; as much or as little as one wants." In spite of X.500 bashings a consensus seemed to have established from time to time in this group that LDAP is a good technology for certificate repositories. X.509 people rediscovered the X.500 model from which X.509 once originated. And I am quite confident that threads like this one will not change this. Cheers, Peter Gi. Hallam-Baker, Phillip wrote: >>Anders Rundgren wrote: >> >>>But the _real_ problem with the X.500 model is that it builds >>>on the assumption that organizations want to publish information >>>for others to search. >> >>Again: This is not a specific problem with the X.500 model. >>It's a general >>problem with certificate retrieval across organizational boundaries. > > > I don't see this as an objection to the X.500/LDAP architecture. > However it is a severe restriction on deployment. > > Since the argument for reuse of LDAP is that it is deployed and > the excuse for reuse of X.500 is that it is going to be deployed > the fact that enterprises will not allow public access to anything > that looks like a directory is very relevant. > > Not making your directory world readable is probably more important > as an enterprise security measure than firewall deployment. > > > >> >>Using a 'web service' (whatever we might agree in the future >>if ever on what >>that really is) will just migrate the very same problems to >>another service. > > > First off, there is considerable agreement on the definition > of Web services. They are machine/machine protocols that are > encapsulated in SOAP messaging. > > Note that there is no requirement to run over HTTP. I think that > in the long run we will move to DIME or something similar. > > > >>That's what folks should understand *before* trying to solve >>problems by >>defining yet another standard with yet another buzz-word. > > > Take a look at the XKMS specs. The problem is really well > understood at this point. > > > >>And I also agree with David that web services just >>circumvents firewalls by simple HTTP tunneling. > > > That is a misconception, although several folk like Bruce > the sage of Minnessota have been plugging away at it. > > First off Web Services need not be layered on HTTP. In > fact DIME is a much cleaner interface. But HTTP has some > near term advantages. > > Secondly a large part of the Web Services architecture is > all about how to route messages through firewalls, the > visibility that messages must have, etc. etc. > > There is an assumption that the firewall does somewhat more > than simply block certain ports. > > >>PKI acceptance is yet another issue independent of X.500 directories. > > > No, the X.500 linkage is the single biggest barrier. It has > led to more failed PKI deployments in my experience than any > other. > > The customers have wanted to deploy a PKI, they are captured by > a directory vendor. They spend three years arguing over theri DIT > instead and erroneously conclude that PKI is hard to deply. > > For PKI deployment to succeed you have to take X.500 and LDAP > deployment out of the critical path. > > >>If someone's to blame for lack of PKI acceptance it's this WG for not >>reaching consensus on very basic issues > > > No, that is not a factor in PKI deployment. This list is no longer > a factor in the development of the PKI world. > > The basic certificate standards are already deployed in Windows > 2000, Java and the rest. The job of this group is to document the > reality that has been created. This group cannot influence changes > in the PKI infrastructure, that has already happened. > > This by the way is the IETF way. HTTP was only standardized some > six years after the protocol was ubiquitous. > > > >>(feel free to check the mailing list >>archive *excluding* the dumb X.500 bashing of last three months) and > > > Was there a previous X.500 bashing thread? I don't think so. > > We have only been on this thread since the new year. > > > >>And no, the problems will not automagically be solved by XML, >>XKMS, >favourite buzz-words here...>. > > > The XML syntax is neither here nor there. I used it simply because > if I ask an engineer to learn ASN.1 they start preparing their resume, > engineers ask me if they can learn XML. > > Whether or not XML is actually superior it has won by any empirical > standard. Choosing to use ASN.1 at this point is like choosing to > use EBSDIC instead of ASCII. > > > I hope that we put rather more into the design of XKMS than simply > rehashing PKIX in XML. In fact that was the one thing that the > original charter did not allow us to do. > > Phill -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 Tübingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ From owner-ietf-pkix@mail.imc.org Fri Feb 14 10:32:15 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24780 for ; Fri, 14 Feb 2003 10:32:15 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EExsS03203 for ietf-pkix-bks; Fri, 14 Feb 2003 06:59:54 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EExqd03198 for ; Fri, 14 Feb 2003 06:59:52 -0800 (PST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1EExECq027431; Fri, 14 Feb 2003 06:59:14 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <15SFCZ3H>; Fri, 14 Feb 2003 06:59:53 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Peter Gietz'" , "Hallam-Baker, Phillip" Cc: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= , ietf-pkix@imc.org, Peter Gutmann , David Chadwick Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 14 Feb 2003 06:59:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_010F_01C2D40F.D0643020"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_010F_01C2D40F.D0643020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > To summarize this thread it seems that following technologies > have been > proposed to publish X.509 certificates: > LDAP/X.500, DNS, HTTP (CertStore) and XML (XKMS). A new draft on Web > Services seems to be on its way. No, XKMS is a Web Service. It is OSCPII and its competitors that are on their way. > May be in different environments different such technologies might be > usefull. What I am missing in this discussion is a clear list of > requirements for certificate retrieval. Alice wants to send email to Bob Alice does not know Bob's Certificate Alice does know Bob's email address. Bob's name is not unique Bob's company will not provide any form of search capabilities beyond exact match. The Trust topology is complex as in a multiple bridge CA Web of trust. XKMS and the planned ASN.1 cert discovery protocols meet these requirements X.500/LDAP are designed to meet different requirements. They cannot address the Web of Trust cert path discovery requirement. > > As to LDAP/X.500: > > Michael has shown that most arguments against LDAP/X.500, He showed no such thing. His arguments were flat and unconvincing except if you are already sold on LDAP/X.500. My empiriacal observation is that companies that try to deploy a Directory based PKI fail far more frequently than those who do not make the directory a critical path component, or make the directory deployment completely subordinate to the PKI. The problem is that Directories offer companies infinite scope for arguing over the structure of DITs etc. The fact that these arguments are important demonstrate the basic immaturity of directory technology. > e.g. privacy > issues, organisations not willing to publish information about their > employess, etc. also hold true for the other technologies. This is empirically wrong. Most VeriSign customers are prepared to publish their certificats in the public directory for retrieval on the basis of exact match of email address. > I vote for LDAP, since it provides an established network > protocol and The customers vote for no-LDAP and have done for the past ten years. > Our proposal for storing certs in LDAP > (draft-klasen-ldap-x509certificate-schema) provides the > possibility to > create a distributed certificate repository, where every CA > can publish > their certs in a DIT structure to their liking ( That is the problem, to their liking means no interoperability. > With the help of an indexing system and the LDAP referral > mechanism a > service can be established that can refer an LDAP client to the LDAP > server on which the certificate searched for is stored. The > alternative > using DNS SRV for locating servers has been mentioned in this thread > already. I originally proposed the SRV mechanism. It can locate a certificate server but it cannot locate a certification path. > Peter Gu.: if you don't know whether to laugh or cry about > our proposal, > please consider that > > ldap:///?caCertificate?sub? > (&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6 > %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43% > 5C83%5C78%5C25%5C70%5C52%5CE0%5C19)) > > is a bit more powerfull that the key/value pair you propose, I don't care how 'powerfull' a mechanism is. The point is that power does not equal utility. Less powerful frequently means more useful. C is a subset of the CPL language and is better for it. Directories are the ADA of network computing. > X.500 bashing on this list is no new phenomenon, look at the pkix > archives and you will find similiar, e.g. quote: > > From chandras@xxx.xxx Tue Mar 11 16:00:16 1997 [sic]: > > "Part of the recent success of X.509 in the internet space, > given it lay on the internet doldrums for years, was its abandonment > of X.500 as mandatory for theory or practice. One can, always > add X.500 back in whenever one wants, of course; as much > or as little as one wants." If X.500 gets bashed it is probably because it deserves to. The above comment is correct. PKI has succeeded in spite of directory nonsense, not as a result. Now that we have alternatives that actually meet our needs it is time to give the unwellcome house guest their marching orders. > In spite of X.500 bashings a consensus seemed to have > established from time to time in this group that LDAP > is a good technology for certificate repositories. The only consensus I can see concerning certificate discovery is that there is a need for a new protocol which duplicates most of the functionality of XKMS in ASN.1 and then adds in some extra twiddles. I don't agree that angle brackets are indigestible but it is better for the group to persue the right architecture than to continue to persue an architecture that has been an abject failure. I don't count large numbers of enterprise directory sales as evidence for success. Try a thought experiment, what happens if the directory goes down, how much work does that event stop getting done? Phill ------=_NextPart_000_010F_01C2D40F.D0643020 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNDE0 NTk1MFowIwYJKoZIhvcNAQkEMRYEFI8tCf5TMwwcTEl0xyHUfnYip4UWMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAC4kIfeSDFwsaxBE6XgjH5WvkHEKX87LSL5ljq9mkak6W7pNx Wp3FXxZ4cOh3oNdMjLt+YF4W4uIumNpeOWq8afFwzVA3q4jLzjPjjn1uQ/8cY5ABAMxlyQNxWNTM BKtHW3XnQj7PwFfZi00wnAULmiuo7uVLIQ05pVeSZSwTbFcAAAAAAAA= ------=_NextPart_000_010F_01C2D40F.D0643020-- From owner-ietf-pkix@mail.imc.org Fri Feb 14 11:41:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26544 for ; Fri, 14 Feb 2003 11:41:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EGECm05565 for ietf-pkix-bks; Fri, 14 Feb 2003 08:14:12 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EGEAd05561 for ; Fri, 14 Feb 2003 08:14:11 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA20808; Fri, 14 Feb 2003 17:16:12 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA19574; Fri, 14 Feb 2003 16:07:53 +0100 Message-ID: <3E4D1505.6010509@bull.net> Date: Fri, 14 Feb 2003 17:10:45 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "Jeffrey I. Schiller" CC: Nick Pope , John Ross , IETF PKIX WG List , "Steven M. Bellovin" Subject: Re: Issues with draft-ietf-pkix-pr-tsa-02.txt References: <3E303A7F.2090609@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1EGECd05562 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jeff, > The IESG discussed this document on today's telechat. Two issues were > raised. > 1. There needs to be a Security Considerations section! Nick Pope and myself have prepared such a section. Here it is: 8. Security Considerations When verifying time-stamp tokens it is necessary for the verifier to ensure that the TSU certificate is trusted and not revoked. This means that the security is dependent upon the security of the CA that has issued the TSU certificate for both issuing the certificate and providing accurate revocation status information for that certificate. When a time-stamp is verified as valid at a given point of time, this does not mean that it will necessarily remain valid later on. Every time, a time–stamp token is verified during the validity period of the TSU certificate, it must be verified again against the current revocation status information, since in case of compromise of a TSU private key, all the time-stamp tokens generated by that TSU become invalid. Annex C provides guidance about the long term verification of time-stamp tokens. In applying time-stamping to applications, consideration also needs to be given to the security of the application. In particular, when applying time-stamps it is necessary to ensure that the integrity of data is maintained before the time-stamp is applied. The requester ought to really make sure that the hash value included in the time-stamp token matches with the hash of the data. > 2. Is this document identical to its ETSI equivalent? Do we have > permission from ETSI to publish this as an IETF document? Do we > need permission? We do have permission from ETSI for the publication. RFC 3126 has been published with the following advertisement. The contents of this Informational RFC is technically equivalent to ETSI TS 101 733 V.1.2.2 Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org The writing for this new document is nearly the same: The contents of this Informational RFC is technically equivalent to ETSI TS 102 023 V1.2.1 (2002-06) [TS 102023]. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org If this is a problem, we can make it exactly the same: The contents of this Informational RFC is technically equivalent to ETSI TS 102 023 V 1.2.1 (2002-06) [TS 102023] Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org Would you tell me whether I can now place the version with the additional security considerations section with the current text about the copyright or with the new proposed text ? (or whether it does not matter which one ?) Regards, Denis > > -Jeff From owner-ietf-pkix@mail.imc.org Fri Feb 14 12:01:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27223 for ; Fri, 14 Feb 2003 12:00:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EGVi806007 for ietf-pkix-bks; Fri, 14 Feb 2003 08:31:44 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EGVgd06002 for ; Fri, 14 Feb 2003 08:31:42 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 14 Feb 2003 08:31:38 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Feb 2003 08:31:38 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Feb 2003 08:31:38 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Feb 2003 08:31:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Fri, 14 Feb 2003 08:31:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: A challenge Date: Fri, 14 Feb 2003 08:31:39 -0800 Message-ID: Thread-Topic: A challenge Thread-Index: AcLT9NY17o858S3UT+GciJlJ8DdheAAUQdkY From: "Tom Jones \(.NET\)" To: Cc: "Anders Rundgren" , , "Torsten Hentschel" X-OriginalArrivalTime: 14 Feb 2003 16:31:37.0385 (UTC) FILETIME=[8B8CB990:01C2D446] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1EGVhd06003 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit it is kind-of hard to get your point from this post. Note that the point of logon is that mobile computers need to work off-line. So any logon proceedure needs to accomodate off-line as well as on-line. As you point out, cert were designed in an off-line scenario. Seems to fit the problem nicely. If we don't have smart cards with certs in them, we need to put the cert (binding) in every mobile device that would use that info. That would assume that the mobile device was more secure than the smart card/cert combo, and had more current info. My experience w/ mobile devices, including cell phones, leads me to believe that neither of these is true. ..tom ________________________________ From: lynn.wheeler@firstdata.com [mailto:lynn.wheeler@firstdata.com] Sent: Thu 2/13/2003 8:27 AM To: Tom Jones (.NET) Cc: Anders Rundgren; ietf-pkix@imc.org; Torsten Hentschel Subject: RE: A challenge my previously post in this thread was more on the semantics of certificates http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) rather than the most recent post http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge which is about 7816 contact smartcard. one of the issues is that 7816 also pretty much dictates the packaging and form factor. migration away from 7816 contact to any of the contactless/wireless conventions also can totally open up the packaging and form factor issues. my certificate assertion wasn't that you can't have certificates representing a binding/association registration process, my assertion was that the certificates .... were actually that ... just a representation of a binding/association registration process (along with a side note that in an online environment the use of certificates as a representation of the binding/association registration process would frequently redundant and superfluous ... not that it wouldn't work). My primary points were 1) that it seems that sometimes that the certificates are mistaken for the binding/associationr registration business process ... as opposed to just a representation of the binding/association registration business process (originally targeted for recipients who would never have been involved in any binding/assication registration business process) .... and 2) that sometimes such semantic confusion can complicate processes with regard to which are addressing the binding/association registration business process and which are addressing just the management of things that represent that binding/association registration business process (especially in an online environment when having separate representations can be redundant and superflous). However, just because something may be redundant and superfluous doesn't mean that it can't work. The issue in something like login .... is supposedly something has been registered to allow login .... in the PKI/certificate case, presumably what has been registered is some information that is bound in a PKI certificate (name, serial number, etc) ... in addition, the login process has the public key registration of acceptable certification authorities (that can be used to validate acceptable certificates to the login process). I've never claimed that doesn't work ... I've just claimed that frequently it is possible to show semantic equivalence between the login process registration of some value out of a certificate and the login process registration of the public key directly; The PKI registration process provides a type of information mapping indirection (somewhat like DNS provides a real-time mapping between hostnames and ip-address) .... where the CA digital signature asserts to the equivalence of the information (like a person's name or userid) bound in a certificate and a public key. The login process then has a set of registered CA public keys. In the PKI scenario, the login process gets a signed message that has an appended digital signature and an appended certificate. The login process finds the registered CA public key and validates the certificate, it then uses the public key in the certificate to validate the signed message. At this point it presumably has a proven equivalence between the entity sending the message and some bound information in the certificate (like a name). The login process can then have its own registry that maps between names found in certificates and userids .... and uses that to establish a valid login for that userid. The informaiton assurance mapping goes I've never asserted that it doesn't work. I have asserted that in situation where the login process has its own registery and mapping; that directly registering an entity's public key bound to a userid .... can be equivalent to a entity registering their public key with a CA, the CA signing a certificate that equates a name in a certificate with that public key, and then the login process registering a name in a certificate bound to a userid. The issue isn't that the levels of PKI information indirection (between public key and userid) don't work, the point was purely that they may be superfluous and redundant. This is somewhat equivalent to the IETF pk-init draft for Kerberos which provides for both certificate (aka PKI) based registration as well as certificateless based registration .... aka directly registering the entity's public key. The business process of registering a name from a certificate as equivalent to a userid .... can be shown to be the same as directly registering a public key as equivalent to a userid. The issue then is whether all the additional business processes in support of the various registering process providing information indirection between the name in the certificate and the entity's public key provides real value or is purely redundant and superfluous (given that there has to be a complex infrastructure for not only creating the certificates .... but once created these certificates now also have to be managed). Now the intersection with certifications and smartcards (actually hardwoare token) .... was whether there was a unique token/certificate pair for every environment or whether there was one (or a very small number of) token(s) could be used across a multitude of environments. If the environment supported a registration process, then the above assertion that public key can be directly registered would support that the public key of a single token could be registered in multiple environments. The counter-argument is some future environment that has migrated to hardware token authentication potentially requiring a unique token per environment and an entity possibly having to manage hundreds of such tokens. So an additional assertion is an ideal place for certificates is where there isn't an additional registration process and the certificate is sufficent for establishing both authentication as well as permissions (aka all/any generic employee certificate gets an entity through the door). A corresponding scenario would be a system login that has no userid directory/registration and when presented with a login message with an attached certificate .... it is possible for the login process to establish the complete user environment from just the contents of the certificate (not requiring a userid directory/registration at all). The problem is that tends to require a unqiue certificate for each environment ... which may or may not imply a corresponding unique hardware token. If it requires a unique hardware token, then the future possibility is that people walk around with hundreds of hardware tokens. Moving it out of the digital signature domain but still in the area of authentication might be biometrics. There is the possibility that a login process directly registers a person's fingerprint in the userid directory. The person then types in their userid and applies their finger to a fingerprint sensor. I assert that the direct registration of a person's fingerprint in a userid directory is equivalent to the direct registration of a public key in the userid directory. However, the downside is that a person's fingerprint is, in effect, a shared-secret ... anybody copying the fingerprint representation and being able to regenerate it can impersonate that entity. The upside of public key registration is that it isn't a shared-secret, knowledge of the public key isn't sufficient to impersonate. So sort of a summary .... 1) understanding that the binding/registration process is indenpendent of certificates that represent that process can result in better designs dealing with the two sepaate issues and 2) when there are additional registries (like userid directories) it is possible to view certificates as a type of information indirection and that such levels of indirection may be redundant and superfluous (not that they can't work just that they are redundant and superfluous). some kerberos related threads: http://www.garlic.com/~lynn/subpubkey.html#kerberos and somewhat topic drift ... redundant and superfluous may represent additional complexity and cost that are hard to justify. From recent discussion about DNS, KISS, theory, and practice: http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm tjones@windows.microsoft.com on 2/12/2003 8:21 pm wrote: For better, or worse, the current sc logon to o/s's uses a cert in the sc. It could be argued that the sc really only needs to cache the user's name in an insecure manner, but the point is that a PKI is used to authenticate the user w/ the sc. It seems to work. It's hard to imagine how it could be improved by some structure other than a PKI. There is no biz rule associated w/ the authentication. I doubt that u can argue that it does not work. I am sure that a better sol'n is possible, that is always true. So, let's just use sc w/ cert for logon authN. Ok? ..tom To remove yourself from this list send a message Unsubscribe to epay-request@ca0.net From owner-ietf-pkix@mail.imc.org Fri Feb 14 12:25:18 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27889 for ; Fri, 14 Feb 2003 12:25:17 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EH1eY07877 for ietf-pkix-bks; Fri, 14 Feb 2003 09:01:40 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-86.apple.com [17.250.248.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EH1dd07873 for ; Fri, 14 Feb 2003 09:01:39 -0800 (PST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h1EH1f51025823 for ; Fri, 14 Feb 2003 09:01:41 -0800 (PST) Received: from [10.10.110.50] ([65.200.9.2]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id HAB5YT00.K70 for ; Fri, 14 Feb 2003 09:01:41 -0800 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 14 Feb 2003 09:01:38 -0800 Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP From: Aram Perez To: PKIX Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phill, While I generally agree with what you write, this time I have do have some questions, see below. Regards, Aram Perez Hallam-Baker, Phillip wrote: [snip] > >> May be in different environments different such technologies might be >> usefull. What I am missing in this discussion is a clear list of >> requirements for certificate retrieval. > > Alice wants to send email to Bob > Alice does not know Bob's Certificate > Alice does know Bob's email address. > Bob's name is not unique But Bob's email is unique. Why can't Alice look up Bob's certificate by his unique email address? > Bob's company will not provide any form of search capabilities beyond > exact match. > The Trust topology is complex as in a multiple bridge CA Web of trust. > > > XKMS and the planned ASN.1 cert discovery protocols meet these > requirements > > X.500/LDAP are designed to meet different requirements. They cannot > address the Web of Trust cert path discovery requirement. Can you please restate exactly what this "Web of Trust cert path discovery requirement" is? [snip] >> e.g. privacy >> issues, organisations not willing to publish information about their >> employess, etc. also hold true for the other technologies. > > This is empirically wrong. Most VeriSign customers are prepared > to publish their certificats in the public directory for retrieval > on the basis of exact match of email address. Not exactly related, but why won't VeriSign "publish" or make available their public keys so I can do my own manual verification of VeriSign's certificates in my browser? [snip] > > I don't count large numbers of enterprise directory sales as > evidence for success. Try a thought experiment, what happens if > the directory goes down, how much work does that event stop > getting done? Come on Phill, what happens if any critical component goes down? Look at what the Slammer virus did to the whole, worldwide Internet when it attacked SQL servers (not LDAP servers). From owner-ietf-pkix@mail.imc.org Fri Feb 14 13:49:14 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00698 for ; Fri, 14 Feb 2003 13:49:13 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIGrq14137 for ietf-pkix-bks; Fri, 14 Feb 2003 10:16:53 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EIGmd14122 for ; Fri, 14 Feb 2003 10:16:48 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 10:16:18 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 01:18:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: one of the factors driving 7816 standardization/commoditization in the '80s was that 7816 was a portable computing device ... but was dependent upon somewhat ubiquitous deployment of (stationary) input/output stations. the appearance of intergrated portable input/output technology (cellphones & pds) in the early '90s started to chip away at the original 7816 target market. further eroding this target market is the spread of numerous contractless/wireless technologies. a big part of the 7816 standardization was the requirement for physical interoperability between the portable 7816 devices and the input/output stations. contactless technologies enable arbritrary form-factors .... further chiping away at the 7816 standardization. for the aads chip strawman http://www.garlic.com/~lynn/index.html#aadstraw in '98 timeframe, i had somewhat facetiously claimed that i would take a $500 milspec part and cost-reduce it by two-orders of magnitude while improving the integrity. at an assurance panel in the TCPA track at the intel developer's conference, i claimed that the chip met all the function/requirements of the TPM (and was finalized much earlier) and was equivalent to the best of integrity from gov. agencies. One of the TCPA people in the audience commented that wasn't fair since I didn't have a committee of 200 people helping me. One of the people on the panel from a gov. TLA replied that it was possibly true except in the area of radiation hardening. past tcpa related posts: -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix@mail.imc.org Fri Feb 14 13:51:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00766 for ; Fri, 14 Feb 2003 13:51:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIGr514139 for ietf-pkix-bks; Fri, 14 Feb 2003 10:16:53 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EIGnd14124 for ; Fri, 14 Feb 2003 10:16:49 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 10:31:24 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 01:18:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: one of the factors driving 7816 standardization/commoditization in the '80s was that 7816 was a portable computing device ... but was dependent upon somewhat ubiquitous deployment of (stationary) input/output stations. the spread of integrated portable input/output technology (cellphones & pds) in the early '90s started to chip away at the original 7816 target market (i.e. portable computing devices w/o requirement for ubiquitous input/output stations. further eroding this target market is the spread of numerous contractless/wireless technologies. a big part of the 7816 standardization was the requirement for physical interoperability between the portable 7816 devices and the input/output stations. contactless technologies enable arbitrary form-factors .... further chiping away at the 7816 market segment. one of the targets for iso 14443 is a current primary 7816 market segment, point-of-sale .... where the contact infrastructure is showing failures .... especially in high-traffic areas. contactless/wireless breaks the requirement for form-factor specific implementation (required by contact interoperability) and starts to allow interoperability with devices regardless of their form factor. for the aads chip strawman http://www.garlic.com/~lynn/index.html#aadstraw in '98 timeframe, i had somewhat facetiously claimed that i would take a $500 milspec part and cost-reduce it by two-orders of magnitude while improving the integrity. at an assurance panel in the TCPA track at the intel developer's conference, i claimed that the chip met all the function/requirements of the TPM (and was finalized much earlier) and was equivalent to the best of integrity from gov. agencies. One of the TCPA people in the audience commented that wasn't fair since I didn't have a committee of 200 people helping me. One of the people on the panel from a gov. TLA replied that it was possibly true except in the area of radiation hardening. other past tcpa related posts: http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA) http://www.garlic.com/~lynn/aadsm12.htm#14 Challenge to TCPA/Palladium detractors http://www.garlic.com/~lynn/aadsm12.htm#15 Challenge to TCPA/Palladium detractors http://www.garlic.com/~lynn/aadsm12.htm#16 Feasability of Palladium / TCPA http://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA) http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM] http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#63 Intertrust, Can Victor Shear Bring Down Microsoft? -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix@mail.imc.org Fri Feb 14 13:53:11 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00815 for ; Fri, 14 Feb 2003 13:53:10 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIGrX14138 for ietf-pkix-bks; Fri, 14 Feb 2003 10:16:53 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EIGnd14128 for ; Fri, 14 Feb 2003 10:16:50 -0800 (PST) Subject: RE: A challenge To: epay@ca0.net Cc: "Anders Rundgren" , ietf-pkix@imc.org, "Torsten Hentschel" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 11:12:15 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 01:18:20 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384" Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384 Content-type: text/plain; charset=us-ascii the point was offline from the registry in login there is either 1) registry in the unit requiring logging in which contains a binding between some identity and the permission's (i.e. what things can log in and do). 2) or a purely ROM logging-in process that accepts any and all certificates signed by some prespecified CA .... and will perform whatever operations indicated by the certificate. in previous posting outlining a logging in scenario where there is some local registry in the device .... that is also certificate based .... the local device registry has both the list of acceptable public key certificates as well as some list of acceptable identification information from one or more certificates. The person presents a certificate, an attempt is made to validate the CA signature from the list of valid CA public keys in the registry .... and then some identification information contained in the certificate (say a person's name) is used to look up a registry entry for "certificates" that are allowed to log in and possibly their mapping to permissions and authorization. The public key from the certificate can be used to validate a signed message .... either before or after the lookup to see if there is a userid registry entry that corresponds to some identification field in the certificate (say person's name). My assertion is that in the case where there is registry of valid userids with a mapping to a value in the certificate .... the whole infrastructure is equivalent to "information indirection" paradigm provided by the certificate infrastructure. Say I buy a mobile device .... and want to establish my "ownership" by registering my certificate in the device as the true owner. So in the device are: 1) table of CA public keys 2) certificate with my public key and maybe my name signed by one of the CAs 3) login message 4) my signature on the login message I assert that the levels of indirection can be totally eliminated by instead replacing the table of CA public keys with a table of "owner" public keys .... and mapping the table of "owner" public keys directly to permissions. The table of CA public keys are eliminated and replaced with a table of owner "public keys". The registry mapping some certificate field unique identifier to permissions is eliminated and instead the registry of permissions are mapped directly to owner "public keys". The information indirection provided by the CA PKI infrastructure and the certificates are eliminated. The issue with regard to being offline from the registry is where there is no local registry which maps a certificate field to local device permissions. The local device has no access to the registry mapping certificate field to permissions ... and therefore must totally rely on information within the certificate as to what permissions are entitled. This "offline" infrastructure has only a CA table of public keys in the device. Certificates are presented signed by any of the acceptable CAs. The device then extracts all permissions directly from the certificate because it doesn't have online (or otherwise) access to the registry of permissions for this device. So my original assertion is that if the device has access (online or otherwise) to the registry of permissions for the device .... the indirection infrastructure provided by PKI certificate based operation can be collapsed to replacing the CA table of acceptable public keys with a separate registry of permissions to a single combined registry table containing the acceptable public keys and the associated permissions. So looking at PKI from the reverse standpoint, a PKI is an extension of the single combined registry table to a two level structure (in its basic form). The simple door entry scenario previously described is a singled combined registry table .... where the "owner" is directly mapped to permissions. The permission "owner" is able to authorize agents or surrogates by way of certificates. An "owner" can directly enter by signing a message with their public key ... or they can authorize others to enter by signing certificates containing the surrogate/agent's public key. The door entry validates the surrogate certificate as coming from a valid owner ... and then validates the agent/surrogate's digital signature. The door entry system doesn't require any access to any registry containing any information regarding anything about the surrogate/agent. The assertion is that anytime that the local environment needs a local registry regarding specific surrogate/agent operation .... then the certificates are a form of information indirection and likely redundant and superfluous .... since the surrogate/agent's public key can be directly added to the single permissions table. Logically permissions are a single table. For arbritrary implementation reasons the table of permissions for CA public keys .... may be implied permission of only signing certificates for delegating authority to surrogate/agents. However, the permission table may be expanded for CA public keys to the type of delegation that specific CA can perform. However, as soon as there has to be a local decision with regard to a surrogate/agent permissions in a local registry directly accessable by the device .... then I claim that the levels of indirection provided by a certificate can be eliminated and the surrogate/agent's public key be directly registered. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm "Tom Jones \(.NET\)" cc: "Anders Rundgren" , , "Torsten Hentschel" 02/14/2003 09:31 AM Subject: RE: A challenge Please respond to epay it is kind-of hard to get your point from this post. Note that the point of logon is that mobile computers need to work off-line. So any logon proceedure needs to accomodate off-line as well as on-line. As you point out, cert were designed in an off-line scenario. Seems to fit the problem nicely. If we don't have smart cards with certs in them, we need to put the cert (binding) in every mobile device that would use that info. That would assume that the mobile device was more secure than the smart card/cert combo, and had more current info. My experience w/ mobile devices, including cell phones, leads me to believe that neither of these is true. ..tom ________________________________ From: lynn.wheeler@firstdata.com [mailto:lynn.wheeler@firstdata.com] Sent: Thu 2/13/2003 8:27 AM To: Tom Jones (.NET) Cc: Anders Rundgren; ietf-pkix@imc.org; Torsten Hentschel Subject: RE: A challenge my previously post in this thread was more on the semantics of certificates http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) rather than the most recent post http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge which is about 7816 contact smartcard. one of the issues is that 7816 also pretty much dictates the packaging and form factor. migration away from 7816 contact to any of the contactless/wireless conventions also can totally open up the packaging and form factor issues. my certificate assertion wasn't that you can't have certificates representing a binding/association registration process, my assertion was that the certificates .... were actually that ... just a representation of a binding/association registration process (along with a side note that in an online environment the use of certificates as a representation of the binding/association registration process would frequently redundant and superfluous ... not that it wouldn't work). My primary points were 1) that it seems that sometimes that the certificates are mistaken for the binding/associationr registration business process ... as opposed to just a representation of the binding/association registration business process (originally targeted for recipients who would never have been involved in any binding/assication registration business process) .... and 2) that sometimes such semantic confusion can complicate processes with regard to which are addressing the binding/association registration business process and which are addressing just the management of things that represent that binding/association registration business process (especially in an online environment when having separate representations can be redundant and superflous). However, just because something may be redundant and superfluous doesn't mean that it can't work. The issue in something like login .... is supposedly something has been registered to allow login .... in the PKI/certificate case, presumably what has been registered is some information that is bound in a PKI certificate (name, serial number, etc) ... in addition, the login process has the public key registration of acceptable certification authorities (that can be used to validate acceptable certificates to the login process). I've never claimed that doesn't work ... I've just claimed that frequently it is possible to show semantic equivalence between the login process registration of some value out of a certificate and the login process registration of the public key directly; The PKI registration process provides a type of information mapping indirection (somewhat like DNS provides a real-time mapping between hostnames and ip-address) .... where the CA digital signature asserts to the equivalence of the information (like a person's name or userid) bound in a certificate and a public key. The login process then has a set of registered CA public keys. In the PKI scenario, the login process gets a signed message that has an appended digital signature and an appended certificate. The login process finds the registered CA public key and validates the certificate, it then uses the public key in the certificate to validate the signed message. At this point it presumably has a proven equivalence between the entity sending the message and some bound information in the certificate (like a name). The login process can then have its own registry that maps between names found in certificates and userids .... and uses that to establish a valid login for that userid. The informaiton assurance mapping goes I've never asserted that it doesn't work. I have asserted that in situation where the login process has its own registery and mapping; that directly registering an entity's public key bound to a userid .... can be equivalent to a entity registering their public key with a CA, the CA signing a certificate that equates a name in a certificate with that public key, and then the login process registering a name in a certificate bound to a userid. The issue isn't that the levels of PKI information indirection (between public key and userid) don't work, the point was purely that they may be superfluous and redundant. This is somewhat equivalent to the IETF pk-init draft for Kerberos which provides for both certificate (aka PKI) based registration as well as certificateless based registration .... aka directly registering the entity's public key. The business process of registering a name from a certificate as equivalent to a userid .... can be shown to be the same as directly registering a public key as equivalent to a userid. The issue then is whether all the additional business processes in support of the various registering process providing information indirection between the name in the certificate and the entity's public key provides real value or is purely redundant and superfluous (given that there has to be a complex infrastructure for not only creating the certificates .... but once created these certificates now also have to be managed). Now the intersection with certifications and smartcards (actually hardwoare token) .... was whether there was a unique token/certificate pair for every environment or whether there was one (or a very small number of) token(s) could be used across a multitude of environments. If the environment supported a registration process, then the above assertion that public key can be directly registered would support that the public key of a single token could be registered in multiple environments. The counter-argument is some future environment that has migrated to hardware token authentication potentially requiring a unique token per environment and an entity possibly having to manage hundreds of such tokens. So an additional assertion is an ideal place for certificates is where there isn't an additional registration process and the certificate is sufficent for establishing both authentication as well as permissions (aka all/any generic employee certificate gets an entity through the door). A corresponding scenario would be a system login that has no userid directory/registration and when presented with a login message with an attached certificate .... it is possible for the login process to establish the complete user environment from just the contents of the certificate (not requiring a userid directory/registration at all). The problem is that tends to require a unqiue certificate for each environment ... which may or may not imply a corresponding unique hardware token. If it requires a unique hardware token, then the future possibility is that people walk around with hundreds of hardware tokens. Moving it out of the digital signature domain but still in the area of authentication might be biometrics. There is the possibility that a login process directly registers a person's fingerprint in the userid directory. The person then types in their userid and applies their finger to a fingerprint sensor. I assert that the direct registration of a person's fingerprint in a userid directory is equivalent to the direct registration of a public key in the userid directory. However, the downside is that a person's fingerprint is, in effect, a shared-secret ... anybody copying the fingerprint representation and being able to regenerate it can impersonate that entity. The upside of public key registration is that it isn't a shared-secret, knowledge of the public key isn't sufficient to impersonate. So sort of a summary .... 1) understanding that the binding/registration process is indenpendent of certificates that represent that process can result in better designs dealing with the two sepaate issues and 2) when there are additional registries (like userid directories) it is possible to view certificates as a type of information indirection and that such levels of indirection may be redundant and superfluous (not that they can't work just that they are redundant and superfluous). some kerberos related threads: http://www.garlic.com/~lynn/subpubkey.html#kerberos and somewhat topic drift ... redundant and superfluous may represent additional complexity and cost that are hard to justify. From recent discussion about DNS, KISS, theory, and practice: http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm tjones@windows.microsoft.com on 2/12/2003 8:21 pm wrote: For better, or worse, the current sc logon to o/s's uses a cert in the sc. It could be argued that the sc really only needs to cache the user's name in an insecure manner, but the point is that a PKI is used to authenticate the user w/ the sc. It seems to work. It's hard to imagine how it could be improved by some structure other than a PKI. There is no biz rule associated w/ the authentication. I doubt that u can argue that it does not work. I am sure that a better sol'n is possible, that is always true. So, let's just use sc w/ cert for logon authN. Ok? ..tom To remove yourself from this list send a message Unsubscribe to epay-request@ca0.net (See attached file: winmail.dat) --0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384 Content-type: application/octet-stream; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IikQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAEAAAAFJFOiBBIGNoYWxsZW5nZQD1 BAEFgAMADgAAANMHAgAOAAgAHwAnAAUAPQEBIIADAA4AAADTBwIADgAIAB8AJwAFAD0BAQmAAQAh AAAAQjgwMDZCQjA3RjYxQzY0QzhGNzE2QjYyOTQzMTIyODQA/wYBA5AGADAoAAA5AAAAAwA2AAAA AABAADkAQkjbjEbUwgEeAD0AAQAAAAUAAABSRTogAAAAAAIBRwABAAAAOgAAAGM9VVM7YT13aW5k b3dzO3A9TWljcm9zb2Z0O2w9V0lOLU1TRy0xMC0wMzAyMTQxNjMxMzlaLTM3MQAAAB4ASQABAAAA EAAAAFJFOiBBIGNoYWxsZW5nZQBAAE4AALwvvnzTwgEeAFoAAQAAABsAAABseW5uLndoZWVsZXJA Zmlyc3RkYXRhLmNvbQAAAgFbAAEAAABTAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAbHlubi53 aGVlbGVyQGZpcnN0ZGF0YS5jb20AU01UUABseW5uLndoZWVsZXJAZmlyc3RkYXRhLmNvbQAAAgFc AAEAAAAgAAAAU01UUDpMWU5OLldIRUVMRVJARklSU1REQVRBLkNPTQAeAF0AAQAAABsAAABseW5u LndoZWVsZXJAZmlyc3RkYXRhLmNvbQAAAgFeAAEAAABTAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIA AAAAbHlubi53aGVlbGVyQGZpcnN0ZGF0YS5jb20AU01UUABseW5uLndoZWVsZXJAZmlyc3RkYXRh LmNvbQAAAgFfAAEAAAAgAAAAU01UUDpMWU5OLldIRUVMRVJARklSU1REQVRBLkNPTQAeAGYAAQAA AAUAAABTTVRQAAAAAB4AZwABAAAAGwAAAGx5bm4ud2hlZWxlckBmaXJzdGRhdGEuY29tAAAeAGgA AQAAAAUAAABTTVRQAAAAAB4AaQABAAAAGwAAAGx5bm4ud2hlZWxlckBmaXJzdGRhdGEuY29tAAAe AHAAAQAAAAwAAABBIGNoYWxsZW5nZQACAXEAAQAAABsAAAABwtP01jXujznxLdRP4ZyImUnwN2F4 ABRB2RgAHgBzAAEAAAA2AAAAQW5kZXJzIFJ1bmRncmVuOyBpZXRmLXBraXhAaW1jLm9yZzsgVG9y c3RlbiBIZW50c2NoZWwAAAAeAHQAAQAAABEAAABUb20gSm9uZXMgKC5ORVQpAAAAAB4AGgwBAAAA EQAAAFRvbSBKb25lcyAoLk5FVCkAAAAAHgAdDgEAAAAMAAAAQSBjaGFsbGVuZ2UAAgEJEAEAAAAc IQAAGCEAAKVyAABMWkZ1/qTVxQMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jB CsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2VkS72Y0EG8RezUDxlR8 YWgDcQKAEeMI7wn3O3scHw4wNR0/HRER4QxgY2cAUAsJAWQzNhFgC6U0siAQAipcDrIBkGcU8BcK oxHjImg0FPA8IUQAT0NUWVBFIEgAVE1MIFBVQkwASUMgIi0vL1dEM0MmAERURCUUM4QuMiYARU4i PiNt8yMPKEExOCRwJSInjyifjSsQMyIAKfBFQUQqTS8O8StvLe8pdDYO8DxNKEVUQQewQTDgPSKm RwnwBJBhdAWwIhcQaE9OVCdQVDFwBeFFongY4W5nZQZSdhMxBzPBAJACICA2LjUuwDY4NTEuMCd+ L08JKYM3NyRwVElUTIpFKk40DvBSRToRcHIgGOFsbAnwM2Ao7jX9JHAvN881/yrFORE7UCzPCysf PyQ1EWA8Qk9Ejlk+nSFxP79nOTYkcIBESVYgaWQ9RBAgT1dBUmULUHlUSGV4dDdwOTAU8GToaXI9 P0ByPpA/AwAhPiAAAEXBCrFGshjgXHH/AyFGJRFgQX9Cj0OWRY9Gn3NHqj7ZNjRLikffKXQ0JSnR RjJRIGYA0GU9RwcTOZAboj0jMFKTIHUAkHpRoDJLexgwAzBjbxPwA7IB0Ee5aQVABAAgYmsLgGQt b0wAGPFkeiAx8CAzYAVAPTxJRXnxCGEgcG8LgAVAA1JW0EZoVeFY8HN0Lij8Nf1DoS9RIkt5S4dN ywHAS4fvCqJcaAqAKPwwLJEmYEPg/1u/T79JL0o/S09MX1yfTn8/Yb9Qn1GmUw9UFFTNTm/+dDNw WaAx4FmRM3BY9FZhvRuwZzRRVeFuowRgYgMQjzNwV19jQgWgbXB1bnBdGRAgMbAJgFbSdwWwa9Fv gWYtbAuAZVo/W0//XF9db15/X49gn2lPYr9jz/9k32XvZv9oD2kfai9rP2xPrVS+U1bwAHB5b7Vw A2B/UZAJgAhwM3BzAnAxiIFj/3JhBHAx4HD/fURz1oiQBCD8d2U50I0CAiB0D3Ufe0//dz94T3lf em97f3yPfZ9+r/9/v4DPgd+C74P/hQ+GH4cvvZ2SQQQgWKFvJnKgLDmQvwSQBUCNQInBAQAAkGcx sP9WwAuAiJGLL4w8BPAJ8ArACzRAjjw4IgAmbmJzxnACgJlnXCdhAUCdR+kGUWVtijNmVbFu8wNg 3wJgqoBy8A3gjVB5jj+PT/+QX5Fvkn+Tj5SfnU+Wv5fP/5jfme+a/5wPnR+eL58/oE+9VL5Jt/CN QLbgAiAnBUDfGPAzwL4AAMCjkWMLEY0h/VWwaKNjBCCkoaUPtWJu8X5to1DAoXMGcpFu46NzKKdw wFYwC4BnKaSSZTPBd4jAcKUBAHasAW6Uc4B1+mxWwHUZIMMfxCVuwQuA/wIQrF+tb65/r4+wn7Gv sr//u2+037Xvtv+4D7kfui+7P2+8T71fvm9UvlTIeI0Qc751B4BumMeMyV/UQneNEfcEYInBGSBj ibJuoQOgbvL9wYgvo3NyYQbgo1AAcFbA/xjwVsDjc+PhHqBZIeHv1EL/yv/MD80fzi/PP9BP0V/S b//Tf9SP1Z/Wr9e/2M/Z39rvb9v/3Q/eH/DhTYjARPBwpwZxCfDIMXcvx3xzo1B9C4BjCkDGkud/ chSNUnD/GuAxsP8ROeDmgONRboFW8P5ijVAIkMFRbqKnf6iPqZp/MbDCURMxVmFu8ckv6GZz/wOP BJ+pmvQAHQDpH+ov6z//7E/tX+5v73/4L/Gf8q/zv//0z/Xf9u/3//kP+h/7L6Fe/wwfDS8TXwlP Cl8ZLw+fEK//Eb8hvxPfFO8V/xcPGB8lfz8aPyqfHF8dbx5/MfguLv1W4G0gLyE/Dj8mPydPKF// KW8yHz0vPj8q7yv/LQ8uHxMvL0HfMTFUkDxCUj81GUMCQhBG/0KPQ5xIUjFW0GFiSVYw/WA9LSox NRwxL5BjL5BqXMXfwWI2AH4gX0+iT2H/RlCOATuTSc9K3jB/MY8yn3kzqVRhAZDk0DSvNbI1vzYP Iv5IoDUbT1FY90argOxtOkvcSIEvWpo5iQHw4Hlubi53bwCNUHLAlkCq8HLQdIrhYS7lwbsHb0uD W+TQcNCKUDpfL/1gN11HnThRSLyN8lDPWd//Wu+IM+dBXH9dj6nX31CioCAyLzEzL1iwMDNgIDg6 Mjdgz0uDQf5NZF9lb2Z/Z49on971YoBval9rb2x3YKFKAaLGQC7wTkVUKW+fcK9xv3LPc3Pfe7RD Y3Vvdn+p10GjTVFgECBSdU1QZ+cxFjtuH+iEZTtwLXBrgGl4QGltYy7mwJ5ngoB1QGARpwAgSOdB +6bgq0BseR96L3s/fE99X/FppXViauPQaj9/76nI+FJFOqJAgp8A5ANQAVD9pwBniGGGX4dviH83 vzjP/5Pvkf+TDzoPOx88Lz//lg//UY9Ln0Q1NRuer0gfSS+i3/ef/1M1nXBQpG+leKHvov+vM3dX LzXB3nxt/UBw5zDbyBDfsHNioMVwb2AgwuL/yGAIwMhR5zDmgeM3wODkdPvEkORQdOGgwtAG4Y9v APT9m0BpX/DlIIVgCNyX75j/HYkvPI9ApwOwwWY9IoEkcHRwOi8vd7pQPC5npTAC4ISw5cEvfqli oi9hAiFtbVAuJHF6IzNgIjUcAvDf0LMSZgff0MLwYCB7SFlQRcBSTElOSyC537rvPbv4fVLBvfFg EABwXGP/TpHfwFjZvy/AP7wGnf+qCvuej4zKQTUQsu9vJOWwkMbveKDmgOFwTVBheQ+2D7cf98zv zf/PCnLfcAai5DfmsP+wAecwNCDnUa/iz8/Q387v77g/uU/EH8UvNbyPvZ++r//aP9tPwd/C798/ 4E/cEceP/8df12/Jf8qPkL/VT9Zf6CT7YvD+4GiwIAJATSCvgLAQ/Dc47MFgkNRQNBCwELvQxaUw dLSwcmQusaGxkfsG8+8xcwvgAkCwg2BQ6d/npxPv0zSAc2/r7+z/1uznrzHjcP1AbXXvEUSwjDDn tMLTc6cQY2sAkP+islC9sQBmsXBgsDQBApByDAz3I88FbrFQaYJAYFCvcLHA2/L/pyJhsSD4IGZc QfTf//Xv1uzv22Jw+fH4IPGV8CV/65DyEOPARMBjIfIQ8BJ2/9RB/lHvUfSh/o+z9LJQAH+/AY/W 7GJwprDrgASRcIVx/HVw+R/6K/H1+vwJ3wrv/8+/EF8Rba8BB4+0De9g8hBntFKxsbEhbicEIfKy ef+vgOtAslAYcfKwBqDrQLRf9xK/E8/SR2WvMbIgsmENstsVf6cTYrAw3dFnu5DyEPxvYzRw/kOv QA2Q1KD+JfevMCCQBaEsrvIXmxqvG7//Cy3ystOCHp+0DjcBNxCxEHcZ8BdxjDB1DDPyoylCav+v kPLQVwAdp/40ssAjjySfvxF8Hn8fjyCfIarMIWyxsD8NwAXg04AvYazgTWAgbv8MEPHg8qOwMCx/ LY8unf5/d6cEsbARUiDMcK9gXEBu/m3UQtOCr5DxcyhrsTErT/+yz6b104E1bzZ/EXww7zH/nTMF d6+ATzAAIWVx8jD31FAMUa9AZIIRslE9//+Uv01QP49AnxF88iAMkHLdsP51r4EqozShNOVGoEUT GGLxRRByaykPT0lPEW9OH/tPL1A6Ta8ShJClMK/CsDDPhdApdEbPpyIxKUx3siD/sjDyhfSwOsCy cDrA8oU/Xz9R31LvO8yxgf3w1KBha/+FcfpBJs8wX0MJ0xBDylk//1pPQa2vkFABBkEy9ilCsTH/ DICv4UYwBDIq9V5fpyI87/9Y/2KPY59Cf0OPZL9nX6ci/iixcP4AsDAqFKUw68CFYN/6I2n/aw8c zm2wcIPwVNN+aARQRRR4cAag2SEZomLHV3CxwLAwdm9sBqCxAP+wMQRycB9fbRpCYY9zz3Tf/24/ b0pWwCky+w/8H/0r+gL+MlbFeT+nIlgY8iDvEbIm73uvfL9bXbGwZmTBsbEI0fnwEW1w5EEXUiH1 8kEz4/9DwfEBBDKEj6ci7uRdAsxB/x3RZNENwGnPiC+JP2z/bg//bx+Nf0fk7tWPHJA/kU9QHP8q 89ODslAnwLIw1ELxkx4x//KFaKeEL3nvk6qZL5o/fc/7lK9lKCgFoAyQk/EMQnjD/7GhOgOfT3Ei Olru4Mxwoc//ot9QHBmRHjKyIHERF1JorP8GUdNRd+BGGfoCqD+Fk0tUf0vBTd+rf0//sv+0D7Ub SP5vKYB3USJgZuN34BpQO1L/WBOdopyh+CCvz7DfselLs3xkbwWgGGG177b/FH1l/9NTTKQZNE2S st+/v7T/w1/7xG/FelTx1niyuki8P3Ei+8UwXZAgM5ANkSkk70FLQf9mUwxRukjrYGYQd+LGP8dP /6PvQ/EpkWaT63G48Mw1yq8PcSLMpMHi8eBQS0kvXxbaGlCeoCJgHcJ18LBi/wxR7uAXUM7/0A+s rs6U0er/zPJYIdOPcRNxsPpC/jQ09P/Oke+Q+hF4wtWSGdrX/9kP/cVcKHHAOsAiYBexpwF3IO/X QHfguUFYQGOAc9yv3bX/j0Iz8P5RImANAsxEMvbOcmeQD+HP4t9wdddw7wAgv12QRgJD6T3RDVAW 0HDqIP/XcNyfKA7+UrnwNABxcYcQ/YZBKJ7zCN/qb+t/uyE7Uf1mk3bS0DRgF1PuT+9fKJjHjTHn /7LAIEknd7Dyb8fzf8VcdzRjbGFYYWaR/58CvkVNg+WPcNf64irk/ov/RXlM0d8Q+y/8P+utZmA0 UPv3Eo0xc3ag0xCGxjpARaD+afYRnSAW0ABfejRYQCmA/12h+a8ELwU/0R/ta9xj9hH/yaEZAJ1D ZzAW27wPPugLj/8Mnw2vDr/tmDsS7Il6sHXh/QOROxUPFh/FXxq/G8/Ijf/f8hKvaGRD72UjOnA0 cDyi/HR5skA9wt4K11BmQJj//x5vH3+gohoS8NIhD3EjWBLH17LMMMwCRE5TI5p14P3S0C1YUiWG d9EK8yYPJx97rK1mYHTj8jyhEn/dlnA+LZiFgHSqMlUxOxJDQV8Z4dugLyDkoJVgZ5zQdP51jyKM IdYA+VIujy+fHKzfE/IIyj3fE4neCijL82cw/7JBoTC+gGYQ4/KnsF3wugH9VDBkgHDfQzdfOG8o LhF//5fAZz9xBOyIgM+B34LsyTL/6DwT8XjQznJEgJ6gnUJAP/9BTxcv0iY1YeyFRK9xIuzxfnP6 wdVH3FDV4JzQVDBv/+ff6OFyUSQRS89M3xysNhL7coGGMXOc4Z7kznJQH5dk/0RwZkCdICyQl8A1 n0Q0Wnj/VJ9Vr4lt+Lg0oEmfWQ9xE//ggHqg6TNOv+ynl6FdP15P/xys9hZjtNXp1uDCUUqzYi// cSK6AWO07InVNeA/Zj9nT9851/X5UxJXnDSgQZ8vPHb/3xHNUHqQwjPXCUsEI6Iub/9vrxyOCMoK 2p0hjIDNsVrB/8pvPFpYBpei3GM/73hPeV//KOLeKG2fzCA91uPy+rHJMv98/8uz6EuK4kqyf++A /6yv/8mxNwHTAJRXZYCe8yWRzpL/CvQxxN4g32WGD/hvZa+Jn/+Krz9kpgDU45eibFWfEdKh/5jA 9vLfEJgh9gTMNd4hjx//PIWfET9kYOORf5KPgg/eMr/xcPDiyYGlIAlCLZZnvlH/mm+bfxyvn7+g z6HZAbP+JP+YH1ojNsP+1sJR/1r6wYuk96eNyeHxcHXeY6KPo5+hrP80yKY/hx/OY4wM+LBlgyWG /xp8R39Ij/Hjry8q0hn2q4//rJ9N72RDzjLB0XwEPrHsif/fRNKiP1XMk7N/tI9Iy4gy/7a/CpS4 j7mfea8I9JYDRIDffAW7ilMRKTDsenfxcJbS/zVgUvTCTyrSNWDDv8TPVr/+brwDQ3vx4wjBkPQ+ 1EM//8nztm9FbcxfzW+hrGVh5DD/MiJKs1Mfu3zRn9BU068Kk/9/r9Yv1z++CmDkBAB2QOIi7/+S ldTZQv4xbIwhO2BSMn89GtyfM3MpGN4/30+hrCh/CtZk/D9X/1D/lsqEdYR3/0sRyUApQAOh5T+Z J9kxuH9f6D+hnZ2wvZFykXU+UWb/ENDd8DIETzHeAQhhvwzw///yD6J/9j8fn3VRdVErJ+5PhyrS xrzZMklFVEYUgNxrLSkAqGIPwGYDAZfhfks24C4QdzAjgDTAbmBo//g/+U8GTSO2l9Ld4MoR/E/z kD09wGFrRIBSMT/BSxDvV9EiW0sRCwBsW4BLEAEP/wIfX1/QJnrgI3EH1AUvIh//lPQHURn2yB4J rwq/xd28j/9GgIW/3Vi+YPdBI3SH4ztR69pfYSBmdzBtVH8TLwuv/0OaI4DGvhbPbBW+lsHz82L/ MYCMUZYh82Fyc9tCCY8b3//3PhC/z5TJSR/fp0Qez+GP/4hvJI8ln51BAJJUQDTRH6D/CVHZMjPh ndCDYVtxKO8X3//aEdFRqsLzoHWA0BA7Qtky/3rAUsG+YCzPLd+6r7u3Yab/BAR8v+YIgwrmp3s7 2zU1v/82z+Bdg+3YpRUoOp/UuGVT/wQHuCBbcXrB4nGX4ftQPp+/P68DLe3k9Jd+9POpKBlw/3dR Q5/vS1wRsVIitBrcv+/VwP9jf1BweuB4Rz9IT3ecj55gjMF1uEBcApfSbusE4LHAbnaRY0Yx5vDI tP9Mr5AvlOQYEFcSexFXg10ff1O/QJ8skL5wbfq84Fbwd/8wYX9Ai6QitFhfy/KdsIVQ/3Nw7AD1 L1zP909jP2RPZVr+TmAB2TJ1obJwvnA9BMnzd8/45wH0NHOdsNAQwgBy/5TBYT/L8gcwVlEwcXai bFC/7JDL8BIvZx/gT+swbgew/5Tz7ZIv9k5U7ZK+Qc+AepD3YR995XIiL8/6WVDJEZfSv6Xi8B9w HxRPBDAEEG6OUP8fUZfhcx9XIYSxl+Efv8vUx3fSa9IJUW51bQBR4/HjB7ByEyhzKXgfeS8dDf3d 8GyXUPNhvmGXUG3wAHHtdBJthBBDMXUEUOPyfc/7/VN7KHOpUTTkexmA/4IP/859NGSEoggssNXK g9kUhj//p0Pd4Km3PGLQs8lIiY+Kn/8dDSH0Js8IAeyQhBI0VtNfv0157RFFCOQBfaAYMWcfMP+S f5OPcT/qkYP3lnnbgYVjv1KBmE+HPxZkg/Fpoi3L8P5nf9AfQkcfnD+Lj/vB/9D/WtBWcnsa0LOx UqCvYkPPYL8IkQgB/kFug27hnjVhWtD/LJHcAGskpE+lXwMtBOBDEv9uM7ggHuEZxXRfdW53IDBB 33sa9FK8R+0h4lBp1RCSb/+uP2UtYIHIox+QYoRucN4B/0qh4+OyL8vy4mAA4HIEiDC/tj+3T2U/ vU++X79pUx+R/wjhMQiQ6PtRIfEEQUZRUoD/bfBWlLsPWW8vxG7/wQ+dT/9zo+Kkw0yNT9oSQpbG LwY+56Qvyb+mT3Vm3CEfQneD/xmQkIC/ECJQuWIE06xcCPn/zy9EpH8gqqC10WtiBzLRb/fSf788 MHEvw0DrUGLAvzDLIVAWEGVScW956oBBy59iwIggtQmowAQQdWcFD/+ZSOww7KBi/9tPvx/jH+Qv 9eU7QVJBcpYAUJA8cDpDvnPUsTVSlxVPIvugeRmR/xqw3oAZcJFlTrJW8OEPINmf5g/nHyXvlhE8 EHkvCDz/9GEv8Y3yXuFpoZcBanJ9oP/rtPvQLDC6Ampj7N+QQ60v+++P3G5099AA4AgBBnoQI/// UchBtbVWlD3i67QYpisR//XPobPVVvc/+E/K71JFBwH3ISJ7CxqDaiEgTjNSQfPRf4gRNMb+X8c9 AD8BT+UsKP9W8rD7ITTxj9b1mD+QJdeg/+LvCe/lDxDPEd8S6yviGKH//IEasMhBTgQsoGxhKxGw 9PPrAkrQcWlGsfrKxe+hd//6YRO/FM96P3tHcpPVwLxx339wmnGQUCCCVvJpUnFXYP99oOkssb8H matmHC8dP51v/yygiEP70RiFdBmrbI6Jp5X3I09Es7XDaRKwQ1AlHyYvN1TtF4VLoG+gYnLQbGv/ fZDgsfMCanK6SqtnLA9117+8/y7/Er82Lzc/OEtNRcH/uXH70aMgWuEGlJXg8kA5sPtGYPxgZ+ow VmPioH9wn+H/WsLyYC2wRmDr4zQ/kCVGMf+agTkfOi/cfdZ8qqFQ4GDy/y2gp1HycJIQoqTL8z+z LVn/qLR9r5Ak67NBz0Lfr139tf+V73QS2VFgUMxAMRD7ELlw/38g/aBpkT+GDQVJD5BCDXe/Ng9L rxXPmcFPg46VedlQ/8ghP6N3UQ0FtNOXoDgQyBH/WCRQBP4fkAdTn1SvODxQCvvzsadAcohBkNUX lT0zlgL/zVyak1q/2RVPo1wfXS9eP99QOgzv3bDIQbECdsPwqIP/wyBhOWMPkELyKmTfZe84PF+a k5npUMxS/wdkOFuAJhRuYulwO28ZJ2Ew8Th4IEhv14B30Y6Da6//UqR2QDXgxSEXZ1wPbs+vTu9P j6PzjoCf4WXUgJYRjoD3msGrYasALQ0QhOBGgB/Ta3cP9tR5kJBk3bAF8HD+eblj80B5f3qPZv9Q N5YA//OF8pjq8LFT/IIYU93T+0L/f/+QQvvRlXIhcVbjCM+DX/+Eb6jDtUSitJeQeJOakZnp//Ir F3aI/4oFzCWLb4x/pm2rfuoq4GsMAHcDsGS6Ef8GhXEazDPUZFlwaqSSH4oD/4rIU4+VDzgvnS+e P8JdYAFzPNN+sXVtudBpwfuDMf4pIsHFMFbwoKDppGDnmv//ECItoOmj8hugD6EfTM/90//IQaeh s6DZUKySPNPHe+wT/4Y3pj/iFTFS/bWKcajfqe//nyzpUeqwUKPq8PpABCHFML894k4BxUG5YjKz UPJ06pD/X8FbsNEE1GApQa9P9tTO0P4ypLDzMrGfsq8CXxjSGNL7zM9ZciifAJCAci5ZcaSw//vU uG8tGIfjum+7f58sPDD8ZXetfOxxYuBXkjOC/XD/1QGkAJFE6aFOQvK2kc8P1+/UYCBRA7B2cGxk z8Rvb9//yQsg8urxfwEzEd/wSMFZAePUYNlRZmx1PLDZ8QwCf2Dm3bDKbwgD3/CZ4eqQcv5rzG/N f58sBWXS1ipS0M//0dYQn9Y/nw/bP9xPljxGYffTT1uzv5By6vD9sDEQTkDebK4ByfJBYTNgOt4v 3z8z3U9zezxBB9Tj4WY9AiLlwHRwOi8vd1npoC5nECCQQS4DcS+ifiGgbm4vmhBicRHVkIEu5cIj 4sYi5ZnkcHv7EMwwZORy0fAigfJgewBIWVBFUkxJTjxLIOkv6j/rT+xQfX0P7SHtcFbwB4BcY2Yx /ly0wOYw5sfvD/Af8S/lt0/lp94A90/d/jky5VAv/kHlkORf5W/mf/tP/F9EGv9ZAeF/y3NGYSAg F8IxoHFR/zMwCIAfxNl/0dcg8oY3/h9//y9D7b4YAV/UY/VAMbF4/0hSWPKBwNhmKlIqAogC2EL7 GdCPAUYfYBdQTkEGfweP8wifTiBzY1EwwuCG8oFwRz8BCl+5ckROUyrgS/xJUxSxUPFpsX6RWQGG UPsb8EUhZeRPED/9L+d/6I+P9H/1g7egM2BtMTLrgvwjOexv7X/ujxwPHR7yT//zXyD/Ig8d4PiP +F8ZP/p4qxM/W7NDU2BwmsFGo0C5o+AgUoZxuXDL0UcyUf5wpEIWnxevhJ2B8C7PL98fGL8Zzxrf JY/1kjIwMOYz9RDrkzI0Hg8fHyAv/zdvOH4jTyRfPF89bzlAKO/vKL80nyrfUg1OtUDVArdj92JF UTC2YmgMoTH/Mw80HKh3L220wWkL0SA0EP9IVGhR0dEWIMdQSg9LHzQfzzUvNj9A70H9NTY5bzp/ /zuPVE9VXj6vP79ZP1pPViDfRE9EH1F/Rj93bUXHgMCxQ7DBwsZQQVNWahB4/3xxirAPD0+/UM9R 31LvXZ/7Xq9WEDdWT1dfWG9sj22e/1uPXJ9xf3KPbmBhL2D/ab//Yx9kL2U/Zk9nX2hveg9/z3OA 34HlLS2CX4NvgXxJ305CTbEDIL8QxmBhFSA4kPO2wdSwdjpqD2sfdc/1VvfR4JphhzBm64Juj2+f cK+/jJ+NrXPPdN+Rf5KPbXlv/3k/gf/6f4Xvhv+aH5x/nY9vnp+fr6C/AyBqqLDHUECDtqAMYG93 cy5tdoB74xGtUHR2onv/uWMSsTIGLx2AOIMgODoyMft9wA6wd+MQt8AWj6LfoO//qc+q36vvrP+u D68XLUG1JT8VILKx1QEGYBUjxqB1ch/AUAShElCmn7ljbG9n6xKxLRFv9cAnx5C/wceS/8ayyQEV Mq+vsL/gTXaQii5AJm5ic3A7uakn/GEwrwiIYBMgDJBNMAEw89CR1GBndeOj0tS0v9Qm7ePxbEHg z1BuwfGuwOOg/8eQLRHUoMvQ2VC4L7k/uk/9tzFytwEKEOFBt/HUsMkBvwZgtEHZUNBQPZCzImIT Ef+0AsBv1GJ90E4xz4DCsQzz735QFODK4rcxZMOfxK+j/f0tIGETEBVQTkB2gOOBs/P/xpJM8b/l u3+8j72fyU8CY/3CgG3Cs03i0W/Sf9OOtwH/DXXMT81frsx/ANsgrrFJsZ53x6C+iX8AFgBvduOh 3mIF8OEvAhiJAHUWMMgC/6lgFVCLgAzhEsHLgi6/2389rr1U4hHHMcbhLSBiad56DsBNML8RffBv jeDQAf8BMNDV4A8LYs95EqHi/+QPv66/6t/r74e7EiAuUGIMxf51wvESwb9CDNTeMaVwt1H/5pDU cNZ/7n/vj/CSxxDob58CVMgCyyWy5N+hbCfHkZ8FsH3WFSLyYrdhbHcF4PvLAS1gZfOf9K/sz/wP /R/5/ipTbxUgC+DZwg3y9u/fC1O3McAi0NG3o2aysbZEHc9yTta/18/TjE9rP98GHwcvvasuoC0Q bf7v/////g8Mrw2/Ds8P3xDvEf8TD/8UHxUvFj8XT+XhLSAC38F0sm3fMSB5LlCzsWwaQP5mpfCp IMNgyvF2cH2hSLC/pWC3cd/QffAZIMAQVcfA//DwwDB+8L8BLREbr7YCSMG0eS2LsHG/YJBAQM/w /DAuTbEYfxmPF58jiVYg4ZtxRk9OVCSZmJ8lEL+14ih4JZi10yWftUY3m2IKUJu+MIsBL0RJVnsn zyvvZ5khtfMwTzFfNcI4m3FCT0RZm72bYAsyjzURN5txSFRNTAUkkH03QB4ANRABAAAAWwAAADxG N0I5NzgyNjkxMkJDNDQxOUQ1RERGNTNCMjE2OTQ1MzM5OUQ5M0BXSU4tTVNHLTEwLndpbmdyb3Vw LndpbmRlcGxveS5udGRldi5taWNyb3NvZnQuY29tPgAAHgBHEAEAAAAPAAAAbWVzc2FnZS9yZmM4 MjIAAAsA8hABAAAAHwDzEAEAAAAsAAAAUgBFACUAMwBBACAAQQAgAGMAaABhAGwAbABlAG4AZwBl AC4ARQBNAEwAAAALAPQQAAAAAAsA9RAAAAAACwD2EAAAAABAAAcw736a3UXUwgFAAAgw/6jwjEbU wgEDAN4/r28AAAMA8T8JBAAAHgD4PwEAAAARAAAAVG9tIEpvbmVzICguTkVUKQAAAAACAfk/AQAA AF8AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPUZJUlNUIEFE TUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049VEpPTkVTAAAeAPo/AQAAABUAAABT eXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEA AAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAeADBAAQAA AAcAAABUSk9ORVMAAB4AMUABAAAABwAAAFRKT05FUwAAHgAyQAEAAAAbAAAAbHlubi53aGVlbGVy QGZpcnN0ZGF0YS5jb20AAB4AM0ABAAAAGwAAAGx5bm4ud2hlZWxlckBmaXJzdGRhdGEuY29tAAAe ADhAAQAAAAcAAABUSk9ORVMAAB4AOUABAAAAAgAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGED4/ eT8DAAcQ7yAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABJVElTS0lORC1PRkhBUkRUT0dF VFlPVVJQT0lOVEZST01USElTUE9TVE5PVEVUSEFUVEhFUE9JTlRPRkxPR09OSVNUSEFUTU9CSUxF Q09NUFVURVJTTkVFRFRPV09SS09GRi1MAAAAAAIBfwABAAAAWwAAADxGN0I5NzgyNjkxMkJDNDQx OUQ1RERGNTNCMjE2OTQ1MzM5OUQ5M0BXSU4tTVNHLTEwLndpbmdyb3VwLndpbmRlcGxveS5udGRl di5taWNyb3NvZnQuY29tPgAA+ag= --0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384-- From owner-ietf-pkix@mail.imc.org Fri Feb 14 15:31:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03981 for ; Fri, 14 Feb 2003 15:31:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EK7wD19081 for ietf-pkix-bks; Fri, 14 Feb 2003 12:07:58 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EK7ud19075 for ; Fri, 14 Feb 2003 12:07:56 -0800 (PST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1EK7JCq014332; Fri, 14 Feb 2003 12:07:19 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <15SFDBQR>; Fri, 14 Feb 2003 12:07:59 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Aram Perez'" , PKIX Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 14 Feb 2003 12:07:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_017A_01C2D43A.DCBEF910"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_017A_01C2D43A.DCBEF910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > >> May be in different environments different such > technologies might be > >> usefull. What I am missing in this discussion is a clear list of > >> requirements for certificate retrieval. > > > > Alice wants to send email to Bob > > Alice does not know Bob's Certificate > > Alice does know Bob's email address. > > Bob's name is not unique > > But Bob's email is unique. Why can't Alice look up Bob's > certificate by his > unique email address? That is the whole big-thing point as Rowan Atkinson would say. > Can you please restate exactly what this "Web of Trust cert > path discovery > requirement" is? OK, you want to sent a meesage from UC Irvine to the Sorbone Paris. There is a certification path through the HEBCA bridge, the FBCA, le Ponte Authoritee Certification Franglaise and le Ecole Nationalle Ponte Authoritee Certification. So to get from A to B you have to know that there is a trust relationship that goes through the four bridge CAs, it is also a pretty strong one that is maintained under fairly strict scrutiny. But getting from A to B is going to be either inefficient or impossible unless you know that there is a structure here you can exploit. Cf the difficulty of IP routing without the concept of clouds. Phill ------=_NextPart_000_017A_01C2D43A.DCBEF910 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNDIw MDc1OVowIwYJKoZIhvcNAQkEMRYEFAbNsccScq/07wbgrsCKsjY/mERGMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAbr+M907I8ebcwvZ1E1evWRqNlpL//cXFcT2jtsNkjNRdKVNK 76TzQPn6MRoar3wgoEqGXOu/sK2KTQtDoDoswgXWXh78GVgTZIPukxGA6V0vQypSW4WymfHw6RaB PqNOvCKmzcNgW4Z1/ahUJ9/EemEA7AfWTa4PbR+htBLT8FMAAAAAAAA= ------=_NextPart_000_017A_01C2D43A.DCBEF910-- From owner-ietf-pkix@mail.imc.org Fri Feb 14 16:27:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05458 for ; Fri, 14 Feb 2003 16:27:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EL2iX22002 for ietf-pkix-bks; Fri, 14 Feb 2003 13:02:44 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EL2hd21998 for ; Fri, 14 Feb 2003 13:02:43 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <1T4XVLL6>; Fri, 14 Feb 2003 16:02:39 -0500 Message-ID: From: Carlisle Adams To: "'Jeffrey I. Schiller'" , Stephen Farrell Cc: ietf-pkix@imc.org, "Steven M. Bellovin" Subject: RE: AD Review of draft-ietf-pkix-rfc2510bis-07.txt Date: Fri, 14 Feb 2003 16:02:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D46C.68244880" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D46C.68244880 Content-Type: text/plain Hi Jeff, Thanks for your preliminary feedback on rfc2510bis-07.txt. We will split the references into Normative and Informational, as you suggest, and will add a more explicit reference in Section 2.2.2. As for your comment regarding the PKCS #10 protocol exchange over SSL (the model for certificate issuance employed by popular browsers), it is generally accepted that this mechanism is common and workable. It is also too limited for some environments. - It is not always the case that certificate issuance takes place over SSL-protected connections, and so total reliance upon the presence of an underlying secure channel seems unwise. It would be better to have protection mechanisms built into the issuance request/response protocol itself, if possible. - Passing a secret value along with the PKCS #10 in a form post, while authenticating the sender to some degree, does not authenticate the content of the PKCS #10: there is no cryptographic binding between the secret value and the data inside the PKCS #10 message. Again, conveying these together through a secure underlying transport such as SSL can help, but what if that transport isn't there? And, even if it is there, no binding exists once the two pieces pop out the other end, so if the CA doesn't act on this issuance request immediately, the value of the sender authentication is lost. It would be better to have a strong cryptographic binding between the shared secret used for sender authentication and the issuance request. - This has been discussed many times over the PKIX list over the past several years, but PKCS #10 does not readily accommodate key pairs that are to be used for purposes other than signing. If I have a key pair that can only be used for encryption, how can I use the private key to sign the PKCS #10 request? If I want to certify my Diffie-Hellman public key, how can I use my corresponding private key to sign the request (RFC 2875 provides a couple of mechanisms, but these do stretch the "spirit" of PKCS #10 somewhat). It would be better to have a protocol message (including subsequent challenge/response messages, if necessary) that can easily handle certificate issuance requests for different kinds of key pairs. - The syntax of PKCS #10 assumes that the requester already knows its own DistinguishedName (DN), as well as the DN of the CA. In many applications this will not be the case: as part of the issuance process, the CA will assign a DN to the entity and include this DN in the response (i.e., in the issued certificate). It would be better to have flexibility in the request message to allow the sender to be identified in some other way. - PKCS #10, even for environments in which it is a suitable technology, does not do anything more than request certificate issuance. Every other aspect of certificate life cycle management (update/renewal, revocation, recovery, etc.) needs protocol messages beyond PKCS #10. It would be better to have a single, comprehensive suite of protocols that encompasses the full life cycle of certificate use. For all the above reasons (and perhaps others that I couldn't remember off the top of my head), CMP/CRMF was created. In an attempt to accommodate the current browser-based solution, a PKCS #10 message can be carried in a CMP envelope, but this isn't really recommended. CMP/CRMF is intended to provide all the functionality of PKCS #10, while addressing every one of its limitations. Significant implementation and interoperability experience has shown that it does this quite successfully in many different kinds of environments. Carlisle. ------_=_NextPart_001_01C2D46C.68244880 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: AD Review of draft-ietf-pkix-rfc2510bis-07.txt

Hi Jeff,

Thanks for your = preliminary feedback on rfc2510bis-07.txt.  We will split the = references into Normative and Informational, as you suggest, and will = add a more explicit reference in Section 2.2.2.

As for your comment = regarding the PKCS #10 protocol exchange over SSL (the model for = certificate issuance employed by popular browsers), it is generally = accepted that this mechanism is common and workable.  It is also = too limited for some environments.

 - It is not = always the case that certificate issuance takes place over = SSL-protected connections, and so total reliance upon the presence of = an underlying secure channel seems unwise.  It would be better to = have protection mechanisms built into the issuance request/response = protocol itself, if possible.

 - Passing a = secret value along with the PKCS #10 in a form post, while = authenticating the sender to some degree, does not authenticate the = content of the PKCS #10:  there is no cryptographic binding = between the secret value and the data inside the PKCS #10 = message.  Again, conveying these together through a secure = underlying transport such as SSL can help, but what if that transport = isn't there?  And, even if it is there, no binding exists once the = two pieces pop out the other end, so if the CA doesn't act on this = issuance request immediately, the value of the sender authentication is = lost.  It would be better to have a strong cryptographic binding = between the shared secret used for sender authentication and the = issuance request.

 - This has = been discussed many times over the PKIX list over the past several = years, but PKCS #10 does not readily accommodate key pairs that are to = be used for purposes other than signing.  If I have a key pair = that can only be used for encryption, how can I use the private key to = sign the PKCS #10 request?  If I want to certify my Diffie-Hellman = public key, how can I use my corresponding private key to sign the = request (RFC 2875 provides a couple of mechanisms, but these do stretch = the "spirit" of PKCS #10 somewhat).  It would be better = to have a protocol message (including subsequent challenge/response = messages, if necessary) that can easily handle certificate issuance = requests for different kinds of key pairs.

 - The syntax = of PKCS #10 assumes that the requester already knows its own = DistinguishedName (DN), as well as the DN of the CA.  In many = applications this will not be the case:  as part of the issuance = process, the CA will assign a DN to the entity and include this DN in = the response (i.e., in the issued certificate).  It would be = better to have flexibility in the request message to allow the sender = to be identified in some other way.

 - PKCS #10, = even for environments in which it is a suitable technology, does not do = anything more than request certificate issuance.  Every other = aspect of certificate life cycle management (update/renewal, = revocation, recovery, etc.) needs protocol messages beyond PKCS = #10.  It would be better to have a single, comprehensive suite of = protocols that encompasses the full life cycle of certificate = use.


For all the above = reasons (and perhaps others that I couldn't remember off the top of my = head), CMP/CRMF was created.  In an attempt to accommodate the = current browser-based solution, a PKCS #10 message can be carried in a = CMP envelope, but this isn't really recommended.  CMP/CRMF is = intended to provide all the functionality of PKCS #10, while addressing = every one of its limitations.  Significant implementation and = interoperability experience has shown that it does this quite = successfully in many different kinds of environments.

Carlisle.

------_=_NextPart_001_01C2D46C.68244880-- From owner-ietf-pkix@mail.imc.org Fri Feb 14 17:02:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06601 for ; Fri, 14 Feb 2003 17:02:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ELgxh22973 for ietf-pkix-bks; Fri, 14 Feb 2003 13:42:59 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ELgwd22969 for ; Fri, 14 Feb 2003 13:42:58 -0800 (PST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h1ELh151025600 for ; Fri, 14 Feb 2003 13:43:01 -0800 (PST) Received: from [10.10.110.50] ([65.200.9.2]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id HABIZO00.NT0 for ; Fri, 14 Feb 2003 13:43:00 -0800 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 14 Feb 2003 13:42:58 -0800 Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP From: Aram Perez To: PKIX Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hallam-Baker, Phillip wrote: > >>>> May be in different environments different such >> technologies might be >>>> usefull. What I am missing in this discussion is a clear list of >>>> requirements for certificate retrieval. >>> >>> Alice wants to send email to Bob >>> Alice does not know Bob's Certificate >>> Alice does know Bob's email address. >>> Bob's name is not unique >> >> But Bob's email is unique. Why can't Alice look up Bob's >> certificate by his >> unique email address? > > That is the whole big-thing point as Rowan Atkinson would say. I'm afraid I don't understand. AFAIK, LDAP/X.500/SQL all can be set up to return a certificate given a unique email. Is the issue that companies/organizations do not set up their LDAP/X.500/SQL data stores to allow this? > > >> Can you please restate exactly what this "Web of Trust cert >> path discovery >> requirement" is? > > OK, you want to sent a meesage from UC Irvine to the Sorbone Paris. > There is a certification path through the HEBCA bridge, the > FBCA, le Ponte Authoritee Certification Franglaise and le Ecole > Nationalle Ponte Authoritee Certification. > > So to get from A to B you have to know that there is a trust > relationship that goes through the four bridge CAs, it is also a pretty > strong one that is maintained under fairly strict scrutiny. But getting > from A to B is going to be either inefficient or impossible unless you > know that there is a structure here you can exploit. So how does something like XKMS solve this? Because it appears that the issue is not just Alice getting Bob's certificate, it's how does Alice get all the intermediate certificates (that may or may not have a unique email). Aram From owner-ietf-pkix@mail.imc.org Fri Feb 14 17:25:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07524 for ; Fri, 14 Feb 2003 17:25:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EM0gE23435 for ietf-pkix-bks; Fri, 14 Feb 2003 14:00:42 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EM0fd23424 for ; Fri, 14 Feb 2003 14:00:41 -0800 (PST) Subject: surrogate/agent addenda (long) To: epay@ca0.net Cc: "Anders Rundgren" , ietf-pkix@imc.org, "Torsten Hentschel" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 15:02:02 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 05:02:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I claim that I can model an operational environment in terms of entities and permissions (for simplification attributes are also modeled as a kind of permission). Registry is defined to be the method that an operatinal environment uses to map entities to permissions. A registry may be a single operational thing or it may be made up multiple things both explicit and implicit. Digital signatures and public keys are used to authenticate entities to the operational environment. The operatinnal environment uses public keys in the registry to represent entities (since they are unique to the authentication of the entity). The mapping between public keys and permissions is a function of the registry entry. CA/PKI further extends the kinds of permissions to "delagation". A CA entity/public key is given the permission of delegation. A CA uses its own registry to provide a mapping between entities, public keys, and permissions. A CA then signs a static, stale copy of some of the fields in its registry and calls it a certificate. An operational environment can authenticate delegated permissions from a signed certificate by using the public key of a CA entity from its own registry. Just for some convention I'll call delegation entities: surrogates/agents. Full blown PKI defines the possibility of a multi-level delegation as a trust hierarchy. So my repeated assertion is that if the operational environment accesses a surrogate/agent registry entry (local, remote, online, etc) then correspond surrogate/agenty certificate can be shown to beredundant and superfluous. So, I've managed to explain this redundant and superfluous characteristic in a number of different ways: 1) a registry entry can contain anything that a certificate can contain, therefor all fields that can occur in a certificate can also be placed in a surrogate/agent registry entry. Also, for every field that can exist in a certificate can be placed in a registry entry. When all fields from a certificate are placed in a registry entry, the certificate can be compressed to zero bytes. These certificates aren't actually redundant and superfluous, they are just zero bytes. 2) the creation of a registry entry for a surrogate/agent is equivalent to a registration authority business process. anything that is done during a CA's RA process can be done during the creation of a registry entry for the surrogate/agent. If necessary, this can be viewed as caching the certificate in the surrogate/agent registry entry. Then while the certificate isn't strictly redundant and superfluous, any transmission of the certificate is redundant and superfluous since the operational environment already has access to the cached entry. This is especially useful when the inclusion of a certificate in a transmission represents a painful bloating of the total transmission size. 3) when there is a directly accessable registry entry (local, remote, online, etc) for a surrogate/agent, then the certificate may just represent information indirection .... somewhat like DNS system mapping of hostname to ip-address. the registry entry contains some value that can be matched to a field in the certificate. This provides a indirection mapping between the permissions in the registry entry and the entity's public key in the certificate (authenticated & deligated by the CA signatures and the CA entry in a directly accessable registry entry). However, since nay value that can occur in a certificate can also be placed in the registry entry, the public key from certificate entry can be directly placed in the surrogate/agent registry entry, eliminating the indirection provided by the certificate and making the use of the certificate redundant and superfluous . 4) an operational environment may require direct access to a surrogate/agent registry entry (local, remote, online, etc) because of permissions expressed in terms of aggregation information (information that is maintained in the registry entry that represents information aggregation and is a difficult paradigm for a static, stale certificate) or permissions expressed in terms of real-time or near real-time information (again difficult paradigm for a static, stale certificate). 5) If a static, stale certificate provides an identifier that is used to index a surrogate/agent registry entry (local, remote, online, etc) then it is also possible to include the same identifier as part of the message digitally signed by the surrogate/agent. As before, such a surrogate/agent registry entry can include anything that a certificate can include, including the public key of the surrogate/agent. By directly placing the public key in the surrogate/agent registry entry, and directly accessing the surrogate/agent registry entry using an identifier from the signed message, then the signed message can be authenticated using the public key from the directly accessed surrogate/agent registry entry. The directly accessed surrogate/agent registry entry can contain any other field that might exist in the certificate, including all possible permission values. Since the digital signed message can be authenticated without having to resort to the certificate and since the directly accessed surrogate/agent registry entry can contain any field that a certificate can contain, the static, stale certificate transmitted as part of the message is redundant and superfluous . The simplest scenario for a static, stale certificate is in an operational environment that only accesses a CA delegation registry entries and permissions are solely established on the basis of the contents of the CA registry entry and the contents of the certificate. This is the employee certificate that is used for door entry. The door entry operational environment only contains the public key of one or more CAs. The door is opened purely based on being able to validate the CA's signature on the certificate and then validate the employee's signature using the public key in the certificate. For opening the door, there is no recourse to any employee specific entry. This is the typical "offline" door operation typical of low value situations. Higher value door operations tend to be "online" in the sense that they directly access employee specific registry information. Such online permission entry can be based on timely information (like has the employee been fired within the past couple hours) or aggregation (what other things has the employee done in the recent past). It is in the accessing of the employee registry entry (local, remote, online, etc) for timely and/or aggregated information that makes the use of the static, stale certificate redundant and superfluous. Similarly a portable device can either be "offline" in the sense that its operation is totally determined from just a CA public key registry and a static, stale certificate (and doesn't have direct access to the surrogate/agent registry entry). Lets say there are large number of "public" portable device and anybody can utilize any device so long as they have a valid certificate for device useage. However, a certificate can become redundant and superluous if the device has a surrogate/agent specific registry entry that it references (since it is possible to register any information that might be found in a certificate, in a surrogate/agent registry entry). A portable device that might contain a surrogate/agent specific registry entry might be a owner-specific paradigm (i.e. the surrogate/agent registry entry in the device corresponds to the owner). A onwer-specific paradigm could be implemented with certificates if the certificate contained the device specific identifier. The device would only work when a certificate was presented that contained the device-specific identifier in one of the certificate fields. Lets say we are looking at a hardware token implementation as keys for automobiles. For an owner specific paradigm there can be a certificate/PKI based implementation or a certificate-less based implementation. In the PKI-based implementation the automobile's internal permission registry table contains one or more CA public keys. The car starts for any hardware token that has a digital signed certificate that specifies the specific automobile serial number and authenticated by any of the CA public keys (and of course the hardware token signs a valid message that is authenticated from the public key in the certificate). The certificate-less implementation replaces the CA public keys in the automobile's internal permission registry table with public keys of the owner's hardware tokens. Then only the directly listed hardware tokens are able to start the automobile. In the certificate-less scheme, there would be a administration mode used in conjunction with a valid hardware token to add/delete public keys in the automobile's registry. In the PKI-based implementation for "owned" automobile operation, it becomes somewhat more problamatical to invalidate hardware tokens (aka certificates) for the automobile. One method would be to create registry entries for invalidated certificates (aka public key/hardware token). However, I would assert as soon as surrogate/agent specific entries are required for invalidated public keys .... then the infrastructure has been established making certificate-less operation KISS (aka static, stale certificates being redundant and superfluous). Just create a positive list/registry of public keys .... possibly totally eliminating the delegation permission associated with CA public keys. The automobile registry than has permissions like administrative mode, start automobile, open trunk, open doors, etc for each public key (aka hardware token). It is problamatical whether CA public keys would be retained in the automobile registry solely associated with manufacture and service operation. Standard automobile operation would be straight certificate-less with the owner's hardware tokens being directly registered in the automobile's registry table. However, there might be non-ownership related permissions like various service operations. There could be a manufacture CA delegation permissions associated with service operation and independent of automobile serial/identification. The manufacture's public key would be in the automobile's table with delegation permissions. The manufacture would sign public key certificates for service operations, enabling service specific permissions for all cars from the manufacture. However, CRLs really become a nightmare in this situation. I would contend that a much KISS solution is that the service operation goes online with the manufacture (in much the same way that POS terminal do online transaction) and that the automobile authenticates the service operation by accessing the manufacture's online database. The manufacture's public key is still in the automobile registry .... not for purposes of validatting certificates but for purposes of validating online communcation with the manufacture for authentication of real-time service organization delegation. As a result, the operation is online with direct access to registry entries for service organizations and therefor service organization certificates are redundant and superfluous. past references regarding compression of certificates to zero bytes: http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ? http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key? http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates past references to methodology of registry operation caching certificate kind of information (making certificate transmission redundant and superfluous) http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda) http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure http://www.garlic.com/~lynn/aadsm4.htm#8 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC) http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key? http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key? http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal http://www.garlic.com/~lynn/2003.html#52 SSL & Man In the Middle Attack past discussions of static, stale certificate issues vis-a-vis aggregated/timely information: http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against Virtual Banks (fwd) http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs http://www.garlic.com/~lynn/aadsmore.htm#client2 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsm2.htm#arch4 A different architecture? (was Re: certificate path http://www.garlic.com/~lynn/aadsm2.htm#availability A different architecture? (was Re: certificate path http://www.garlic.com/~lynn/aadsm2.htm#mauthauth Human Nature http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB http://www.garlic.com/~lynn/aadsm4.htm#01 redundant and superfluous (addenda) http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI http://www.garlic.com/~lynn/aadsm9.htm#softpki24 Software for PKI http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your account-authority model (small clarification) http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital Signatures ... in support of x9.59 http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#x9flb12 LB#12 Protection Profiles http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work? http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and PKI (addenda) http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III http://www.garlic.com/~lynn/aadsm12.htm#20 draft-ietf-pkix-warranty-ext-01 http://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II) http://www.garlic.com/~lynn/aadsm13.htm#0 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#2 OCSP value proposition http://www.garlic.com/~lynn/aadsm13.htm#3 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#6 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads http://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/98.html#0 Account Authority Digital Signature model http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2000.html#42 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation http://www.garlic.com/~lynn/2001.html#67 future trends in asymmetric cryptography http://www.garlic.com/~lynn/2001c.html#8 Server authentication http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site. http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site. http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key? http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks? http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix@mail.imc.org Fri Feb 14 21:45:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12801 for ; Fri, 14 Feb 2003 21:45:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1F2LIp00573 for ietf-pkix-bks; Fri, 14 Feb 2003 18:21:18 -0800 (PST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1F2LHd00569 for ; Fri, 14 Feb 2003 18:21:17 -0800 (PST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53] (may be forged)) by pigeon.verisign.com (8.12.1/) with ESMTP id h1F2JLiq011738; Fri, 14 Feb 2003 18:19:21 -0800 (PST) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <15SCLY2C>; Fri, 14 Feb 2003 18:21:19 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Aram Perez'" , PKIX Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 14 Feb 2003 18:21:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_01B4_01C2D46F.052A45B0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C2D46F.052A45B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > I'm afraid I don't understand. AFAIK, LDAP/X.500/SQL all can > be set up to > return a certificate given a unique email. Is the issue that > companies/organizations do not set up their LDAP/X.500/SQL > data stores to > allow this? You can go rabbit hunting with a howitzer, but that does not make it the best choice. The point is that you do not need anything more than exact match and in fact you will not have anything else available in the internet case. So you do better with a system that is designed for that and that alone. > So how does something like XKMS solve this? Because it > appears that the > issue is not just Alice getting Bob's certificate, it's how > does Alice get > all the intermediate certificates (that may or may not have a > unique email). XKMS does not impose a particular data model on the problem. The XKMS service can use local knowledge of the trust topology structure to assist finding the certification paths and can pre-calculate and cache such paths. The directory approach forces the client to do this work since the searches required do not conform to the restrictions of the data model. Phill ------=_NextPart_000_01B4_01C2D46F.052A45B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNTAy MjEyMVowIwYJKoZIhvcNAQkEMRYEFPQF1G19lfa0J7dPhpqTmaJXnj2oMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAnR05EXITfrTDOmXsILsASszfS9dB+AY5+AIZFFbC5jyL0CB0 eefam+1XtVelDeH79xZ47ItiSZKBsVdOXHyS0QKCiP/HRzacPefLLMrBSC6qbS9CP1UK9FG4rTn7 53AdJXkKMtKOWr0qeEMlx79u7gOYMD1jSG5gafrhCORQhlYAAAAAAAA= ------=_NextPart_000_01B4_01C2D46F.052A45B0-- From owner-ietf-pkix@mail.imc.org Sat Feb 15 18:36:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08684 for ; Sat, 15 Feb 2003 18:35:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1FN3t912951 for ietf-pkix-bks; Sat, 15 Feb 2003 15:03:55 -0800 (PST) Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1FN3rd12947 for ; Sat, 15 Feb 2003 15:03:54 -0800 (PST) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 22764708 for ietf-pkix@imc.org; Sat, 15 Feb 2003 17:03:55 -0600 Date: Sat, 15 Feb 2003 17:03:52 -0600 (CST) From: Eric Norman To: PKIX list Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/signed; BOUNDARY="-2140662931-1674615169-1045350236=:20274"; protocol="application/x-pkcs7-signature"; micalg=sha1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2140662931-1674615169-1045350236=:20274 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Feb 2003, Aram Perez wrote: > Hallam-Baker, Phillip wrote: > > > Alice wants to send email to Bob > > Alice does not know Bob's Certificate > > Alice does know Bob's email address. > > Bob's name is not unique > > But Bob's email is unique. Why can't Alice look up Bob's certificate by his > unique email address? Going off on a tangent here, but it's a tangent that doesn't seem to have been explored. Why can't Alice get Bob's up-to-date encryption certificate when she clicks on Bob's mailto URL? Eric Norman "I may be just a butterfly, but watch out if I flap my wings". ---2140662931-1674615169-1045350236=:20274 Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: BASE64 MIIHNQYJKoZIhvcNAQcCoIIHJjCCByICAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBUswggKVMIIB/qADAgECAgICejANBgkqhkiG9w0BAQQFADCB kTELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xIDAe BgNVBAsTF0ludGVybmV0MiBEZW1vbnN0cmF0aW9uMRgwFgYDVQQDEw9IRVBL SSBDbGllbnQgQ0EwHhcNMDIwODI0MTkwNjE5WhcNMDMwOTI5MTkwNjE5WjCB vzELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xKzAp BgNVBAsTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxFDAS BgNVBAMTC0VyaWMgTm9ybWFuMSUwIwYJKoZIhvcNAQkBFhZlam5vcm1hbkBk b2l0Lndpc2MuZWR1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALReNRkixlpT urV2ogd3BCWgxihjl0j6+a7EGnV+SCCBsqjWqKcVTCedD49lTbHLnmgejUd+ tfdiy5Dg+//ZpMUCAwEAAaMQMA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQB/5AydG4TKKO6ZFiI9d/m03260pf4lBp81mlD3B9IQl0ofJ1gl NtZlTZyC1N4x+c82eqMNBIBrcA/dcaoy0LyNWRrRtt+et+JkNXfrhLuwUWtQ NR8Gq3i00C2th4DienwNbh9FoVo6gru6sC3i4TRxwKnDbKus6r2xvKlOQt3E azCCAq4wggIXoAMCAQICAgG/MA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTAeFw0wMTA3MTcxODI0MzFaFw0yMzA2MTMxODI0MzFaMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6xU1OJP0g+mU9srwrQLC zWXAMlkv3DKb+lEugUQTTV8/bi+ZgcG3oan7ZcxpiN+k+3biz8vcxIbxCMcI NZvi0u0mdDoLjaAtZtqvORMgbm3XkJhzgtGMmaxFLUBlhebSdd7YeV4/X4lJ FAIE3hcaXWayirI+jwGkaD0UgELs3ysCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQCkRVbjdpKkibnoRNqoDGWxu1Bno4eS pw0GlIwkveeyhURWvBA2neUzBuFlG2JinTx7/YtHYf19vwzN+GSEzv7cUl0l p27Uc0iamMYxzCCkgSvwgOn87FrdNgVA6e1QYvjzu0XdvbVyBqr0zH5a0Cel /kzV7l/+idyjGPeNHC1lqzGCAbIwggGuAgEBMIGYMIGRMQswCQYDVQQGEwJV UzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAwHgYD VQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50ZXJu ZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBDQQIC AnowCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wMzAyMTUyMzAzNTVaMCMGCSqGSIb3DQEJBDEWBBRQ thBxUKrT7qSsejv637RZlBEwADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAa53giZokvQ29QOk/3Uac fOBLLClrPA359mjCos4w3GmFoJ0eQrMZrk6puESEclpl8rSvYbwGF2qkPKQ5 KNT3WQ== ---2140662931-1674615169-1045350236=:20274-- From owner-ietf-pkix@mail.imc.org Sat Feb 15 21:07:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09925 for ; Sat, 15 Feb 2003 21:07:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1G1hjG15541 for ietf-pkix-bks; Sat, 15 Feb 2003 17:43:45 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1G1hhd15535 for ; Sat, 15 Feb 2003 17:43:43 -0800 (PST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1G1h8Cq026386; Sat, 15 Feb 2003 17:43:08 -0800 (PST) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id <15SG6RHQ>; Sat, 15 Feb 2003 17:43:45 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Eric Norman'" , PKIX list Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Sat, 15 Feb 2003 17:43:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01C2D532.EE2309F0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C2D532.EE2309F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Eric, I did look into fixing SMTP to upport that mode. But SMTP is really, really yukky, there are a lot of moving parts, lots of legacy stuff. The proposal I am pushing is using the DNS to locate a discovery service (SRV already supports this), with my preferred discovery service being XKMS locate which is a lot simpler to implement than LDAP. It would also be possible to implement an HTTP interface on top of NAPTR but SRV is not quite up to it. Phill > -----Original Message----- > From: Eric Norman [mailto:ejnorman@doit.wisc.edu] > Sent: Saturday, February 15, 2003 6:04 PM > To: PKIX list > Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP > > > On Fri, 14 Feb 2003, Aram Perez wrote: > > > Hallam-Baker, Phillip wrote: > > > > > Alice wants to send email to Bob > > > Alice does not know Bob's Certificate > > > Alice does know Bob's email address. > > > Bob's name is not unique > > > > But Bob's email is unique. Why can't Alice look up Bob's > certificate by his > > unique email address? > > Going off on a tangent here, but it's a tangent that doesn't seem > to have been explored. > > Why can't Alice get Bob's up-to-date encryption certificate > when she clicks on Bob's mailto URL? > > > Eric Norman > > "I may be just a butterfly, > but watch out if I flap my wings". > > > ------=_NextPart_000_000E_01C2D532.EE2309F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNjAx NDM0NFowIwYJKoZIhvcNAQkEMRYEFLaOdBtxrDJmgq/xwB/wiK1VC7BMMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAZ27+j6Nk4T8vhV21mOSHVHNojpfOI0c4IK2ByZuK+rjR9ncT jJHQY7z/n2JhoS99Jo689Y6c7ZFx0rejWH9kBLGGh5PcZUrVR3fdcQcKzdMgvCPFuJjwuCUjUk3d FtYLhhyPUke7QDYvY48HB0OmhquDvIoRYplv0SFNe9nSp1sAAAAAAAA= ------=_NextPart_000_000E_01C2D532.EE2309F0-- From owner-ietf-pkix@mail.imc.org Sat Feb 15 21:57:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10587 for ; Sat, 15 Feb 2003 21:57:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1G2bwt16804 for ietf-pkix-bks; Sat, 15 Feb 2003 18:37:58 -0800 (PST) Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1G2bud16800 for ; Sat, 15 Feb 2003 18:37:56 -0800 (PST) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 22765805 for ietf-pkix@imc.org; Sat, 15 Feb 2003 20:37:59 -0600 Date: Sat, 15 Feb 2003 20:37:58 -0600 (CST) From: Eric Norman To: PKIX list Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/signed; BOUNDARY="-2140662931-1575522160-1045363079=:20274"; protocol="application/x-pkcs7-signature"; micalg=sha1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2140662931-1575522160-1045363079=:20274 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: On Sat, 15 Feb 2003, Hallam-Baker, Phillip wrote: > I did look into fixing SMTP to upport that mode. But SMTP is > really, really yukky, there are a lot of moving parts, lots of legacy > stuff. I'm thinking something simpler. Methinks I confused the idea by using the phrase "mailto URL". Perhaps I should have referred to it as whatever you click on to send electronic mail to someone. Trying to do it with SMTP would couple the message encryption process with the process of injecting the message into the delivery system; I don't think that's a good thing. > The proposal I am pushing is using the DNS to locate a discovery > service (SRV already supports this), with my preferred discovery service > being XKMS locate which is a lot simpler to implement than LDAP. Since some browsers already support a MIME type for receiving encryption certificates, I'm thinking that the "send me mail" link that someone puts on (for instance) their home page includes an attribute that says how to fetch their encryption key (probably from their home page file space in this case). > > -----Original Message----- > > From: Eric Norman [mailto:ejnorman@doit.wisc.edu] > > Sent: Saturday, February 15, 2003 6:04 PM > > To: PKIX list > > Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP > > > > > > On Fri, 14 Feb 2003, Aram Perez wrote: > > > > > Hallam-Baker, Phillip wrote: > > > > > > > Alice wants to send email to Bob > > > > Alice does not know Bob's Certificate > > > > Alice does know Bob's email address. > > > > Bob's name is not unique > > > > > > But Bob's email is unique. Why can't Alice look up Bob's > > certificate by his > > > unique email address? > > > > Going off on a tangent here, but it's a tangent that doesn't seem > > to have been explored. > > > > Why can't Alice get Bob's up-to-date encryption certificate > > when she clicks on Bob's mailto URL? > > > > > > Eric Norman > > > > "I may be just a butterfly, > > but watch out if I flap my wings". > > > > > > > Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". ---2140662931-1575522160-1045363079=:20274 Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: BASE64 MIIHNQYJKoZIhvcNAQcCoIIHJjCCByICAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBUswggKVMIIB/qADAgECAgICejANBgkqhkiG9w0BAQQFADCB kTELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xIDAe BgNVBAsTF0ludGVybmV0MiBEZW1vbnN0cmF0aW9uMRgwFgYDVQQDEw9IRVBL SSBDbGllbnQgQ0EwHhcNMDIwODI0MTkwNjE5WhcNMDMwOTI5MTkwNjE5WjCB vzELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xKzAp BgNVBAsTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxFDAS BgNVBAMTC0VyaWMgTm9ybWFuMSUwIwYJKoZIhvcNAQkBFhZlam5vcm1hbkBk b2l0Lndpc2MuZWR1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALReNRkixlpT urV2ogd3BCWgxihjl0j6+a7EGnV+SCCBsqjWqKcVTCedD49lTbHLnmgejUd+ tfdiy5Dg+//ZpMUCAwEAAaMQMA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQB/5AydG4TKKO6ZFiI9d/m03260pf4lBp81mlD3B9IQl0ofJ1gl NtZlTZyC1N4x+c82eqMNBIBrcA/dcaoy0LyNWRrRtt+et+JkNXfrhLuwUWtQ NR8Gq3i00C2th4DienwNbh9FoVo6gru6sC3i4TRxwKnDbKus6r2xvKlOQt3E azCCAq4wggIXoAMCAQICAgG/MA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTAeFw0wMTA3MTcxODI0MzFaFw0yMzA2MTMxODI0MzFaMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6xU1OJP0g+mU9srwrQLC zWXAMlkv3DKb+lEugUQTTV8/bi+ZgcG3oan7ZcxpiN+k+3biz8vcxIbxCMcI NZvi0u0mdDoLjaAtZtqvORMgbm3XkJhzgtGMmaxFLUBlhebSdd7YeV4/X4lJ FAIE3hcaXWayirI+jwGkaD0UgELs3ysCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQCkRVbjdpKkibnoRNqoDGWxu1Bno4eS pw0GlIwkveeyhURWvBA2neUzBuFlG2JinTx7/YtHYf19vwzN+GSEzv7cUl0l p27Uc0iamMYxzCCkgSvwgOn87FrdNgVA6e1QYvjzu0XdvbVyBqr0zH5a0Cel /kzV7l/+idyjGPeNHC1lqzGCAbIwggGuAgEBMIGYMIGRMQswCQYDVQQGEwJV UzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAwHgYD VQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50ZXJu ZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBDQQIC AnowCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wMzAyMTYwMjM3NThaMCMGCSqGSIb3DQEJBDEWBBQM 2sjHgxQ9JQ3OagWYgfifZnH3STBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAOiXwOXJnwBTanVRscWYC OBZgTiQbo+akgbhM5FxjOawhCG5FUf5uW1oVnh5RWJ36n0Brif8wMjNGpQ96 4Q5viQ== ---2140662931-1575522160-1045363079=:20274-- From owner-ietf-pkix@mail.imc.org Sun Feb 16 04:52:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24474 for ; Sun, 16 Feb 2003 04:52:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1G9XMb19687 for ietf-pkix-bks; Sun, 16 Feb 2003 01:33:22 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1G9XLd19683 for ; Sun, 16 Feb 2003 01:33:21 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h1G9XEoC001697; Sun, 16 Feb 2003 10:33:14 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <005901c2d59d$07343940$0500a8c0@arport> From: "Anders Rundgren" To: "Hallam-Baker, Phillip" , "PKIX list" , "Eric Norman" , "Russ Housley" References: Subject: Getting the encryption key. Was: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Sun, 16 Feb 2003 10:23:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit >Going off on a tangent here, but it's a tangent that doesn't seem >to have been explored. >Why can't Alice get Bob's up-to-date encryption certificate >when she clicks on Bob's mailto URL? Right on Eric! I think the whole S/MIME-thing is pretty awkward to use for anybody. I have toyed with the following idea for a while: An SMTP-extension holding an optional "encryption certificate lookup object" would allow a more dynamic use of encryption. This object should preferably be distributed as a part of a standard e-mail message, and hopefully "land" in the address book completely automatically. This extension could also be supplied in an X.509 extension. Phill: XKMS et. al. _do_ need an SMTP extension to become fully useful. To go from a mailto directly, doesn't this require an enhanced mailto URL unless mail clients are supposed to do XKMS/LDAP/CertStore "fishing" using DNS SRV-records etc? I'm not so sure that such "fishing" will prove to be very fruitful as it requires mail-providers (e-mail domain owners) to maintain keys that often come from other domains (TTP CAs). That needs yet another special-purpose directory "behind the scene" to work. Since you anyway have to upgrade e-mail and browser software on a regular basis due to viruses and "improvements", I can't see that an encrypted-mailto URL and an SMTP-extension would be such major PITAs. Existing systems would not break AFAIK. All other suggestions also effectively require as a minimum (apart from possible CA changes), updated e-mail client software. But is this a W3C, SMTP, S/MIME, or PKIX-issue? Anders R From owner-ietf-pkix@mail.imc.org Sun Feb 16 08:16:29 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25919 for ; Sun, 16 Feb 2003 08:16:28 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1GCvvU02850 for ietf-pkix-bks; Sun, 16 Feb 2003 04:57:57 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1GCvtd02841 for ; Sun, 16 Feb 2003 04:57:56 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 16 Feb 2003 05:56:21 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/16/2003 07:59:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: somewhat addenda to question about '83 OSI .... while iso/x3s3.3 couldn't have a work item for standard that violated OSI (i.e. HSP, high-speed protocol .... direct from level4/transport to LAN/MAC interface which sits in the middle of level3/network) .... x3s3.3 could have a work item that studied HSP. note also that IP also violated OSI ... since it is a layer that sits between level4/transport layer and level3/network layer .... the inter-networking layer. however, IETF doesn't have any qualms about having IP interface directly to LAN/MAC. as before ... internet archeological references from 82/83: http://www.garlic.com/~lynn/rfcietf.htm#history 20th anniversary of the internet! http://www.garlic.com/~lynn/2002p.html#38 20th anniversary of the internet http://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet http://www.garlic.com/~lynn/2002q.html#22 20th anniversary of the internet and a little more thread drift, a recent archeological reference to something else that i was doing about that time http://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard? and the whole thing about thread between loosely-coupled, sysplex, high availability, cluster, supercomputers, and electronic commerce: http://www.garlic.com/~lynn/2001i.html#52 -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix@mail.imc.org Mon Feb 17 06:31:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20502 for ; Mon, 17 Feb 2003 06:31:39 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HAkKY18071 for ietf-pkix-bks; Mon, 17 Feb 2003 02:46:20 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HAkJd18067 for ; Mon, 17 Feb 2003 02:46:19 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1HAkDU25292 for ; Mon, 17 Feb 2003 19:46:13 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate52.nec.co.jp [10.7.69.191]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1HAkD320053 for ; Mon, 17 Feb 2003 19:46:13 +0900 (JST) Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.109.63.71]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h1HAkCH04920 for ; Mon, 17 Feb 2003 19:46:12 +0900 (JST) Received: from smtp4.necst.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-01/28/03) with ESMTP id TAA21479 for ; Mon, 17 Feb 2003 19:46:08 +0900 (JST) From: k-fujino@pb.jp.nec.com Received: by smtp4.necst.nec.co.jp id h1HAjor11096 ; Mon, 17 Feb 2003 19:45:50 +0900 (JST) Received: from ecpc15 by smtp4.necst.nec.co.jp with SMTP id h1HAjme11093 for ; Mon, 17 Feb 2003 19:45:50 +0900 (JST) To: ietf-pkix@imc.org Subject: SkipCerts Question [RFC3280] Reply-To: k-fujino@pb.jp.nec.com Message-Id: <20030217194548k-fujino@smtp.necst.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.08D] ID:NECST0 Date: Mon, 17 Feb 2003 19:45:48 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear all, We are now testing our certificate path validation program in Japan. And I have a question on the "SkipCerts" in the RFC3280. Would you please tell me? ----- According to the RFC3280, 4.2.1.12 Policy Constraints If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. ----- If there is a certificate path like the following, cert0 cert1 cert2 and if the cert1 has the requireExplicitPolicy=1, is the cert2 required to have an explicit policy or not ? (Is the value applied to the cert1 which has the requireExplicitPolicy=1?) I don't think the cert2 is required to have it, but I'm not sure. Regards, Kozo -------------------------------------------------------- Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) NEC System Technologies, Ltd. Hiroshima, Japan From owner-ietf-pkix@mail.imc.org Mon Feb 17 09:23:01 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22793 for ; Mon, 17 Feb 2003 09:23:00 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HDUpH23210 for ietf-pkix-bks; Mon, 17 Feb 2003 05:30:51 -0800 (PST) Received: from mail3.consignia.com (mail.royalmail.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HDUod23205 for ; Mon, 17 Feb 2003 05:30:50 -0800 (PST) Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 2A16B18FB17 for ; Mon, 17 Feb 2003 13:31:06 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CD0.004A4053 ; Mon, 17 Feb 2003 13:31:01 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@Royalmail.com To: ietf-pkix@imc.org Message-ID: <00256CD0.004A3E20.00@postoffice.co.uk> Date: Mon, 17 Feb 2003 13:30:35 +0000 Subject: SMIME and disclaimers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I don't imagine for a moment that we're the only ones looking at this issue. Discounting whether disclaimers carry any worthwhile legal weight, technically is it feasible to add a disclaimer to outgoing SMIME messages at the outgoing server without breaking the signature ? The multipart nature of MIME suggests that it is at least plausible to place the disclaimer in its own MIME boundary such that it doesn't interfere with signed portions in the parts of the message that originate at the client. Opinions appreciated. Chris Royal Mail is a trading name of Royal Mail Group plc. Registered in England and Wales. Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ This email and any attachments are confidential and intended for the addressee only. If you are not the named recipient, you must not use, disclose, reproduce, copy or distribute the contents of this communication. If you have received this in error, please contact the sender and then delete this email from your system. From owner-ietf-pkix@mail.imc.org Mon Feb 17 10:14:09 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23536 for ; Mon, 17 Feb 2003 10:14:08 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HERxM24692 for ietf-pkix-bks; Mon, 17 Feb 2003 06:27:59 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HERvd24688 for ; Mon, 17 Feb 2003 06:27:57 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id IAA24828 for ; Sat, 22 Feb 2003 08:11:36 +0100 Received: from authentidate.de (input.authentidate.de [192.168.42.73]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1HERk929476 for ; Mon, 17 Feb 2003 15:27:46 +0100 X-Authentication-Warning: gate.wisnet.de: Host input.authentidate.de [192.168.42.73] claimed to be authentidate.de Message-ID: <3E50F1A8.7000701@authentidate.de> Date: Mon, 17 Feb 2003 15:28:56 +0100 From: Holger Ebel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, after working through these specs and decoding many example signatures I still have the following questions regarding the meaning of the signatureAlgorithm/digestEncryptionAlgorithm in these standards mentioned above. (To be more precise, the appearance of these in the SignerInfo structure of the SignedData contentType) If this topic does not belong to this list, it would be nice if someone can point me at the responsible mailing list. Please note that I use the term signatureAlgorithm for the combination of a digest and a digestEncryption algorithm in the following mail. (To be honest, this could also be the subject of my mail: Do the successors of PKCS#7 mean "SignatureAlgorithm" alike.) ;-) With respect, I would like to summarize first how I get these standards. PKCS#7 PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm and a digestEncryptionAlgorithm. So if the signatureAlgorithm is md5WithRSAEncryption (1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5) and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1). Or if the signatureAlgorithm is sha1WithRSAEncryption (1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (1.3.14.3.2.26) and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1). (The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2) All the PKCS#7 'samples' I've found strictly follows these rules, there is a digest- and a digestEncryption algorithm. CMS CMS (RFC 2630/3369/3370) introduced the term signatureAlgorithm in the SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm of PKCS#7 while the digestAlgorithm field still remains. Here the value of the signatureAlgorithm must contain a signatureAlgoOID (sha1WithRSAEncryption, md5WithRSAEncryption, RipeMD160WithRsaEncryption or sha1WithDsaEncryption) and the digestAlgorithmValue must be equals to the one defined in the signatureAlgorithm. The only Exception is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 in conjunction with a digestAlgorithm as defined in PKCS#7 for backward compatibility. When this OID is used, it is assumed that the digestAlgo is SHA-1, but may be also MD5. (RFC 3370) The CMS samples I've found (e.g. csrc.nist.gov/pki/testing/x509paths.html, ISISMTT TestSuite) following these rules. Now my questions: (1) Did I get the standard mentioned above right regarding the signatureAlgo/digestEncryptionAlgorithm? (2) How should I handle a CMS (2630) signature where the value of the digestAlgorithm does not match the 'included' digestAlgorithm in the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo OID at the digestInfo field and a Sha1WithRSA OID in the signature- algorithm field). (3) When a component claims that it can produce valid RFC 2630 signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 the only exception from the rule? (4) Having the following signatureAlgorithms, is the usage of these for PKCS#7 and RFC 2630 signatures allowed and correct? (having valid signatures according the corresponding standard) --------------------------------------------------------------------------- SignatureAlgorithm digestAlgo (I) signatureAlgo (RFC 2630) (II) digestEncrAlgo(PKCS#7) --------------------------------------------------------------------------- (A) sha1WithRSA 1.3.14.3.2.26 (Ia) 1.2.840.113549.1.1.5 (1.2.840.113549.1.1.5) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (B) md5WithRSA 1.2.840.1x9.2.5 (Ia) 1.2.840.113549.1.1.4 (1.2.840.113549.1.1.4) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (C) ripeMD160WithRsa 1.3.36.3.2.1 (Ia) 1.3.36.3.3.1.2 (1.3.36.3.3.1.2) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (D) sha1WithDsa 1.3.14.3.2.26 (Ia) 1.2.840.10040.4.3 (1.2.840.10040.4.3) (Ib) 1.2.840.10040.4.1 (?) (II) 1.2.840.10040.4.1 --------------------------------------------------------------------------- (5) Or is the signatureAlgorithm check performed this way (for 2630): If the signatureAlgo field contains a digestEncryptionOID, the signatureAlgo is the digestEncryptionOID plus the digestOID. If the signatureAlgo field contains a signatureAlgo, the signatureAlgo equals the found signatureAlgo. The included digestAlgo is not observed/ must be the same as the one which is contained in the signatureAlgo? Thanks in advance Best Regards Holger From owner-ietf-pkix@mail.imc.org Mon Feb 17 10:48:07 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24324 for ; Mon, 17 Feb 2003 10:48:06 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HFKZa26720 for ietf-pkix-bks; Mon, 17 Feb 2003 07:20:35 -0800 (PST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HFKYd26716 for ; Mon, 17 Feb 2003 07:20:34 -0800 (PST) Received: from [192.168.0.244] ([67.118.214.168]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HAG00HYSLAAVR@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 17 Feb 2003 07:20:36 -0800 (PST) Date: Mon, 17 Feb 2003 07:20:33 -0800 From: Aram Perez Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Microsoft-Entourage/10.1.1.2418 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hallam-Baker, Phillip wrote: [snip] >> So how does something like XKMS solve this? Because it >> appears that the >> issue is not just Alice getting Bob's certificate, it's how >> does Alice get >> all the intermediate certificates (that may or may not have a >> unique email). > > XKMS does not impose a particular data model on the problem. The XKMS > service can use local knowledge of the trust topology structure to > assist finding the certification paths and can pre-calculate and cache > such paths. The directory approach forces the client to do this work > since the searches required do not conform to the restrictions of the > data model. It appears that XKMS is moving the problem from the client to the server, since how does the XKMS service learn the "trust topology structure" for a new unknown user. Regards, Aram From owner-ietf-pkix@mail.imc.org Tue Feb 18 12:25:36 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02401 for ; Tue, 18 Feb 2003 12:25:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IGaus07439 for ietf-pkix-bks; Tue, 18 Feb 2003 08:36:56 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IGatd07435 for ; Tue, 18 Feb 2003 08:36:55 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h1IGapA8009306; Tue, 18 Feb 2003 17:36:51 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <022b01c2d76a$8788cd30$0500a8c0@arport> From: "Anders Rundgren" To: "Hallam-Baker, Phillip" , "'Eric Norman'" , "PKIX list" References: Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Tue, 18 Feb 2003 17:26:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phill, >I did look into fixing SMTP to upport that mode. But SMTP is >really, really yukky, there are a lot of moving parts, lots of legacy >stuff. When I wrote my posting the other day I referred to SMTP which sure is as yucky as you say. However, MIME-encode mail which is pretty much standard, offers an "X-" extension which is similar to an X.509.v3 non-critical extension. Using MIME this should not be a problem. If you look into this mail you will find an X-OLE-something which hardly can be anything but an undocumented MS-feature. Anders From owner-ietf-pkix@mail.imc.org Tue Feb 18 13:06:41 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03475 for ; Tue, 18 Feb 2003 13:06:41 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IHZ2M09034 for ietf-pkix-bks; Tue, 18 Feb 2003 09:35:02 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IHZ0d09030 for ; Tue, 18 Feb 2003 09:35:00 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1IHYoSc065014; Tue, 18 Feb 2003 12:34:50 -0500 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1IHYlcC113754; Tue, 18 Feb 2003 12:34:47 -0500 Importance: Normal Subject: Re: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 To: Holger Ebel Cc: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Tue, 18 Feb 2003 12:34:24 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 02/18/2003 12:34:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Holger: With respect to your digestAlgorithm and digestEncryptionAlgorithm points, the use of the term "digestEncryptionAlgorithm" really applies best to RSA signatures and only to one mode of those. PKCS#1has two distinct signature schemes: the traditional one, which is the only mode defined within RFC 2313 and 2437 and is described in the new RFC 3447 as RSASSA-PKCS1-V1_5-SIGN; and the newly recommended one, which is described in RFC 3447 as RSASSA-PSS-SIGN. In the older mode, the plain text encrypted by the RSA key contains the actual algorithm ID of the hash algorithm used - see RFC 3447 section 9.2 step 2 or RFC 2437 section 9.2.1 step 2. In the newer mode, the hash algorithm used cannot be recovered so easily from the plain text - see RFC 3447 section 9.1.1 and 9.1.2. This is especially the case because the mask generation function is typically based on a hash algorithm which need not be the same as the hash algorithm used in the signature calculation, although it is recommended in RFC 3447 that they be the same. Please note that although RFC 3447 is brand new, it is essentially the same as PKCS#1 version 2.1, whichhas been actively under development since at least September 1999 (including the PSS scheme) and was finalized in June 2002. Tom Gindin Holger Ebel @mail.imc.org on 02/17/2003 09:28:56 AM Sent by: owner-ietf-pkix@mail.imc.org To: ietf-pkix@imc.org cc: Subject: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 Hello, after working through these specs and decoding many example signatures I still have the following questions regarding the meaning of the signatureAlgorithm/digestEncryptionAlgorithm in these standards mentioned above. (To be more precise, the appearance of these in the SignerInfo structure of the SignedData contentType) If this topic does not belong to this list, it would be nice if someone can point me at the responsible mailing list. Please note that I use the term signatureAlgorithm for the combination of a digest and a digestEncryption algorithm in the following mail. (To be honest, this could also be the subject of my mail: Do the successors of PKCS#7 mean "SignatureAlgorithm" alike.) ;-) With respect, I would like to summarize first how I get these standards. PKCS#7 PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm and a digestEncryptionAlgorithm. So if the signatureAlgorithm is md5WithRSAEncryption (1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5) and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1). Or if the signatureAlgorithm is sha1WithRSAEncryption (1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (1.3.14.3.2.26) and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1). (The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2) All the PKCS#7 'samples' I've found strictly follows these rules, there is a digest- and a digestEncryption algorithm. CMS CMS (RFC 2630/3369/3370) introduced the term signatureAlgorithm in the SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm of PKCS#7 while the digestAlgorithm field still remains. Here the value of the signatureAlgorithm must contain a signatureAlgoOID (sha1WithRSAEncryption, md5WithRSAEncryption, RipeMD160WithRsaEncryption or sha1WithDsaEncryption) and the digestAlgorithmValue must be equals to the one defined in the signatureAlgorithm. The only Exception is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 in conjunction with a digestAlgorithm as defined in PKCS#7 for backward compatibility. When this OID is used, it is assumed that the digestAlgo is SHA-1, but may be also MD5. (RFC 3370) The CMS samples I've found (e.g. csrc.nist.gov/pki/testing/x509paths.html, ISISMTT TestSuite) following these rules. Now my questions: (1) Did I get the standard mentioned above right regarding the signatureAlgo/digestEncryptionAlgorithm? (2) How should I handle a CMS (2630) signature where the value of the digestAlgorithm does not match the 'included' digestAlgorithm in the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo OID at the digestInfo field and a Sha1WithRSA OID in the signature- algorithm field). (3) When a component claims that it can produce valid RFC 2630 signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 the only exception from the rule? (4) Having the following signatureAlgorithms, is the usage of these for PKCS#7 and RFC 2630 signatures allowed and correct? (having valid signatures according the corresponding standard) --------------------------------------------------------------------------- SignatureAlgorithm digestAlgo (I) signatureAlgo (RFC 2630) (II) digestEncrAlgo(PKCS#7) --------------------------------------------------------------------------- (A) sha1WithRSA 1.3.14.3.2.26 (Ia) 1.2.840.113549.1.1.5 (1.2.840.113549.1.1.5) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (B) md5WithRSA 1.2.840.1x9.2.5 (Ia) 1.2.840.113549.1.1.4 (1.2.840.113549.1.1.4) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (C) ripeMD160WithRsa 1.3.36.3.2.1 (Ia) 1.3.36.3.3.1.2 (1.3.36.3.3.1.2) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (D) sha1WithDsa 1.3.14.3.2.26 (Ia) 1.2.840.10040.4.3 (1.2.840.10040.4.3) (Ib) 1.2.840.10040.4.1 (?) (II) 1.2.840.10040.4.1 --------------------------------------------------------------------------- (5) Or is the signatureAlgorithm check performed this way (for 2630): If the signatureAlgo field contains a digestEncryptionOID, the signatureAlgo is the digestEncryptionOID plus the digestOID. If the signatureAlgo field contains a signatureAlgo, the signatureAlgo equals the found signatureAlgo. The included digestAlgo is not observed/ must be the same as the one which is contained in the signatureAlgo? Thanks in advance Best Regards Holger From owner-ietf-pkix@mail.imc.org Tue Feb 18 16:25:49 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08959 for ; Tue, 18 Feb 2003 16:25:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IKwZw15486 for ietf-pkix-bks; Tue, 18 Feb 2003 12:58:35 -0800 (PST) Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IKwYd15481 for ; Tue, 18 Feb 2003 12:58:34 -0800 (PST) Received: from smtp1.pacifier.net (smtp1 [64.255.237.171]) by mx4.pacifier.net (Postfix) with ESMTP id 80C176A7D4; Tue, 18 Feb 2003 12:58:36 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 2E97F6EF22; Tue, 18 Feb 2003 12:58:35 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Manger, James H'" , Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Tue, 18 Feb 2003 12:56:29 -0800 Message-ID: <004201c2d790$36df6df0$1600a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmail.telstra.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I disagree that the problem of specifing the constraints is based on the fact that the restraints are specified in the Alg.Id field. I do agree that the constraints should be expressed differently. I think that the signature and public key parameters structures should be specified as different structures. I am not even sure that I like the fact that PSS is using DEFAULT parameters. (This has the potential to slow down moving to a larger hash algorithm since the size of the certificate is going to increase.) My preference would be to specify the necessary constraints in the parameters of the algorithm location. I disagree that there is a reason to worry about specifying a constraint that says "My software should only use alg X, but display as alg Y". This is an internal issue to the software and should not be imposed externally. jim > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H > Sent: Tuesday, February 11, 2003 10:30 PM > To: IETF-PKIX@imc.org > Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - > binding key to 1 alg > > > > Constraining the algorithms with which a key is used is good > security practice so there is sense in including a constraint > to this effect in a certificate. However, I am not sure that: > a) the subjectPublicKeyInfo field should hold this constraint and > b) the syntax for the constraint should be an Alg.Id. > > Jim Schaad's comments #8 and #13 (confusion about how to > compare the parameters of a signature or encryption with the > parameters from subjectPublicKeyInfo) are due to the > constraint being specified with an Alg.Id, which is not quite > appropriate (e.g. by including a saltLength field that is irrelevant). > > Consider other possible (& reasonable?) constraints that you > may wish to express: > > 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 > as the hash algorithm. > [Cannot be expressed as RSASSA-PSS-params only has a single > hashAlgorithm field] > > 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP > encryption, but not with any other algorithms. > [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > > 3* Only use id-sha1-with-dss-signature for signing. > [Cannot be expressed as this signature OID has NULL > parameters, but {p, q, g} need to be specified.] > > 4* Tell your signing software only to use RSASSA-PSS with > this key, but don't prevent some legacy apps from accepting > your signature. > [Cannot be expressed as legacy apps reject the cert as they > don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, > the constraint needs to be in a non-critical extension.] > > > A better solution would be to define a new extension to hold > the constraint. Mark it critical to guarantee enforcement of > the constraint, or non-critical to supply the info but > maintain some backward compatibility. > > algorithmConstraints EXTENSION ::= { > SYNTAX AlgConstraintsSyntax > IDENTIFIED By id-ce-algorithmConstraints } > > AlgConstraintsSyntax ::= ...???????... this is the hard bit > > > A simple syntax would be: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID is in the sequence. > > Or the same simple syntax with more complex semantics: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID > -- and all the OIDs of any other Alg.Ids > -- in its parameters field (inc. defaults if absent) > -- are all in the sequence > > Or something really generic: > Filter -- see X.511 > -- applied to a "virtual entry" containing just the > Alg.Id in question > > Or... > > > ---------- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Saturday, 8 February 2003 4:59 AM > Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > > ... > > ---------- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, 8 January 2003 12:30 AM > > Title : Additional Algorithms and Identifiers > for RSA Cryptography for use in the Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation List > (CRL) Profile > Author(s) : R. Housley, B. Kaliski > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > Pages : 22 > Date : 2003-1-6 > > This document supplements RFC 3279. It describes the > conventions for using the RSASSA-PSS signature algorithm, the > RSAES-OAEP key transport algorithm, and additional one-way > hash functions with the PKCS #1 version 1.5 signature > algorithm in the Internet X.509 Public Key Infrastructure > (PKI). Encoding formats, algorithm identifiers, and > parameter formats are specified. > http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt From owner-ietf-pkix@mail.imc.org Tue Feb 18 20:10:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13916 for ; Tue, 18 Feb 2003 20:09:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1J0UlE21944 for ietf-pkix-bks; Tue, 18 Feb 2003 16:30:47 -0800 (PST) Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1J0Ukd21940 for ; Tue, 18 Feb 2003 16:30:46 -0800 (PST) Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA06179 for ; Wed, 19 Feb 2003 11:30:40 +1100 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpd0s41k8; Wed Feb 19 11:30:24 2003 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA03438 for ; Wed, 19 Feb 2003 11:30:23 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdaR3cV_; Wed Feb 19 11:29:54 2003 Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA19552 for ; Wed, 19 Feb 2003 11:29:54 +1100 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Wed, 19 Feb 2003 10:29:29 +1000 Message-ID: <73388857A695D31197EF00508B08F29806EE1767@ntmsg0131.corpmail.telstra.com.au> Thread-Topic: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Thread-Index: AcLXkKu0MatTsbDaTN2xB3LELvBaTgAF1/Aw From: "Manger, James H" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1J0Ukd21941 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jim, I am not entirely clear which fields you are referring to when you say "the Alg.Id field" and "the algorithm location". I guess these refer to components within a certificate's subjectPublicKeyInfo field. > specify the necessary constraints in the parameters of the algorithm location. The subjectPublicKeyInfo.algorithm.parameters field is already needed to specify parameters for the public key: NULL for an RSA key; {p, q, g} for a DSA key; a curve for an ECDSA key; {prime, base, len} for a DH key; ... Do you really think we should change all these existing syntaxes to include constraints, instead of placing the constraints in their own field? The constraints are specific to signature or encryption algorithms -- not directly to key types. There are a number of supporting techniques (hash functions, mask generation algorithms etc) that many signature and encryption algorithms have in common. These are the sort of items that we will want to constrain. However, these supporting techniques have nothing to do with the type of key. Combining key parameters with constraints on supporting techniques does not seem that sensible. > "My software should only use alg X, but display as alg Y" Is this referring to my point 4? This is not what I was suggesting. The criticality flag in an extension allows you to choose your own balance between security & backward-compatibility. Placing constraints in the subjectPublicKeyInfo.algorithm.parameters fields does not allow this choice. > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, 19 February 2003 7:56 AM > To: Manger, James H; IETF-PKIX@imc.org > Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg > > I disagree that the problem of specifing the constraints is based on the > fact that the restraints are specified in the Alg.Id field. > > I do agree that the constraints should be expressed differently. I > think that the signature and public key parameters structures should be > specified as different structures. I am not even sure that I like the > fact that PSS is using DEFAULT parameters. (This has the potential to > slow down moving to a larger hash algorithm since the size of the > certificate is going to increase.) > > My preference would be to specify the necessary constraints in the > parameters of the algorithm location. > > I disagree that there is a reason to worry about specifying a constraint > that says "My software should only use alg X, but display as alg Y". > This is an internal issue to the software and should not be imposed > externally. > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H > > Sent: Tuesday, February 11, 2003 10:30 PM > > > > Constraining the algorithms with which a key is used is good > > security practice so there is sense in including a constraint > > to this effect in a certificate. However, I am not sure that: > > a) the subjectPublicKeyInfo field should hold this constraint and > > b) the syntax for the constraint should be an Alg.Id. > > > > Jim Schaad's comments #8 and #13 (confusion about how to > > compare the parameters of a signature or encryption with the > > parameters from subjectPublicKeyInfo) are due to the > > constraint being specified with an Alg.Id, which is not quite > > appropriate (e.g. by including a saltLength field that is irrelevant). > > > > Consider other possible (& reasonable?) constraints that you > > may wish to express: > > > > 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 > > as the hash algorithm. > > [Cannot be expressed as RSASSA-PSS-params only has a single > > hashAlgorithm field] > > > > 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP > > encryption, but not with any other algorithms.> > > [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > > > > 3* Only use id-sha1-with-dss-signature for signing. > > [Cannot be expressed as this signature OID has NULL > > parameters, but {p, q, g} need to be specified.] > > > > 4* Tell your signing software only to use RSASSA-PSS with > > this key, but don't prevent some legacy apps from accepting > > your signature. > > [Cannot be expressed as legacy apps reject the cert as they > > don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, > > the constraint needs to be in a non-critical extension.] > > > > > > A better solution would be to define a new extension to hold > > the constraint. Mark it critical to guarantee enforcement of > > the constraint, or non-critical to supply the info but > > maintain some backward compatibility. > > > > algorithmConstraints EXTENSION ::= { > > SYNTAX AlgConstraintsSyntax > > IDENTIFIED By id-ce-algorithmConstraints } > > > > AlgConstraintsSyntax ::= ...???????... this is the hard bit > > > > > > A simple syntax would be: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID is in the sequence. > > > > Or the same simple syntax with more complex semantics: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID > > -- and all the OIDs of any other Alg.Ids > > -- in its parameters field (inc. defaults if absent) > > -- are all in the sequence > > > > Or something really generic: > > Filter -- see X.511 > > -- applied to a "virtual entry" containing just the > > Alg.Id in question > > > > Or... > From incomingforward@cs.com Tue Feb 18 23:47:30 2003 Received: from russelldc1.RussellRecruitment.co.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18428 for ; Tue, 18 Feb 2003 23:47:29 -0500 (EST) From: incomingforward@cs.com Received: from smtp0201.mail.yahoo.com ([200.56.118.13]) by russelldc1.RussellRecruitment.co.uk with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Feb 2003 04:56:32 +0000 Date: Wed, 19 Feb 2003 04:57:39 GMT X-Priority: 3 To: pkirkpatrick@nhsbaltimore.com Subject: pkirkpatrick, LIVE FROM WALL STREET: VICC Test Results Are In.......... Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 19 Feb 2003 04:56:33.0421 (UTC) FILETIME=[461D93D0:01C2D7D3] Content-Transfer-Encoding: 7bit pkirkpatrick@nhsbaltimore.com

If you bought into our last recommendation (CIMG) early enough you had an excellent opportunity to make substantial gains (from .90 to 1.65 in just the first day). Now is your chance to do the same with our newest pick: VICC. To find out more go to Live From the Street.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  From incomingforward@cs.com Tue Feb 18 23:48:00 2003 Received: from russelldc1.RussellRecruitment.co.uk (russellhr.plus.com [212.159.105.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18449 for ; Tue, 18 Feb 2003 23:47:59 -0500 (EST) From: incomingforward@cs.com Received: from smtp0201.mail.yahoo.com ([200.56.118.13]) by russelldc1.RussellRecruitment.co.uk with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Feb 2003 04:56:32 +0000 Date: Wed, 19 Feb 2003 04:57:39 GMT X-Priority: 3 To: pkirkpatrick@nhsbaltimore.com Subject: pkirkpatrick, LIVE FROM WALL STREET: VICC Test Results Are In.......... Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 19 Feb 2003 04:56:33.0421 (UTC) FILETIME=[461D93D0:01C2D7D3] Content-Transfer-Encoding: 7bit pkirkpatrick@nhsbaltimore.com

If you bought into our last recommendation (CIMG) early enough you had an excellent opportunity to make substantial gains (from .90 to 1.65 in just the first day). Now is your chance to do the same with our newest pick: VICC. To find out more go to Live From the Street.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  From owner-ietf-pkix@mail.imc.org Wed Feb 19 01:59:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20473 for ; Wed, 19 Feb 2003 01:59:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1J6XoL00645 for ietf-pkix-bks; Tue, 18 Feb 2003 22:33:50 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1J6Xnd00641 for ; Tue, 18 Feb 2003 22:33:49 -0800 (PST) Received: from sesione (unknown[12.242.154.153]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <2003021906334605300qm8dme>; Wed, 19 Feb 2003 06:33:46 +0000 From: "Khaja Ahmed" To: , Subject: RE: SMIME and disclaimers Date: Tue, 18 Feb 2003 22:35:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <00256CD0.004A3E20.00@postoffice.co.uk> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit The simplest way would be to add the disclaimer in the footer of all outbound messages like the footer / signature in your own message below. Of course if you want it to be done only for signed messages it will be harder. Most likely you will need some custom MIME aware thing to create and add a MIME body part (assuming multipart)with the disclaimer text. Either of these things can be handled at the mail client or the server that relays your mail. Khaja > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of > chris.gilbert@Royalmail.com > Sent: Monday, February 17, 2003 5:31 AM > To: ietf-pkix@imc.org > Subject: SMIME and disclaimers > > > > > > All, > > I don't imagine for a moment that we're the only ones looking at > this issue. > > Discounting whether disclaimers carry any worthwhile legal > weight, technically > is it feasible to add a disclaimer to outgoing SMIME messages at > the outgoing > server without breaking the signature ? The multipart nature of > MIME suggests > that it is at least plausible to place the disclaimer in its own > MIME boundary > such that it doesn't interfere with signed portions in the parts > of the message > that originate at the client. > > Opinions appreciated. > > Chris > > Royal Mail is a trading name of Royal Mail Group plc. Registered > in England and > Wales. > Registered number 4138203. Registered office at 148 Old Street, > LONDON EC1V 9HQ > > This email and any attachments are confidential and intended > for the addressee > only. If you are not the named recipient, you must not use, > disclose, reproduce, > copy or distribute the contents of this communication. If you > have received this > in error, please contact the sender and then delete this email > from your system. > > From owner-ietf-pkix@mail.imc.org Wed Feb 19 07:41:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22559 for ; Wed, 19 Feb 2003 07:41:29 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JC8UP11636 for ietf-pkix-bks; Wed, 19 Feb 2003 04:08:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JC8Sd11632 for ; Wed, 19 Feb 2003 04:08:29 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20120; Wed, 19 Feb 2003 07:04:39 -0500 (EST) Message-Id: <200302191204.HAA20120@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldap-ac-schema-00.txt Date: Wed, 19 Feb 2003 07:04:38 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure LDAP Schema for X.509 Attribute Certificates Author(s) : D. Chadwick, M. Sahalayev Filename : draft-ietf-pkix-ldap-ac-schema-00.txt Pages : 0 Date : 2003-2-14 This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldap-ac-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-14105229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-ac-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14105229.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Thu Feb 20 00:09:34 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19512 for ; Thu, 20 Feb 2003 00:09:33 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K4V1Q20057 for ietf-pkix-bks; Wed, 19 Feb 2003 20:31:01 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K4Uxd20050 for ; Wed, 19 Feb 2003 20:30:59 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1K4Uvx8019690; Thu, 20 Feb 2003 17:30:57 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1K4Ufg18311; Thu, 20 Feb 2003 17:30:41 +1300 Date: Thu, 20 Feb 2003 17:30:41 +1300 Message-Id: <200302200430.h1K4Ufg18311@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: chris.gilbert@Royalmail.com, ietf-pkix@imc.org Subject: Re: SMIME and disclaimers Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: chris.gilbert@Royalmail.com writes: >Discounting whether disclaimers carry any worthwhile legal weight, >technically is it feasible to add a disclaimer to outgoing SMIME messages at >the outgoing server without breaking the signature ? Stick 'em in the unsigned attributes. Benefits: - Doesn't break the signature. - It's much easier for users to ignore them there than tacked onto the end of the message. Actually, another option would be: - Put them in the certPolicies. God knows there's everything else in there already, so one more piece of cruft won't hurt. Peter :-). From owner-ietf-pkix@mail.imc.org Thu Feb 20 08:28:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12763 for ; Thu, 20 Feb 2003 08:28:35 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCfsh05806 for ietf-pkix-bks; Thu, 20 Feb 2003 04:41:54 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCfrd05800 for ; Thu, 20 Feb 2003 04:41:53 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09442; Thu, 20 Feb 2003 07:38:03 -0500 (EST) Message-Id: <200302201238.HAA09442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-tap-00.txt Date: Thu, 20 Feb 2003 07:38:03 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Trusted Archive Protocol (TAP) Author(s) : C. Wallace, S. Chokhani Filename : draft-ietf-pkix-tap-00.txt Pages : 34 Date : 2003-2-19 A Trusted Archive Authority (TAA) is a service that supports long- term non-repudiation by maintaining secure storage of cryptographically refreshed information. This document defines a set of transactions for interacting with a Trusted Archive Authority (TAA) and establishes a means of representing archived information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-tap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-tap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19142304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-tap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-tap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142304.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Thu Feb 20 11:31:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20261 for ; Thu, 20 Feb 2003 11:31:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KFvPE17855 for ietf-pkix-bks; Thu, 20 Feb 2003 07:57:25 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KFvNd17851 for ; Thu, 20 Feb 2003 07:57:24 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26772; Thu, 20 Feb 2003 16:59:40 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA15065; Thu, 20 Feb 2003 15:51:39 +0100 Message-ID: <3E54FA48.20203@bull.net> Date: Thu, 20 Feb 2003 16:54:48 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: David Chadwick CC: pkix Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-ac-schema-00.txt References: <200302191204.HAA20120@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David, Would it be possible that you re-issue this draft according to the requirements for the presentation of an RFC, i.e. 72 characters per line, 58 lines per page, a page numbering and no "tab" characters ? Thank you. Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Internet X.509 Public Key Infrastructure LDAP Schema > for X.509 Attribute Certificates > Author(s) : D. Chadwick, M. Sahalayev > Filename : draft-ietf-pkix-ldap-ac-schema-00.txt > Pages : 0 > Date : 2003-2-14 > > This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pkix-ldap-ac-schema-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From owner-ietf-pkix@mail.imc.org Thu Feb 20 13:33:38 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24497 for ; Thu, 20 Feb 2003 13:33:37 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KHpK923304 for ietf-pkix-bks; Thu, 20 Feb 2003 09:51:20 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KHpId23299 for ; Thu, 20 Feb 2003 09:51:18 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1KHp9Es090718; Thu, 20 Feb 2003 12:51:09 -0500 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1KHp4DK098566; Thu, 20 Feb 2003 12:51:05 -0500 Importance: Normal Subject: Re: SMIME and disclaimers To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: chris.gilbert@Royalmail.com, ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Thu, 20 Feb 2003 12:50:47 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 02/20/2003 12:51:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: Leaving a disclaimer outside the signature base removes most of the point of having one. It needs to be in the footer or in a signed attribute. Having it in the certificate is fine if you always want the disclaimer - see the many NR discussions on this list, as you know. Tom Gindin I/T Architect - Security IBM Business Consulting Services - Public Sector Phone (301) 803-3460 pgut001@cs.auckland.ac.nz (Peter Gutmann)@mail.imc.org on 02/19/2003 11:30:41 PM Sent by: owner-ietf-pkix@mail.imc.org To: chris.gilbert@Royalmail.com, ietf-pkix@imc.org cc: Subject: Re: SMIME and disclaimers chris.gilbert@Royalmail.com writes: >Discounting whether disclaimers carry any worthwhile legal weight, >technically is it feasible to add a disclaimer to outgoing SMIME messages at >the outgoing server without breaking the signature ? Stick 'em in the unsigned attributes. Benefits: - Doesn't break the signature. - It's much easier for users to ignore them there than tacked onto the end of the message. Actually, another option would be: - Put them in the certPolicies. God knows there's everything else in there already, so one more piece of cruft won't hurt. Peter :-). From owner-ietf-pkix@mail.imc.org Thu Feb 20 16:35:37 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00523 for ; Thu, 20 Feb 2003 16:35:36 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKvxX05162 for ietf-pkix-bks; Thu, 20 Feb 2003 12:57:59 -0800 (PST) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKvtd05158 for ; Thu, 20 Feb 2003 12:57:56 -0800 (PST) Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h1KKujf2012773; Thu, 20 Feb 2003 15:56:45 -0500 (EST) Message-Id: <5.1.0.14.2.20030220144712.0210d4c0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 14:57:14 -0500 To: ietf-pkix@imc.org From: Tim Polk Subject: DPD/DPV Protocol Selection Cc: kent@bbn.com, Denis Pinkas , Peter Sylvester , Russ Housley , Ambarish Malpani , Michael Myers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, After some delay, it is finally time to settle on a single PKIX WG protocol for DPD/DPV. Steve and I have been mulling over the results from the strawpoll, as well as the technical content of the messages posted to the list. As you all are aware, we have been adamant that the WG advance only one protocol for DPD/DPV. However, that is not the only important factor. We are also adamant that (1) the protocol must have adequate support among implementers, (2) the protocol MUST satisfy the requirements specified in RFC 3379, and (3) the protocol be mature enough for completion soon. As the co-chairs, we needed to satisfy ourselves that the process was not a beauty contest, and had chosen a technically sound engineering solution. After much consideration, Steve and I are satisfied that SCVP is the best choice as the PKIX WG protocol for DPD/DPV. Let me outline the rationale: (1) The protocol must have adequate support among implementers. The strawpoll voting results were: SCVP 26; OCSP 15; DVCS 8; and CVP 2 out of 51 total votes. These numbers include a vote from Denis for CVP, even though he never officially submitted one, but exclude XKMS and ABSTAIN votes. The numbers are clear if not overwhelming. SCVP garnered just a bit more than 50% of the votes. OCSP got just under 30%. DVCS got almost 16% and CVP 4%. Based on the strawpoll, SCVP has the most support from respondents. OCSP also has relatively strong support. DVCS and CVP fall short in this category. (2) The protocol MUST satisfy the requirements specified in RFC 3379. It is my opinion that each of the four protocols *could* satisfy the requirements, given sufficient time. The question before us, though, is how close are the current proposals. Based on the respective compliance matrices, and the subsequent analysis performed by Denis, none of the current submissions is perfect. However, the compliance matrices imply that SCVP is closer to satisfying the requirements than either OCSP or DVCS. While no one performed that same analysis for Denis' matrix, I believe that CVP's compliance is roughly that of SCVP, since it was designed using 3379. So, SCVP and CVP seem closest to the requirements at this time. (3) The protocol be mature enough for completion soon. OCSP and DVCS have been RFCs for some time, so their base protocols are clearly mature. However, the extensions that are needed to support DPD/DPV are significantly less mature. Moreover, the changes needed by clients and servers to make use of these extensions to OCSP are substantial, vastly greater in complexity that the current OCSP protocol. Thus the installed OCSP client & server base for OCSP does not represent a significant head start for this protocol vs. the others. CVP is a very recent development, having cycled at Internet-Draft just a few times. SCVP is not an RFC, but is currently at draft 11, we have implementation experience, and it has been tweaked and polished throughout the requirements process. In short, SCVP appears best positioned for swift completion. Based on this analysis, we are affirming the results of the strawpoll, and SCVP is *the* PKIX WG protocol for DPD/DPV. I want to encourage everyone to stay involved, even if your favorite protocol was not SCVP. We are in the home stretch, but there is still work to do. Here is the way forward, in our view. Denis' analysis of the SCVP compliance matrix raises an initial set of questions. These issues need to be discussed on the list, and if the WG agrees that changes to SCVP are required, modifications will be proposed (by the editors, or WG membership). Once rough consensus is achieved on those issues, the editors can submit a new draft. At that point, we intend to initiate WG Last Call. Any final issues can be hammered out, then the document forwarded to the ADs. Steve and I want to thank everyone for their participation. First, the editors should be applauded for their efforts in developing the compliance matrices. We know that was a difficult and time-consuming task. Denis' analysis of the SCVP, OCSP, and DVCS compliance matrices was a very significant contribution. Those that reviewed, commented, and voted in the strawpoll put in significant efforts as well. Finally, we need to recognize Denis and Russ for completing RFC 3379, which made it possible to complete the selection process. Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Thu Feb 20 19:10:40 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04244 for ; Thu, 20 Feb 2003 19:10:40 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KNgnj08803 for ietf-pkix-bks; Thu, 20 Feb 2003 15:42:49 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1KNgmd08799 for ; Thu, 20 Feb 2003 15:42:48 -0800 (PST) Received: (qmail 17482 invoked from network); 20 Feb 2003 23:42:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (131.107.52.146) by woodstock.binhost.com with SMTP; 20 Feb 2003 23:42:40 -0000 Message-Id: <5.2.0.9.2.20030220184116.038b7720@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 18:42:06 -0500 To: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org From: Russ Housley Subject: Re: SkipCerts Question [RFC3280] In-Reply-To: <20030217194548k-fujino@smtp.necst.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kozo: You understand correctly -- cert2 is not required to have an explicit policy. Russ At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: >Dear all, > >We are now testing our certificate path validation >program in Japan. >And I have a question on the "SkipCerts" in the RFC3280. > >Would you please tell me? > >----- >According to the RFC3280, > >4.2.1.12 Policy Constraints > > > >If the requireExplicitPolicy field is present, the value of >requireExplicitPolicy indicates the number of additional certificates >that may appear in the path before an explicit policy is required for >the entire path. >----- > >If there is a certificate path like the following, > cert0 > cert1 > cert2 > >and if the cert1 has the requireExplicitPolicy=1, > >is the cert2 required to have an explicit policy or not ? > >(Is the value applied to the cert1 > which has the requireExplicitPolicy=1?) > >I don't think the cert2 is required to have it, >but I'm not sure. > >Regards, > Kozo >-------------------------------------------------------- >Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >NEC System Technologies, Ltd. >Hiroshima, Japan From owner-ietf-pkix@mail.imc.org Fri Feb 21 05:34:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25385 for ; Fri, 21 Feb 2003 05:34:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1L9ugt17028 for ietf-pkix-bks; Fri, 21 Feb 2003 01:56:42 -0800 (PST) Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1L9ufd17023 for ; Fri, 21 Feb 2003 01:56:41 -0800 (PST) Received: from 203.94.239.165 (localhost [127.0.0.1]) by host13.websitesource.com (8.10.2/8.10.2) with ESMTP id h1L9uYI15947; Fri, 21 Feb 2003 04:56:34 -0500 To: n Russ Housley From: Santosh Chokhani Subject: Re: SkipCerts Question [RFC3280] Reply-To: chokhani@orionsec.com CC: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Date: Fri, 21 Feb 2003 04:47:00 -0500 X-Sender: chokhani@orionsec.com X-Originating-Host: 203.94.239.165 [203.94.239.165]; Fri, 21 Feb 2003 09:56:34 GMT X-Mailer: WebMail Check v2.3.21 (2000-7-19) X-Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; AT&T CSM6.0), JavaScript: On Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > From owner-ietf-pkix@mail.imc.org Fri Feb 21 12:29:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07877 for ; Fri, 21 Feb 2003 12:29:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LGuvt11191 for ietf-pkix-bks; Fri, 21 Feb 2003 08:56:57 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [204.167.114.129] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h1LGutd11187 for ; Fri, 21 Feb 2003 08:56:56 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Feb 2003 16:56:57 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA04864; Fri, 21 Feb 2003 11:56:48 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <1WBW62BK>; Fri, 21 Feb 2003 11:56:44 -0500 Message-ID: From: "Kaliski, Burt" To: "'jimsch@exmsft.com'" , "'Russ Housley'" Cc: IETF-PKIX@imc.org Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Date: Fri, 21 Feb 2003 11:56:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Jim, Sorry for my slow response to your comments. My replies are embedded below. I'm not fully committed to the approach of encoding algorithm usage restrictions into the "public key type", and am open to other suggestions. Your message illustrates the challenges with this approach. -- Burt -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, February 07, 2003 12:59 PM To: 'Russ Housley'; Kaliski, Burt Cc: IETF-PKIX@imc.org Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Gentlemen, 1. Can you make the title of the document another line longer? [BK] We'll try :-) 2. Please consider adding the following textto section 1.2 p 3. "Note: It is not possible to restict the use of a key either RSASSA-PSS and anything else. The same is true of RSAES-OAEP." [BK] Agreed. 3. In section 1.2 p 2 last sentence. I think it should be "signature and/or key transport". [BK] Our intent was that a key would be used only for one or other other, hence "or" not "and/or". 4. In section 2.1, there is a par of paragraphs about the use of NULL or ABSENT in encoding the hash functions. There appears to be a conflict between the two paragraphs. The first says use ABSENT. The second says use NULL. One or the other should be omitted, I would perfer the second as the first is the "standard" way of doing things. The second would require changes in my encoder/decoder utility functions. [BK] Both are allowed, due to confusion in implementations. The parameters should be absent, but if present must be NULL. The new RFC version of PKCS #1 v2.1 includes text on this, ftp://ftp.rfc-editor.org/in-notes/rfc3447.txt. 5. Section 3, para 1, last sentence: It appears to me that there should potentially be two different statements on conforming CAs. Some CAs will using RSASSA-PSS as the signing algorithm, while other will just encode a certificate with the RSASSA-PSS public key. Should these be seperated in conformant statements? [BK] Agreed, the conformance may be different for signing with RSASSA-PSS, vs. including public keys restricted to RSASSA-PSS. 6. Section 3.1 maskGenAlgorithm. Please remove the statement "It MUST be an algorithm identifier". This is a tautology. [BK] OK. 7. Section 3.2. I would like to see a different OID used for a signature value from that used to encode the public key. This makes it easier to process for encode/decode as there are not two structures with the same OID. [BK] The OID is not used to encode the public key directly, but to encode an AlgorithmID; the AlgorithmID is used to describe the public key. So, the AlgorithmID has two meanings, one for the signature, one for the public key. I agree this is potential problem, and am open to alternatives. 8. RSASSA-PSS-params and signature processing. I am confused about what should be done by a signature verifier/producer in checking the parameters of a signature againist the parameters of a signature. My first assumption was that all of the fields mattered and should be "equivalent". From reading the text I find that this is not the case and the saltLength is encoded in the certificate parameters but is wildcarded against the signature parameters. This type of behavior makes implementation difficult. My first assumption on this implemenation was a binary comparison. This would not work for a number of reasons the first being saltLength, the second being the requirements that I need to be able to match a defaulted parameter against an existing parameter (i.e. sha1Identifier present vs absent). [BK] I see the challenge. 9. Section 3.1 maskGenAlgorithm. The text at the end of the paragraph is missing some cases that would seem to be logical. The following should be matched: ABSENT {id-mgf1} {id-mgf1, {id-sha1}} {id-mgf1, {id-sha1, NULL}} It would be MUCH simplier if the "stupid" cases could be removed, but I don't know if that would match your worldview. [BK] The second case can be removed since MGF1 must have a parameter (no confusion on that). The others are needed, the first one for the default case, the third and fourth in case of confusion about SHA1's parameters (though MGF1 is explicit that it expects the SHA1 to have parameters). 10. Section 3.1 saltLength. There seems to be a mis-match between the default value in the ASN.1 structure and that in the text. The structure definition says 20. The description says the length of the hash output value. This implies that if I were to use md5 as in the hashAlgorithm field, the default value of the ASN.1 structure for saltLength would suddenly be 16 not 20. [BK] Yes, this is a problem, already propagated in PKCS #1 v2.1. Better not to have defaults ... what's your preference on fixing things? 11. Section 4.1, para 1 - missing id- from RSAES-OAEP in the first sentence. [BK] OK. 12. Section 4.1, maskGenFunc - see comment 9. [BK] See above. 13. Section 4.1, RSAES-OAEP-params comparison function. This comparison has some of the same problems as that of RSASSA-PSS. I don't know the proper way to compare pSourceFunc. I believe that the comparison here is dependent on the value of pSourceFunc.Algorithm. For a value of id-pSpecified, this field should be ignored. Are there other values (such as if nullOctetString is not of 0 length based on para 6 of the security considerations section). [BK] In general, this field is unused. But I can see cases where it might be used several different ways with a given public key, which means that a direct comparison might not be ideal. 14. Section 5. Please change "the parameters MUST be NULL" to "the parameters MUST be ABSENT". This matches SHA-1 convention. [BK] See answer to comment 4. The parameters SHOULD be absent but MAY be NULL, and receivers MUST accept either. 15. ASN.1 Module: Organization: It helps if the parameters structure is in the same section as the OID that uses the structure. Looking from the top to the very bottom for the parameters is messy. [BK] Agreed, will improve this. 16. ASN.1 Module: All of the rSASSA-PSS-*-Identifier structures need to be changed to rSASSA-PSS-*-Identifier AlgorithmIdentifier ::= { id-RSASSA-PSS, rSASSA-PSS-*-params } rSASSA-PSS-*-params RSASSA-PSS-params ::= { *-hash, mgf1*Identifier, 20, 1} The second level of initialization cannot be done in 1988 because the structure is an ANY. [BK] OK. 17. Section 7.1 [P1v2.1] Remove the first J. and the first comma. [BK] OK. Jim From owner-ietf-pkix@mail.imc.org Fri Feb 21 17:06:32 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16676 for ; Fri, 21 Feb 2003 17:06:32 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLhA626355 for ietf-pkix-bks; Fri, 21 Feb 2003 13:43:10 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1LLh9d26351 for ; Fri, 21 Feb 2003 13:43:09 -0800 (PST) Received: (qmail 8648 invoked from network); 21 Feb 2003 21:42:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.160.75) by woodstock.binhost.com with SMTP; 21 Feb 2003 21:42:59 -0000 Message-Id: <5.2.0.9.2.20030221120326.00bc8dc0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Feb 2003 12:14:34 -0500 To: "Manger, James H" From: Russ Housley Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Cc: BKaliski@rsasecurity.com, IETF-PKIX@imc.org In-Reply-To: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmai l.telstra.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: James: Let be give you some background. PKCS#1 v2.1 includes a recommendation that RSA private key only be used with one scheme (such as PSS, OAEP, PKCS#1 v1.5 Signature, PKCS#1 v1.5 key transport, ...). Further, in the case of OAEP, PKCS#1 v2.1 recommends that an RSA private key make use only one mask generation function. The key usage extension can be used to distinguish RSA signature verification keys and RSA key transport keys. But it does not meet the above requirements. So, how can the private key owner's intentions be conveyed to another party? The use of subject public key info seems natural to me. This algorithm identifier is intended to convey to the certificate user information about the public key algorithm. I am opposed to a new certificate extension for algorithm constraints. In RFC 3279, there is a list of public key algorithms. For each algorithm, it specifies the OID to be carried in subject public key info and the format of the public key itself. If the algorithm is a signature algorithm, then there are additional OIDs that imply the use of particular one-way hash functions and the format of the signature value. Perhaps the explosion of OIDs for signature algorithm plus one-way hash function could have been avoided by using a parameter with an OID identifying the one-way hash function, but historically this was not done. People have code that handles this situation in a straightforward manner. While I do not mind exploring other alternatives, I do not think that we should deviate for the historical convention unless there are real unmet needs. In my opinion, the current convention is meeting all of the needs of today's certificate using applications. Russ At 04:29 PM 2/12/2003 +1000, Manger, James H wrote: >Constraining the algorithms with which a key is used is good security >practice so there is sense in including a constraint to this effect in a >certificate. However, I am not sure that: >a) the subjectPublicKeyInfo field should hold this constraint and >b) the syntax for the constraint should be an Alg.Id. > >Jim Schaad's comments #8 and #13 (confusion about how to compare the >parameters of a signature or encryption with the parameters from >subjectPublicKeyInfo) are due to the constraint being specified with an >Alg.Id, which is not quite appropriate (e.g. by including a saltLength >field that is irrelevant). > >Consider other possible (& reasonable?) constraints that you may wish to >express: > >1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 as the hash >algorithm. >[Cannot be expressed as RSASSA-PSS-params only has a single hashAlgorithm >field] > >2* Use this key for RSASSA-PSS signatures or RSAES-OAEP encryption, but >not with any other algorithms. >[Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > >3* Only use id-sha1-with-dss-signature for signing. >[Cannot be expressed as this signature OID has NULL parameters, but {p, q, >g} need to be specified.] > >4* Tell your signing software only to use RSASSA-PSS with this key, but >don't prevent some legacy apps from accepting your signature. >[Cannot be expressed as legacy apps reject the cert as they don't accept >id-RSASSA-PSS in subjectPublicKeyInfo. To work, the constraint needs to >be in a non-critical extension.] > > >A better solution would be to define a new extension to hold the >constraint. Mark it critical to guarantee enforcement of the constraint, >or non-critical to supply the info but maintain some backward compatibility. > >algorithmConstraints EXTENSION ::= { > SYNTAX AlgConstraintsSyntax > IDENTIFIED By id-ce-algorithmConstraints } > >AlgConstraintsSyntax ::= ...???????... this is the hard bit > > >A simple syntax would be: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID is in the sequence. > >Or the same simple syntax with more complex semantics: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID > -- and all the OIDs of any other Alg.Ids > -- in its parameters field (inc. defaults if absent) > -- are all in the sequence > >Or something really generic: > Filter -- see X.511 > -- applied to a "virtual entry" containing just the Alg.Id in > question > >Or... > > >---------- >From: Jim Schaad [mailto:jimsch@nwlink.com] >Sent: Saturday, 8 February 2003 4:59 AM >Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > >... > >---------- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Wednesday, 8 January 2003 12:30 AM > > Title : Additional Algorithms and Identifiers for RSA > Cryptography for use in the Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile > Author(s) : R. Housley, B. Kaliski > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > Pages : 22 > Date : 2003-1-6 > >This document supplements RFC 3279. It describes the conventions for >using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport >algorithm, and additional one-way hash functions with the PKCS #1 version >1.5 signature algorithm in the Internet X.509 Public Key Infrastructure >(PKI). Encoding formats, algorithm identifiers, and parameter formats are >specified. > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt From owner-ietf-pkix@mail.imc.org Fri Feb 21 17:06:35 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16690 for ; Fri, 21 Feb 2003 17:06:34 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLiU426393 for ietf-pkix-bks; Fri, 21 Feb 2003 13:44:30 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1LLiTd26389 for ; Fri, 21 Feb 2003 13:44:29 -0800 (PST) Received: (qmail 8783 invoked from network); 21 Feb 2003 21:44:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.160.75) by woodstock.binhost.com with SMTP; 21 Feb 2003 21:44:19 -0000 Message-Id: <5.2.0.9.2.20030221123939.00bb8188@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Feb 2003 12:44:09 -0500 To: From: Russ Housley Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Cc: IETF-PKIX@imc.org, BKaliski@rsasecurity.com In-Reply-To: <004201c2d790$36df6df0$1600a8c0@soaringhawk.net> References: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmail.telstra.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: You and I are closer to agreement than I realized. That is a good sign. I do not want to have more than one parameter syntax associated with a single OID. I do not want the RSAES-OAEP OID to have one parameter syntax when it is used in subject public key info and another parameter syntax when it is used in EnvelopedData. In my opinion, each OID should only have a single parameter syntax, otherwise the automatic parsing of the parameters filed will become context sensitive. Russ At 12:56 PM 2/18/2003 -0800, Jim Schaad wrote: >I disagree that the problem of specifing the constraints is based on the >fact that the restraints are specified in the Alg.Id field. > >I do agree that the constraints should be expressed differently. I >think that the signature and public key parameters structures should be >specified as different structures. I am not even sure that I like the >fact that PSS is using DEFAULT parameters. (This has the potential to >slow down moving to a larger hash algorithm since the size of the >certificate is going to increase.) > >My preference would be to specify the necessary constraints in the >parameters of the algorithm location. > >I disagree that there is a reason to worry about specifying a constraint >that says "My software should only use alg X, but display as alg Y". >This is an internal issue to the software and should not be imposed >externally. > >jim > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H > > Sent: Tuesday, February 11, 2003 10:30 PM > > To: IETF-PKIX@imc.org > > Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - > > binding key to 1 alg > > > > > > > > Constraining the algorithms with which a key is used is good > > security practice so there is sense in including a constraint > > to this effect in a certificate. However, I am not sure that: > > a) the subjectPublicKeyInfo field should hold this constraint and > > b) the syntax for the constraint should be an Alg.Id. > > > > Jim Schaad's comments #8 and #13 (confusion about how to > > compare the parameters of a signature or encryption with the > > parameters from subjectPublicKeyInfo) are due to the > > constraint being specified with an Alg.Id, which is not quite > > appropriate (e.g. by including a saltLength field that is irrelevant). > > > > Consider other possible (& reasonable?) constraints that you > > may wish to express: > > > > 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 > > as the hash algorithm. > > [Cannot be expressed as RSASSA-PSS-params only has a single > > hashAlgorithm field] > > > > 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP > > encryption, but not with any other algorithms. > > [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > > > > 3* Only use id-sha1-with-dss-signature for signing. > > [Cannot be expressed as this signature OID has NULL > > parameters, but {p, q, g} need to be specified.] > > > > 4* Tell your signing software only to use RSASSA-PSS with > > this key, but don't prevent some legacy apps from accepting > > your signature. > > [Cannot be expressed as legacy apps reject the cert as they > > don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, > > the constraint needs to be in a non-critical extension.] > > > > > > A better solution would be to define a new extension to hold > > the constraint. Mark it critical to guarantee enforcement of > > the constraint, or non-critical to supply the info but > > maintain some backward compatibility. > > > > algorithmConstraints EXTENSION ::= { > > SYNTAX AlgConstraintsSyntax > > IDENTIFIED By id-ce-algorithmConstraints } > > > > AlgConstraintsSyntax ::= ...???????... this is the hard bit > > > > > > A simple syntax would be: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID is in the sequence. > > > > Or the same simple syntax with more complex semantics: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID > > -- and all the OIDs of any other Alg.Ids > > -- in its parameters field (inc. defaults if absent) > > -- are all in the sequence > > > > Or something really generic: > > Filter -- see X.511 > > -- applied to a "virtual entry" containing just the > > Alg.Id in question > > > > Or... > > > > > > ---------- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Saturday, 8 February 2003 4:59 AM > > Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > > > > ... > > > > ---------- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, 8 January 2003 12:30 AM > > > > Title : Additional Algorithms and Identifiers > > for RSA Cryptography for use in the Internet X.509 Public Key > > Infrastructure Certificate and Certificate Revocation List > > (CRL) Profile > > Author(s) : R. Housley, B. Kaliski > > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > > Pages : 22 > > Date : 2003-1-6 > > > > This document supplements RFC 3279. It describes the > > conventions for using the RSASSA-PSS signature algorithm, the > > RSAES-OAEP key transport algorithm, and additional one-way > > hash functions with the PKCS #1 version 1.5 signature > > algorithm in the Internet X.509 Public Key Infrastructure > > (PKI). Encoding formats, algorithm identifiers, and > > parameter formats are specified. > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt From owner-ietf-pkix@mail.imc.org Sat Feb 22 09:06:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10984 for ; Sat, 22 Feb 2003 09:06:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1MDGsl09241 for ietf-pkix-bks; Sat, 22 Feb 2003 05:16:54 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1MDGqd09237 for ; Sat, 22 Feb 2003 05:16:52 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1MDGix7057636; Sat, 22 Feb 2003 08:16:44 -0500 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1MDGf2B124252; Sat, 22 Feb 2003 08:16:42 -0500 Importance: Normal Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg To: Russ Housley , BKaliski@rsasecurity.com Cc: "Manger, James H" , IETF-PKIX@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Sat, 22 Feb 2003 08:14:53 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 02/22/2003 08:16:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Burt: Is the statement in section 6 of RFC 3447 (PKCS #2 2.1) really intended to suggest that TLS/SSL servers and S/MIME clients should not be implemented with single RSA key pairs which use RSA-PSS for signatures and also use RSA-OAEP for key encipherment? It seems to cover that case, although the examples given suggest that using two distinct signature-capable schemes is undesirable, as is using two distinct encryption-capable schemes, and so it is wrong to use PKCS1-V1_5 with either of the newer schemes. Tom Gindin Russ Housley @mail.imc.org on 02/21/2003 12:14:34 PM Sent by: owner-ietf-pkix@mail.imc.org To: "Manger, James H" cc: BKaliski@rsasecurity.com, IETF-PKIX@imc.org Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg James: Let be give you some background. PKCS#1 v2.1 includes a recommendation that RSA private key only be used with one scheme (such as PSS, OAEP, PKCS#1 v1.5 Signature, PKCS#1 v1.5 key transport, ...). Further, in the case of OAEP, PKCS#1 v2.1 recommends that an RSA private key make use only one mask generation function. The key usage extension can be used to distinguish RSA signature verification keys and RSA key transport keys. But it does not meet the above requirements. So, how can the private key owner's intentions be conveyed to another party? The use of subject public key info seems natural to me. This algorithm identifier is intended to convey to the certificate user information about the public key algorithm. I am opposed to a new certificate extension for algorithm constraints. In RFC 3279, there is a list of public key algorithms. For each algorithm, it specifies the OID to be carried in subject public key info and the format of the public key itself. If the algorithm is a signature algorithm, then there are additional OIDs that imply the use of particular one-way hash functions and the format of the signature value. Perhaps the explosion of OIDs for signature algorithm plus one-way hash function could have been avoided by using a parameter with an OID identifying the one-way hash function, but historically this was not done. People have code that handles this situation in a straightforward manner. While I do not mind exploring other alternatives, I do not think that we should deviate for the historical convention unless there are real unmet needs. In my opinion, the current convention is meeting all of the needs of today's certificate using applications. Russ At 04:29 PM 2/12/2003 +1000, Manger, James H wrote: >Constraining the algorithms with which a key is used is good security >practice so there is sense in including a constraint to this effect in a >certificate. However, I am not sure that: >a) the subjectPublicKeyInfo field should hold this constraint and >b) the syntax for the constraint should be an Alg.Id. > >Jim Schaad's comments #8 and #13 (confusion about how to compare the >parameters of a signature or encryption with the parameters from >subjectPublicKeyInfo) are due to the constraint being specified with an >Alg.Id, which is not quite appropriate (e.g. by including a saltLength >field that is irrelevant). > >Consider other possible (& reasonable?) constraints that you may wish to >express: > >1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 as the hash >algorithm. >[Cannot be expressed as RSASSA-PSS-params only has a single hashAlgorithm >field] > >2* Use this key for RSASSA-PSS signatures or RSAES-OAEP encryption, but >not with any other algorithms. >[Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > >3* Only use id-sha1-with-dss-signature for signing. >[Cannot be expressed as this signature OID has NULL parameters, but {p, q, >g} need to be specified.] > >4* Tell your signing software only to use RSASSA-PSS with this key, but >don't prevent some legacy apps from accepting your signature. >[Cannot be expressed as legacy apps reject the cert as they don't accept >id-RSASSA-PSS in subjectPublicKeyInfo. To work, the constraint needs to >be in a non-critical extension.] > > >A better solution would be to define a new extension to hold the >constraint. Mark it critical to guarantee enforcement of the constraint, >or non-critical to supply the info but maintain some backward compatibility. > >algorithmConstraints EXTENSION ::= { > SYNTAX AlgConstraintsSyntax > IDENTIFIED By id-ce-algorithmConstraints } > >AlgConstraintsSyntax ::= ...???????... this is the hard bit > > >A simple syntax would be: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID is in the sequence. > >Or the same simple syntax with more complex semantics: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID > -- and all the OIDs of any other Alg.Ids > -- in its parameters field (inc. defaults if absent) > -- are all in the sequence > >Or something really generic: > Filter -- see X.511 > -- applied to a "virtual entry" containing just the Alg.Id in > question > >Or... > > >---------- >From: Jim Schaad [mailto:jimsch@nwlink.com] >Sent: Saturday, 8 February 2003 4:59 AM >Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > >... > >---------- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Wednesday, 8 January 2003 12:30 AM > > Title : Additional Algorithms and Identifiers for RSA > Cryptography for use in the Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile > Author(s) : R. Housley, B. Kaliski > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > Pages : 22 > Date : 2003-1-6 > >This document supplements RFC 3279. It describes the conventions for >using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport >algorithm, and additional one-way hash functions with the PKCS #1 version >1.5 signature algorithm in the Internet X.509 Public Key Infrastructure >(PKI). Encoding formats, algorithm identifiers, and parameter formats are >specified. > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt From owner-ietf-pkix@mail.imc.org Sun Feb 23 19:48:03 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16118 for ; Sun, 23 Feb 2003 19:48:02 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1O0HuM11201 for ietf-pkix-bks; Sun, 23 Feb 2003 16:17:56 -0800 (PST) Received: from center.kisa.or.kr ([211.252.150.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1O0Hnd11195 for ; Sun, 23 Feb 2003 16:17:49 -0800 (PST) Received: from LocalHost (localhost [127.0.0.1]) by center.kisa.or.kr (8.11.6+Sun/8.11.1) with ESMTP id h1O0F7L27292 for ; Mon, 24 Feb 2003 09:15:07 +0900 (KST) From: "InKyoung Jeun" To: Subject: FW: SkipCerts Question [RFC3280] Date: Mon, 24 Feb 2003 09:17:49 +0900 Message-ID: <001201c2db9a$2a3ecb00$b40310ac@LocalHost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit -----Original Message----- From: InKyoung Jeun [mailto:ikjeun@kisa.or.kr] Sent: Friday, February 21, 2003 1:22 PM To: 'Russ Housley'; 'k-fujino@pb.jp.nec.com'; 'ietf-pkix@imc.org' Subject: RE: SkipCerts Question [RFC3280] Russ : I think cert2 is required to have an explicit policy. In the RFC3280 Basic Path validation, if i is equal to n, perform the wrap-up steps. Cert2 is n=i=2, so we must perform the wrap-up steps. During wrap-up steps, state variable explicit_Policy is set to 0. Because if cert2 is not self-issed and explicit policy is 1. Let's look at the result. If cert2 has not an explicit policy, valid_policy_tree in NULL and explicit_policy is 0. And the path processing has failed. So cert2 is required to have an explicit policy. Kyoung. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Friday, February 21, 2003 8:42 AM To: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo: You understand correctly -- cert2 is not required to have an explicit policy. Russ At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: >Dear all, > >We are now testing our certificate path validation >program in Japan. >And I have a question on the "SkipCerts" in the RFC3280. > >Would you please tell me? > >----- >According to the RFC3280, > >4.2.1.12 Policy Constraints > > > >If the requireExplicitPolicy field is present, the value of >requireExplicitPolicy indicates the number of additional certificates >that may appear in the path before an explicit policy is required for >the entire path. >----- > >If there is a certificate path like the following, > cert0 > cert1 > cert2 > >and if the cert1 has the requireExplicitPolicy=1, > >is the cert2 required to have an explicit policy or not ? > >(Is the value applied to the cert1 > which has the requireExplicitPolicy=1?) > >I don't think the cert2 is required to have it, >but I'm not sure. > >Regards, > Kozo >-------------------------------------------------------- >Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >NEC System Technologies, Ltd. >Hiroshima, Japan From owner-ietf-pkix@mail.imc.org Mon Feb 24 18:03:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29582 for ; Mon, 24 Feb 2003 18:03:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OMZtm03167 for ietf-pkix-bks; Mon, 24 Feb 2003 14:35:55 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OMZsd03163 for ; Mon, 24 Feb 2003 14:35:54 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v1.5 Enhanced SNACC Freeware Now Available Date: Mon, 24 Feb 2003 17:35:56 -0500 Message-ID: Thread-Topic: v1.5 Enhanced SNACC Freeware Now Available Thread-Index: AcI5cp6Z14OJyzHGQ8i472hAAgjQnA== From: "Pawling, John" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1OMZtd03164 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, DigitalNet (formerly Getronics Government Solutions) has delivered the v1.5 eSNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) Windows NT/98/2000/XP. The eSNACC software is freely available to everyone from: The eSNACC ASN.1 software can be used to ASN.1 encode and decode objects. In past releases, DigitalNet improved the eSNACC C++ library to implement the Distinguished Encoding Rules (DER), support large ASN.1 INTEGERs, and improve memory usage. v1.5 eSNACC enhancements (compared to v1.4 release): 1) Updated compiler to automatically read in ASN.1 module files listed in IMPORTS section of primary module. Added option for specifying directories to search when looking for imported ASN.1 modules. Now only primary ASN.1 module needs to be passed to the compiler. 2) Enhanced compiler to support OCTET STRING CONTAINS DER ENCODING feature. 3) Enhanced AsnBuf, ASNOcts, ASNAny class to expand as necessary when encoding and to decode directly from a file. CSM_Buffer moved out of eSNACC. 4) Enhanced C Library to use GenBuf to provide improved buffer processing capabilities. We successfully tested the v1.5 eSNACC ASN.1 C++ and C libraries using the Simple Network Management Protocol (SNMP) v1 test suite (18,000 test cases) developed by the University of Oulu. We tested the v1.5 eSNACC release with the v2.2 S/MIME Freeware Library (SFL) available from that uses the eSNACC ASN.1 software to encode and decode the IETF S/MIME v3 Cryptographic Message Syntax (RFC 3369) and Enhanced Security Services for S/MIME (RFC 2634) security protocol. We tested the v1.5 eSNACC release with the freeware v2.2 Certificate Management Library (CML) available from that uses the eSNACC ASN.1 software to encode and decode X.509 certificates, attribute certificates and Certificate Revocation Lists as specified in the 2000 X.509 Recommendation. We tested the v1.5 eSNACC release with the freeware v2.2 Access Control Library (ACL) available from that uses the eSNACC ASN.1 software to encode and decode security labels and other objects (such as Security Policy Information Files) required to provide rule based automated access control as specified in SDN.801. The eSNACC ASN.1 software implements the majority of the ASN.1 encoding/decoding rules as specified in the 1988 X.209 Recommendation. It implements the DER as specified in the 1997 X.690 Recommendation. It does not support all of the latest ASN.1 features, but there are strategies that allow it to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 3280 and RFC 2630, include 1988-compliant ASN.1 syntax modules which can be compiled using the eSNACC compiler. The eSNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the eSNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the eSNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established an eSNACC web page . The IMC has established an eSNACC mail list which is used to: distribute information regarding eSNACC releases; discuss related issues; and provide a means for integrators to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We are still in the process of improving the eSNACC software. We welcome all feedback regarding the eSNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This release announcement was sent to several mail lists, but please send all messages regarding the eSNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the eSNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC ================================================= From owner-ietf-pkix@mail.imc.org Mon Feb 24 18:38:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00363 for ; Mon, 24 Feb 2003 18:38:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONEku04532 for ietf-pkix-bks; Mon, 24 Feb 2003 15:14:46 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONEkd04528 for ; Mon, 24 Feb 2003 15:14:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v2.2 Certificate Management Library (CML) Now Available Date: Mon, 24 Feb 2003 18:14:48 -0500 Message-ID: Thread-Topic: v2.2 Certificate Management Library (CML) Now Available Thread-Index: AcI5gE4M/klWhmpWSMGjrjHpK3/8Ow== From: "Pawling, John" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1ONEkd04529 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, DigitalNet (formerly Getronics Government Solutions) has delivered the Version 2.2 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux. The v2.2 CML and documentation is freely available at: . Applications requiring Public Key Infrastructure (PKI) security services can use the CML to meet their X.509 certificate and Certificate Revocation List (CRL) processing requirements. The v2.2 CML is described in the v2.2 CML Application Programming Interface (API) document. It implements the 2000 X.509 Recommendation certification path verification processing rules and SDN.706 profile. It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile requirements. There are some unsupported features such as Delta CRLs. The v2.2 CML Abstract Syntax Notation One (ASN.1) decodes X.509 Certificates and CRLs. It requires the v1.5 Enhanced SNACC ASN.1 software that is freely available from: . The CML provides robust certification path building capabilities such as using cross certificates. The CML uses the accompanying Storage and Retrieval Library (SRL) (optionally) to provide local certificate and CRL storage management functions. The SRL (optionally) provides remote directory retrieval capabilities using the Lightweight Directory Access Protocol (LDAP). The CML has been thoroughly tested including validating X.509 Certificates and CRLs created by a variety of Certification Authority (CA) products, and signed using the Digital Signature Algorithm (DSA) and RSA algorithms. Further enhancements, ports and testing of the CML are still in process. Further releases of the CML will be provided as significant capabilities are added. v2.2 CML includes the following enhancements (compared to v2.1 CML release): 1) Significantly improved robustness of the certification path building capabilities (especially the building of paths in cross-certified PKI environments). 2) Significantly improved performance and reduced memory requirements of CRL decoding and processing. 3) Enhanced the CML C++ library to support name constraints processing of the IPAddress GeneralName type. 4) Enhanced CML ASN.1 code to process both correct X.501 Clearance attribute syntax. 5) See the CML web site and CML API document for further details. v2.2 SRL includes the following enhancements (compared to v2.1 SRL release): 1) Enhanced SRL to remove the dependency on a local LDAP distribution located in the SMPDist directory. The new SRL uses the distribution that the customer is using on their platform. 2) Enhanced SRL to remove the dependency on LDAP header files. All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees. The CML was originally developed by the U.S. Government. DigitalNet is enhancing and supporting the CML under contract to the U.S. Government. The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software. The CML makes calls to an algorithm-independent CTIL API that provides access to a variety of external crypto libraries. There is a CTIL for each crypto library that maps the generic CTIL API calls to the specific calls for that crypto library. DigitalNet provides CTILs for the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used with the CML. The underlying, external crypto libraries are not distributed as part of the CML software. The CML has been successfully tested with the v2.2 S/MIME Freeware Library (SFL) that is freely available from . The CML has been successfully tested with the v2.2 Access Control Library (ACL) that is freely available to everyone from: . The CML has been successfully used to build and verify certificate paths used in the Bridge Certification Authority (BCA) demonstration which includes cross-certified hierarchical and non- hierarchical PKIs. The BCA Interoperability Test Suite (BITS) is a free and openly available test resource provided to facilitate vendor development of secure, interoperable Public Key Enabled applications. The CML has been used to successfully develop and verify the BITS X.509 certification paths available from . The National Institute of Standards and Technology (NIST) is providing a standard test suite of X.509 certificate paths that can be used for testing applications against RFC 2459. The CML was used to successfully process the NIST test data. The CML meets the requirements stated in the SDN.706 Certificate/ CRL Profile required by the U.S. Defense Message System (DMS) project. The Internet Mail Consortium (IMC) has established a CML web page and a CML mail list which is used to: distribute information regarding CML releases; discuss CML-related issues; and allow CML users to provide feedback, comments, bug reports, etc. Subscription information for the imc-cml mailing list is at the IMC web site listed above. All comments regarding the CML source code and documents are welcome. This CML release announcement was sent to several mail lists, but please send all messages regarding the CML to the imc-cml mail list ONLY. Please do not send messages regarding the CML to any of the IETF mail lists. We will respond to all messages sent to the imc-cml mail list. =========================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC =========================================== From owner-ietf-pkix@mail.imc.org Mon Feb 24 22:22:48 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04602 for ; Mon, 24 Feb 2003 22:22:48 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1P2qmI11527 for ietf-pkix-bks; Mon, 24 Feb 2003 18:52:48 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1P2qld11523 for ; Mon, 24 Feb 2003 18:52:47 -0800 (PST) Received: (qmail 19079 invoked from network); 25 Feb 2003 02:45:57 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.110) by woodstock.binhost.com with SMTP; 25 Feb 2003 02:45:57 -0000 Message-Id: <5.2.0.9.2.20030224143338.02bcfe68@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 Feb 2003 16:27:58 -0500 To: BKaliski@rsasecurity.com, jimsch@exmsft.com From: Russ Housley Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Cc: IETF-PKIX@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Burt & Jim: Clearly there are some choices. I believe that use of the same object identifier is the best we can do given the current state of the world. The solution that we devise needs to be backward compatible. I do not think that assigning two OIDs for each possible use of an RSA or Elliptic Curve public key is desirable. We already need to assign one OID for the signature validation (or key management technique). Assigning a second OID for use in the subject public key info to say that the key can only be used in a particular manner is only useful if the parameters that are already associated with the currently assigned OID do not support the necessary information. Russ >[JS] 7. Section 3.2. I would like to see a different OID used for a >signature value from that used to encode the public key. This makes it >easier to process for encode/decode as there are not two structures with >the same OID. > >[BK] The OID is not used to encode the public key directly, but to encode an >AlgorithmID; the AlgorithmID is used to describe the public key. So, the >AlgorithmID has two meanings, one for the signature, one for the public key. >I agree this is potential problem, and am open to alternatives. From Live_From_the_Street_99587@aol.com Tue Feb 25 07:38:23 2003 Received: from 61.150.93.253 ([202.88.158.75]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27849 for ; Tue, 25 Feb 2003 07:38:18 -0500 (EST) Message-Id: <200302251238.HAA27849@ietf.org> Received: from [198.250.227.71] by m10.grp.snv.yahoo.com with QMQP; Feb, 25 2003 5:15:27 AM -0800 Received: from 87.15.78.89 ([87.15.78.89]) by pet.vosn.net with local; Feb, 25 2003 4:30:49 AM -0100 From: Kumaravel To: Fermi Subject: LIVE FROM WALL STREET: VICC Test Results Are In... awwhx Sender: Kumaravel Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 25 Feb 2003 06:40:53 -0600 X-Mailer: Microsoft Outlook Build 10.0.2627

If you bought into our last recommendation (CIMG) early enough you had an excellent opportunity to make substantial gains (from .90 to 1.65 in just the first day). Now is your chance to do the same with our newest pick: IMTS. To find out more go to Live From the Street.

If you no longer want to receive information from us just go to tallrhe@cs.com.

  qhfdvpfjnleimnkdmmtwjfjjsnpwtbfeigrdml From owner-ietf-pkix@mail.imc.org Wed Feb 26 15:30:39 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23495 for ; Wed, 26 Feb 2003 15:30:38 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QJv0R25600 for ietf-pkix-bks; Wed, 26 Feb 2003 11:57:00 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [204.167.114.129] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QJuxd25595 for ; Wed, 26 Feb 2003 11:56:59 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Feb 2003 19:57:01 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA18670; Wed, 26 Feb 2003 14:56:54 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <1WBW8QS3>; Wed, 26 Feb 2003 14:56:48 -0500 Message-ID: From: "Kaliski, Burt" To: "'Tom Gindin'" , Russ Housley Cc: "Manger, James H" , IETF-PKIX@imc.org Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Wed, 26 Feb 2003 14:56:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, Our intent is the encourage the use of a key pair with only one algorithm. The security analysis for each algorithm assumes a key pair is used with only the particular algorithm (and with a generally fixed set of underlying components). While we are not aware of any "bad" interactions if a key is used for both RSAES-OAEP and RSASSA-PSS, the security "assurance" may be reduced because the security analysis is no longer directly applicable. (If someone were to do the full security analysis for the use of a key pair with both algorithms, and the result were positive, then there would be motivation to change this recommendation.) Similarly, we would not recommend using a key with PKCS1-V1_5 and either of the newer schemes. But I understand that to encourage adoption of the new schemes, it may be necessary to allow a key pair to be used with more than one algorithm in the interim. -- Burt -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Saturday, February 22, 2003 8:15 AM To: Russ Housley; Kaliski, Burt Cc: Manger, James H; IETF-PKIX@imc.org Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Russ, Burt: Is the statement in section 6 of RFC 3447 (PKCS #2 2.1) really intended to suggest that TLS/SSL servers and S/MIME clients should not be implemented with single RSA key pairs which use RSA-PSS for signatures and also use RSA-OAEP for key encipherment? It seems to cover that case, although the examples given suggest that using two distinct signature-capable schemes is undesirable, as is using two distinct encryption-capable schemes, and so it is wrong to use PKCS1-V1_5 with either of the newer schemes. Tom Gindin From owner-ietf-pkix@mail.imc.org Wed Feb 26 17:04:58 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28452 for ; Wed, 26 Feb 2003 17:04:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QLb3A29821 for ietf-pkix-bks; Wed, 26 Feb 2003 13:37:03 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QLb1d29816 for ; Wed, 26 Feb 2003 13:37:01 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Wed, 26 Feb 2003 16:36:58 -0500 Message-ID: <9A4F653B0A375841AC75A8D17712B9C9061ABFF0@sottmxs04.entrust.com> From: Sharon Boeyen To: "'chokhani@orionsec.com'" , n Russ Housley Cc: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Date: Wed, 26 Feb 2003 16:36:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > From owner-ietf-pkix@mail.imc.org Wed Feb 26 21:20:00 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06146 for ; Wed, 26 Feb 2003 21:19:59 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1R1qjl09914 for ietf-pkix-bks; Wed, 26 Feb 2003 17:52:45 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1R1qid09910 for ; Wed, 26 Feb 2003 17:52:44 -0800 (PST) Received: from chokhani (124.washington-16rh15rt.dc.dial-access.att.net[12.91.134.124]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003022701523411200il8ese>; Thu, 27 Feb 2003 01:52:34 +0000 From: "Santosh Chokhani" To: "'Sharon Boeyen'" , "'n Russ Housley'" Cc: , Subject: RE: SkipCerts Question [RFC3280] Date: Wed, 26 Feb 2003 20:53:03 -0500 Message-ID: <001d01c2de02$f7f67420$7c865b0c@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <9A4F653B0A375841AC75A8D17712B9C9061ABFF0@sottmxs04.entrust.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1R1qid09911 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > From owner-ietf-pkix@mail.imc.org Thu Feb 27 10:36:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08391 for ; Thu, 27 Feb 2003 10:36:03 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RF5YA10700 for ietf-pkix-bks; Thu, 27 Feb 2003 07:05:34 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RF5WY10695 for ; Thu, 27 Feb 2003 07:05:32 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Feb 2003 10:05:28 -0500 Message-ID: <9A4F653B0A375841AC75A8D17712B9C9061ABFF1@sottmxs04.entrust.com> From: Sharon Boeyen To: "'Santosh Chokhani'" , Sharon Boeyen , "'n Russ Housley'" Cc: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 10:05:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > From owner-ietf-pkix@mail.imc.org Thu Feb 27 10:38:05 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08459 for ; Thu, 27 Feb 2003 10:38:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFF8L11149 for ietf-pkix-bks; Thu, 27 Feb 2003 07:15:08 -0800 (PST) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFF7Y11145 for ; Thu, 27 Feb 2003 07:15:07 -0800 (PST) Received: from chokhani (4.washington-31rh15rt.dc.dial-access.att.net[12.91.164.4]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003022715150011100rfgoke>; Thu, 27 Feb 2003 15:15:01 +0000 From: "Santosh Chokhani" To: "'Sharon Boeyen'" , "'n Russ Housley'" Cc: , Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 10:15:29 -0500 Message-ID: <002d01c2de73$116a7530$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9A4F653B0A375841AC75A8D17712B9C9061ABFF1@sottmxs04.entrust.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1RFF7Y11146 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sharon: My reading is very simple. My reading is as follows and it applies in general and not just to the last certificate in chain or other esoteric stuff. 2000 edition of X.509 starts applying the skipCerts for requireExplicitPolicy to the certificate in which it is asserted. 3280 applies the skipCerts for requireExplicitPolicy to the next certificate. For example, in the example Kodo cited (and in a private e-mail he agreed with me), 3280 will not require explicit policy for the path and X.509 will. The reasons are articulated in this thread by me. I will call you to discuss this. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 10:05 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > From owner-ietf-pkix@mail.imc.org Thu Feb 27 10:38:30 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08474 for ; Thu, 27 Feb 2003 10:38:30 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFEuX11130 for ietf-pkix-bks; Thu, 27 Feb 2003 07:14:56 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFEsY11126 for ; Thu, 27 Feb 2003 07:14:55 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Feb 2003 10:14:50 -0500 Message-ID: From: Robert Zuccherato To: IETF-PKIX@imc.org Subject: RFC 3161 Interoperability Site Date: Thu, 27 Feb 2003 10:14:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE72.F7584370" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DE72.F7584370 Content-Type: text/plain; charset="iso-8859-1" Entrust would like to announce that we have made available an RFC 3161 compliant TSA for interoperability test purposes. It is accessible at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp and supports the HTTP protocol as specified in RFC 3161. The CA certificate required to verify the TSA certificate is available in Base 64 format at http://vsinterop.entrust.com:7001/verificationserver/ca.cer. The site is for interoperability testing of the RFC 3161 HTTP protocol only and is not guaranteed to be operational 24/7. If anyone has any questions or any problems arise with the site, please direct them to vsinterop-support@entrust.com. Robert Zuccherato ------_=_NextPart_001_01C2DE72.F7584370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 3161 Interoperability Site

Entrust would like to announce that we = have made available an RFC 3161 compliant TSA for interoperability test = purposes.  It is accessible at http://vsinterop.entrust.com:7001/verificationserver/r= fc3161timestamp and supports the HTTP protocol as specified in RFC = 3161.  The CA certificate required to verify the TSA certificate = is available in Base 64 format at http://vsinterop.entrust.com:7001/verificationserver/c= a.cer. 

The site is for interoperability = testing of the RFC 3161 HTTP protocol only and is not guaranteed to be = operational 24/7.  If anyone has any questions or any problems = arise with the site, please direct them to = vsinterop-support@entrust.com.


        Robert Zuccherato

------_=_NextPart_001_01C2DE72.F7584370-- From owner-ietf-pkix@mail.imc.org Thu Feb 27 11:18:16 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10021 for ; Thu, 27 Feb 2003 11:18:16 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFsmV15204 for ietf-pkix-bks; Thu, 27 Feb 2003 07:54:48 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFskY15196 for ; Thu, 27 Feb 2003 07:54:47 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23632; Thu, 27 Feb 2003 16:57:09 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA31958; Thu, 27 Feb 2003 15:48:18 +0100 Message-ID: <3E5E3426.7070803@bull.net> Date: Thu, 27 Feb 2003 16:52:06 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Robert Zuccherato CC: IETF-PKIX@imc.org Subject: Re: RFC 3161 Interoperability Site References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Robert, Thank you for posting this message. However no implementation can yet claim to be "RFC 3161 compliant" since no interoperability test has been performed up to now. An interoperability test matrix has been sent to different people (in fact all people I have been aware of) that have announced to support the Time-Stamp Protocol from the IETF, but two companies (with independent implementations) still need to fill-in the matrix so that we can progress RFC 3161 to Proposed Standard. The only "difficult" part is to test the error cases in both directions. Denis > Entrust would like to announce that we have made available an RFC 3161 > compliant TSA for interoperability test purposes. It is accessible at > http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp > and supports the HTTP protocol as specified in RFC 3161. The CA > certificate required to verify the TSA certificate is available in Base > 64 format at http://vsinterop.entrust.com:7001/verificationserver/ca.cer. > > The site is for interoperability testing of the RFC 3161 HTTP protocol > only and is not guaranteed to be operational 24/7. If anyone has any > questions or any problems arise with the site, please direct them to > vsinterop-support@entrust.com. > > > Robert Zuccherato > From owner-ietf-pkix@mail.imc.org Thu Feb 27 11:30:47 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10373 for ; Thu, 27 Feb 2003 11:30:46 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RG2Wb16639 for ietf-pkix-bks; Thu, 27 Feb 2003 08:02:32 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RG2VY16635 for ; Thu, 27 Feb 2003 08:02:31 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Feb 2003 11:02:27 -0500 Message-ID: <9A4F653B0A375841AC75A8D17712B9C9061ABFF3@sottmxs04.entrust.com> From: Sharon Boeyen To: "'Santosh Chokhani'" , Sharon Boeyen , "'n Russ Housley'" Cc: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 11:02:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh and I did chat on the phone and worked through the processing steps in both 509 and 3280 for the example (see below). Both would have the same outcome for the path, however both Santosh and I believe the text in 3280 that describes the policyConstraints extension needs to be changed to align with both the 3280 path validation procedure and with 509 itself. Currently the text in 3280 clause 4.2.1.12 aligns with the pre DR 222 X.509 description, but the 3280 validation process aligns with the post DR 222 policy constraints. Santosh may propose some rewording for 4.2.1.12. Here is how X.509 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 10.5.3 sets the pending variable to 1 - when processing certificate 3 clause 10.5.3 decrements the pending variable to 0 and sets the explicit-policy-indicator flag on. Clause 10.5.3 and 10.5.4 perform the checks to satisfy the explicit-policy-indicator flag. Here is how RFC 3280 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 6.1.4 step i sets the pending variable to 1 - when processing certificate 2 clause 6.1.5 step a decrements the pending variable to 0. - the very last test conducted at the end of 6.1.5 (see paragraph immediately above 6.1.6) says that the path succeeds if explicit-policy is greater than zero. In this example explicit-policy has reached zero and therefore the path fails. Because X.509 requires only that an implementation be "functionally equivalent to the external behaviour resulting from this procedure" the RFC 3280 path validation algorithm is conformant because the external behaviour is the same. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Thursday, February 27, 2003 10:15 AM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: My reading is very simple. My reading is as follows and it applies in general and not just to the last certificate in chain or other esoteric stuff. 2000 edition of X.509 starts applying the skipCerts for requireExplicitPolicy to the certificate in which it is asserted. 3280 applies the skipCerts for requireExplicitPolicy to the next certificate. For example, in the example Kodo cited (and in a private e-mail he agreed with me), 3280 will not require explicit policy for the path and X.509 will. The reasons are articulated in this thread by me. I will call you to discuss this. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 10:05 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > From owner-ietf-pkix@mail.imc.org Thu Feb 27 11:49:43 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11036 for ; Thu, 27 Feb 2003 11:49:42 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RGKTq17929 for ietf-pkix-bks; Thu, 27 Feb 2003 08:20:29 -0800 (PST) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RGKRY17925 for ; Thu, 27 Feb 2003 08:20:28 -0800 (PST) Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h1RGK0f1027794 for ; Thu, 27 Feb 2003 11:20:01 -0500 (EST) Message-ID: <3E5E3AF5.20707@nist.gov> Date: Thu, 27 Feb 2003 11:21:09 -0500 From: "David A. Cooper" Reply-To: david.cooper@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] References: <002d01c2de73$116a7530$9900a8c0@Chokhani> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Santosh Chokhani wrote: >I do not understand your first point. Are you saying that X.509 will be >changed to align with 3280 and in that case skipCerts = 0 for >requireExplicitPolicy will also take effect in the next certificate? Or, >are you saying that the difference between 3280 and X.509 will remain? I >assume you agree that I am reading 3280 correctly. > Santosh, X.509 and RFC 3280 both state that if a certificate includes requireExplicitPolicy with skipCerts = 0, the constraint takes effect immediately. In X.509, this can be seen in the following statements: Clause 10.5.3: For all certificates, the following actions are then performed: a) If explicit-policy-indicator is not set: If the requireExplicitPolicy constraint is present in the certificate, perform the following. For a SkipCerts value of 0, set the explicit-policy-indicator. Clause 10.5.4: For the end-certificate, the following actions are then performed: a) If explicit-policy-indicator is set, check that the authorities-constrained-policy-set table is not empty. (NOTE: As a result of DR 289, X.509 now requires that one also check that the user-constrained-policy-set is not empty). In RFC 3280: section 6.1.4 (processing of intermediate certificates): (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: (1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. section 6.1.5 (wrap-up procedure): (b) If a policy constraints extension is included in the certificate and requireExplicitPolicy is present and has a value of 0, set the explicit_policy state variable to 0. If either (1) the value of explicit_policy variable is greater than zero, or (2) the valid_policy_tree is not NULL, then path processing has succeeded. So, in both cases, if requireExplicitPolicy is present with SkipCerts=0, even in the final certificate in the path, then the path will be rejected unless it is valid under at least one user acceptable policy. The two documents also agree on the processing requirements when skipCerts > 0. When Sharon mentioned a new defect report against X.509, she was referring to the text in clause 8.4.2.3 that describes the policyConstraints extension. There was concern that this text was somewhat ambiguous. The text in clause 10, which provides detailed, step-by-step, processing requirements for the fields in the policyConstraints extension will not be changed. There is, however, one place in which X.509 and RFC 3280 diverge in the processing of the requireExplicitPolicy field of policyConstraints. X.509 states in clause 10.5.3: if the explicit-policy-pending indicator is set and the certificate is not a self-issued intermediate certificate, decrement the corresponding skip-certificates value and, if this value becomes zero, set explicit-policy-indicator. RFC 3280 states in section 6.1.5 (prcessing of the final certificate in the path): (a) If certificate n was not self-issued and explicit_policy is not 0, decrement explicit_policy by 1. Thus, in X.509 a self-issued end certificate counts when determining whether the path is long enough to "turn on" the constraint. In RFC 3280, a self-issued end certifcate does not count. Since, as a general rule, self-issued end certificates are treated the same as certificates that are not self-issued, I believe this was an error in RFC 3280. Dave From owner-ietf-pkix@mail.imc.org Thu Feb 27 13:45:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16269 for ; Thu, 27 Feb 2003 13:45:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RIC1S24809 for ietf-pkix-bks; Thu, 27 Feb 2003 10:12:01 -0800 (PST) Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RIBxY24801 for ; Thu, 27 Feb 2003 10:11:59 -0800 (PST) Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Feb 2003 12:13:40 -0600 From: "Miguel Rodriguez" To: "'Denis Pinkas'" Cc: Subject: RE: RFC 3161 Interoperability Site Date: Thu, 27 Feb 2003 12:10:12 -0600 Message-ID: <000601c2de8b$78c25fa0$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3E5E3426.7070803@bull.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 27 Feb 2003 18:13:40.0515 (UTC) FILETIME=[F496F730:01C2DE8B] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Denis, Can you send me (or tell me where can I get) a copy of the TSP interoperability test matrix? Regards, Miguel A Rodriguez SeguriDATA Mexico > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: Jueves, 27 de Febrero de 2003 09:52 a.m. > To: Robert Zuccherato > Cc: IETF-PKIX@imc.org > Subject: Re: RFC 3161 Interoperability Site > > > Robert, > > Thank you for posting this message. > > However no implementation can yet claim to be "RFC 3161 compliant" since > no > interoperability test has been performed up to now. > > An interoperability test matrix has been sent to different people (in fact > all people I have been aware of) that have announced to support the > Time-Stamp Protocol from the IETF, but two companies (with independent > implementations) still need to fill-in the matrix so that we can progress > RFC 3161 to Proposed Standard. > > The only "difficult" part is to test the error cases in both directions. > > Denis > > > Entrust would like to announce that we have made available an RFC 3161 > > compliant TSA for interoperability test purposes. It is accessible at > > http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp > > and supports the HTTP protocol as specified in RFC 3161. The CA > > certificate required to verify the TSA certificate is available in Base > > 64 format at > http://vsinterop.entrust.com:7001/verificationserver/ca.cer. > > > > The site is for interoperability testing of the RFC 3161 HTTP protocol > > only and is not guaranteed to be operational 24/7. If anyone has any > > questions or any problems arise with the site, please direct them to > > vsinterop-support@entrust.com. > > > > > > Robert Zuccherato > > > From owner-ietf-pkix@mail.imc.org Thu Feb 27 13:49:21 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16616 for ; Thu, 27 Feb 2003 13:49:21 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RIKKm25300 for ietf-pkix-bks; Thu, 27 Feb 2003 10:20:20 -0800 (PST) Received: from mail.multicert.com ([62.48.185.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RIKIY25295 for ; Thu, 27 Feb 2003 10:20:18 -0800 (PST) Received: from multicert.com (unknown [192.168.0.125]) by mail.multicert.com (Postfix) with ESMTP id 0F8775B80C; Thu, 27 Feb 2003 18:14:59 +0000 (WET) Message-ID: <3E5E5627.6080405@multicert.com> Date: Thu, 27 Feb 2003 18:17:11 +0000 From: Ricardo Barroso User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: Robert Zuccherato , IETF-PKIX@imc.org Subject: Re: RFC 3161 Interoperability Site References: <3E5E3426.7070803@bull.net> Content-Type: multipart/alternative; boundary="------------050107050402010707080508" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------050107050402010707080508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello! Denis, since we wan't to start soon our interoperability tests, can you please send me that interoperability test matrix? Thanks in advance, Ricardo Barroso MULTICERT S.A. Denis Pinkas wrote: > > Robert, > > Thank you for posting this message. > > However no implementation can yet claim to be "RFC 3161 compliant" > since no interoperability test has been performed up to now. > > An interoperability test matrix has been sent to different people (in > fact all people I have been aware of) that have announced to support > the Time-Stamp Protocol from the IETF, but two companies (with > independent implementations) still need to fill-in the matrix so that > we can progress RFC 3161 to Proposed Standard. > > The only "difficult" part is to test the error cases in both directions. > > Denis > >> Entrust would like to announce that we have made available an RFC >> 3161 compliant TSA for interoperability test purposes. It is >> accessible at >> http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp >> and supports the HTTP protocol as specified in RFC 3161. The CA >> certificate required to verify the TSA certificate is available in >> Base 64 format at >> http://vsinterop.entrust.com:7001/verificationserver/ca.cer. >> The site is for interoperability testing of the RFC 3161 HTTP >> protocol only and is not guaranteed to be operational 24/7. If >> anyone has any questions or any problems arise with the site, please >> direct them to vsinterop-support@entrust.com. >> >> >> Robert Zuccherato >> > > --------------050107050402010707080508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello!

Denis, since we wan't to start soon our interoperability tests,
can you please send me that interoperability test matrix?

Thanks in advance,
Ricardo Barroso
MULTICERT S.A.


Denis Pinkas wrote:

Robert,

Thank you for posting this message.

However no implementation can yet claim to be "RFC 3161 compliant" since no interoperability test has been performed up to now.

An interoperability test matrix has been sent to different people (in fact all people I have been aware of) that have announced to support the Time-Stamp Protocol from the IETF, but two companies (with independent implementations) still need to fill-in the matrix so that we can progress RFC 3161 to Proposed Standard.

The only "difficult" part is to test the error cases in both directions.

Denis

Entrust would like to announce that we have made available an RFC 3161 compliant TSA for interoperability test purposes.  It is accessible at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp and supports the HTTP protocol as specified in RFC 3161.  The CA certificate required to verify the TSA certificate is available in Base 64 format at http://vsinterop.entrust.com:7001/verificationserver/ca.cer.
The site is for interoperability testing of the RFC 3161 HTTP protocol only and is not guaranteed to be operational 24/7.  If anyone has any questions or any problems arise with the site, please direct them to vsinterop-support@entrust.com.


        Robert Zuccherato




--------------050107050402010707080508-- From owner-ietf-pkix@mail.imc.org Thu Feb 27 16:31:19 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24752 for ; Thu, 27 Feb 2003 16:31:19 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RKtZb04703 for ietf-pkix-bks; Thu, 27 Feb 2003 12:55:35 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RKtYY04698 for ; Thu, 27 Feb 2003 12:55:34 -0800 (PST) Received: from chokhani (149.washington-15rh15rt.dc.dial-access.att.net[12.91.132.149]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003022720552911200ie6jfe>; Thu, 27 Feb 2003 20:55:29 +0000 From: "Santosh Chokhani" To: Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 15:55:59 -0500 Message-ID: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E5E3AF5.20707@nist.gov> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1RKtYY04700 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit David: As Sharon notes, the text in the description of the extension needs to change. It will also nice to note that if skipCert < = 0 and valid_policy_tree = null, there is policy failure. I will propose some changes to both sections. The first one in my mind is a must (i.e., the description of the extension). The second one (i.e., in the path validation) is to simply add clarity that other wise path validation fails. I will propose some text later in response to Sharon's e-mail. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Thursday, February 27, 2003 11:21 AM To: ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Santosh Chokhani wrote: >I do not understand your first point. Are you saying that X.509 will >be changed to align with 3280 and in that case skipCerts = 0 for >requireExplicitPolicy will also take effect in the next certificate? >Or, are you saying that the difference between 3280 and X.509 will >remain? I assume you agree that I am reading 3280 correctly. > Santosh, X.509 and RFC 3280 both state that if a certificate includes requireExplicitPolicy with skipCerts = 0, the constraint takes effect immediately. In X.509, this can be seen in the following statements: Clause 10.5.3: For all certificates, the following actions are then performed: a) If explicit-policy-indicator is not set: If the requireExplicitPolicy constraint is present in the certificate, perform the following. For a SkipCerts value of 0, set the explicit-policy-indicator. Clause 10.5.4: For the end-certificate, the following actions are then performed: a) If explicit-policy-indicator is set, check that the authorities-constrained-policy-set table is not empty. (NOTE: As a result of DR 289, X.509 now requires that one also check that the user-constrained-policy-set is not empty). In RFC 3280: section 6.1.4 (processing of intermediate certificates): (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: (1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. section 6.1.5 (wrap-up procedure): (b) If a policy constraints extension is included in the certificate and requireExplicitPolicy is present and has a value of 0, set the explicit_policy state variable to 0. If either (1) the value of explicit_policy variable is greater than zero, or (2) the valid_policy_tree is not NULL, then path processing has succeeded. So, in both cases, if requireExplicitPolicy is present with SkipCerts=0, even in the final certificate in the path, then the path will be rejected unless it is valid under at least one user acceptable policy. The two documents also agree on the processing requirements when skipCerts > 0. When Sharon mentioned a new defect report against X.509, she was referring to the text in clause 8.4.2.3 that describes the policyConstraints extension. There was concern that this text was somewhat ambiguous. The text in clause 10, which provides detailed, step-by-step, processing requirements for the fields in the policyConstraints extension will not be changed. There is, however, one place in which X.509 and RFC 3280 diverge in the processing of the requireExplicitPolicy field of policyConstraints. X.509 states in clause 10.5.3: if the explicit-policy-pending indicator is set and the certificate is not a self-issued intermediate certificate, decrement the corresponding skip-certificates value and, if this value becomes zero, set explicit-policy-indicator. RFC 3280 states in section 6.1.5 (prcessing of the final certificate in the path): (a) If certificate n was not self-issued and explicit_policy is not 0, decrement explicit_policy by 1. Thus, in X.509 a self-issued end certificate counts when determining whether the path is long enough to "turn on" the constraint. In RFC 3280, a self-issued end certifcate does not count. Since, as a general rule, self-issued end certificates are treated the same as certificates that are not self-issued, I believe this was an error in RFC 3280. Dave From owner-ietf-pkix@mail.imc.org Thu Feb 27 21:36:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01164 for ; Thu, 27 Feb 2003 21:36:56 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S2ARe14231 for ietf-pkix-bks; Thu, 27 Feb 2003 18:10:27 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S2APY14227 for ; Thu, 27 Feb 2003 18:10:25 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1S2AIU06697; Fri, 28 Feb 2003 11:10:18 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1S2AHk25380; Fri, 28 Feb 2003 11:10:17 +0900 (JST) Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.109.63.71]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h1S29wH25647; Fri, 28 Feb 2003 11:10:16 +0900 (JST) Received: from smtp5.necst.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-02/23/03) with ESMTP id LAA14843; Fri, 28 Feb 2003 11:09:56 +0900 (JST) From: k-fujino@pb.jp.nec.com Received: by smtp5.necst.nec.co.jp id h1S1owu16303 ; Fri, 28 Feb 2003 10:50:58 +0900 (JST) Received: from ecpc15 by smtp5.necst.nec.co.jp with SMTP id h1S1ouU16300 ; Fri, 28 Feb 2003 10:50:56 +0900 (JST) To: Cc: Santosh Chokhani , sharon.boeyen@entrust.com Reply-To: k-fujino@pb.jp.nec.com Subject: RE: SkipCerts Question [RFC3280] In-reply-to: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> Message-Id: <20030228105055k-fujino@smtp.necst.nec.co.jp> References: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> Mime-Version: 1.0 X-Mailer: WeMail32[2.08D] ID:NECST0 Date: Fri, 28 Feb 2003 10:50:55 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Santosh: According to the RFC3280, after decrementing explicit_policy, the value would be reset. Therefore if some changes are needed, the following also need to be changed. Thank you, Kozo ----- 6.1.4 Preparation for Certificate i+1 (h) If the issuer and subject names are not identical: (1) If explicit_policy is not 0, decrement explicit_policy by 1. (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: $B!!(B(1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. ----- -----Original Message----- From:"Santosh Chokhani" Date:Thu, 27 Feb 2003 15:55:59 -0500 Subject:RE: SkipCerts Question [RFC3280] > >David: > >As Sharon notes, the text in the description of the extension needs to >change. It will also nice to note that if skipCert < = 0 and >valid_policy_tree = null, there is policy failure. > >I will propose some changes to both sections. The first one in my mind is a >must (i.e., the description of the extension). The second one (i.e., in the >path validation) is to simply add clarity that other wise path validation >fails. I will propose some text later in response to Sharon's e-mail. > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On >Behalf Of David A. Cooper >Sent: Thursday, February 27, 2003 11:21 AM >To: ietf-pkix@imc.org >Subject: Re: SkipCerts Question [RFC3280] > > > >Santosh Chokhani wrote: > >>I do not understand your first point. Are you saying that X.509 will >>be changed to align with 3280 and in that case skipCerts = 0 for >>requireExplicitPolicy will also take effect in the next certificate? >>Or, are you saying that the difference between 3280 and X.509 will >>remain? I assume you agree that I am reading 3280 correctly. >> >Santosh, > >X.509 and RFC 3280 both state that if a certificate includes >requireExplicitPolicy with skipCerts = 0, the constraint takes effect >immediately. > >In X.509, this can be seen in the following statements: > > >Clause 10.5.3: > For all certificates, the following actions are then performed: > > a) If explicit-policy-indicator is not set: > > If the requireExplicitPolicy constraint is present in the >certificate, perform the > following. For a SkipCerts value of 0, set the >explicit-policy-indicator. > >Clause 10.5.4: > For the end-certificate, the following actions are then performed: > > a) If explicit-policy-indicator is set, check that the >authorities-constrained-policy-set table is not empty. > (NOTE: As a result of DR 289, X.509 now requires that one also >check that the user-constrained-policy-set > is not empty). > > > >In RFC 3280: > >section 6.1.4 (processing of intermediate certificates): > > (i) If a policy constraints extension is included in the > certificate, modify the explicit_policy and policy_mapping state > variables as follows: > > (1) If requireExplicitPolicy is present and is less than > explicit_policy, set explicit_policy to the value of > requireExplicitPolicy. > >section 6.1.5 (wrap-up procedure): > > (b) If a policy constraints extension is included in the > certificate and requireExplicitPolicy is present and has a value > of 0, set the explicit_policy state variable to 0. > > If either (1) the value of explicit_policy variable is greater than > zero, or (2) the valid_policy_tree is not NULL, then path processing > has succeeded. > > > >So, in both cases, if requireExplicitPolicy is present with SkipCerts=0, >even in the final certificate in the path, then the path will be >rejected unless it is valid under at least one user acceptable policy. > The two documents also agree on the processing requirements when >skipCerts > 0. > >When Sharon mentioned a new defect report against X.509, she was >referring to the text in clause 8.4.2.3 that describes the >policyConstraints extension. There was concern that this text was >somewhat ambiguous. The text in clause 10, which provides detailed, >step-by-step, processing requirements for the fields in the >policyConstraints extension will not be changed. > > >There is, however, one place in which X.509 and RFC 3280 diverge in the >processing of the requireExplicitPolicy field of policyConstraints. > >X.509 states in clause 10.5.3: > > if the explicit-policy-pending indicator is set and the certificate >is not a self-issued intermediate certificate, > decrement the corresponding skip-certificates value and, if this >value becomes zero, set explicit-policy-indicator. > >RFC 3280 states in section 6.1.5 (prcessing of the final certificate in >the path): > > (a) If certificate n was not self-issued and explicit_policy is > not 0, decrement explicit_policy by 1. > > >Thus, in X.509 a self-issued end certificate counts when determining >whether the path is long enough to "turn on" the constraint. In RFC >3280, a self-issued end certifcate does not count. > >Since, as a general rule, self-issued end certificates are treated the >same as certificates that are not self-issued, I believe this was an >error in RFC 3280. > >Dave > > > From owner-ietf-pkix@mail.imc.org Thu Feb 27 23:20:04 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02947 for ; Thu, 27 Feb 2003 23:20:04 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S3vEg17567 for ietf-pkix-bks; Thu, 27 Feb 2003 19:57:14 -0800 (PST) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S3vAY17562 for ; Thu, 27 Feb 2003 19:57:10 -0800 (PST) Received: from chokhani (149.washington-15rh15rt.dc.dial-access.att.net[12.91.132.149]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003022803570711300n4lufe>; Fri, 28 Feb 2003 03:57:07 +0000 From: "Santosh Chokhani" To: , Cc: Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 22:57:35 -0500 Message-ID: <004301c2dedd$87873900$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030228105055k-fujino@smtp.necst.nec.co.jp> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Kozo: Based on your comment, I have reviewed the path validation sections you cite in 3280. These sections seem to be correct to me. The first one is decrementing the counter. The second one is taking the low water mark of the pending constraint and the constraint imposed in the new certificate. I also think the order is correct, i.e., the pending counter should be decremented before taking the low water mark of the current state variable and the new constraint. Please tell me what part is wrong? -----Original Message----- From: k-fujino@pb.jp.nec.com [mailto:k-fujino@pb.jp.nec.com] Sent: Thursday, February 27, 2003 8:51 PM To: ietf-pkix@imc.org Cc: Santosh Chokhani; sharon.boeyen@entrust.com Subject: RE: SkipCerts Question [RFC3280] Santosh: According to the RFC3280, after decrementing explicit_policy, the value would be reset. Therefore if some changes are needed, the following also need to be changed. Thank you, Kozo ----- 6.1.4 Preparation for Certificate i+1 (h) If the issuer and subject names are not identical: (1) If explicit_policy is not 0, decrement explicit_policy by 1. (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: $B!!(B(1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. ----- -----Original Message----- From:"Santosh Chokhani" Date:Thu, 27 Feb 2003 15:55:59 -0500 Subject:RE: SkipCerts Question [RFC3280] > >David: > >As Sharon notes, the text in the description of the extension needs to >change. It will also nice to note that if skipCert < = 0 and >valid_policy_tree = null, there is policy failure. > >I will propose some changes to both sections. The first one in my mind >is a must (i.e., the description of the extension). The second one >(i.e., in the path validation) is to simply add clarity that other wise >path validation fails. I will propose some text later in response to >Sharon's e-mail. > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper >Sent: Thursday, February 27, 2003 11:21 AM >To: ietf-pkix@imc.org >Subject: Re: SkipCerts Question [RFC3280] > > > >Santosh Chokhani wrote: > >>I do not understand your first point. Are you saying that X.509 will >>be changed to align with 3280 and in that case skipCerts = 0 for >>requireExplicitPolicy will also take effect in the next certificate? >>Or, are you saying that the difference between 3280 and X.509 will >>remain? I assume you agree that I am reading 3280 correctly. >> >Santosh, > >X.509 and RFC 3280 both state that if a certificate includes >requireExplicitPolicy with skipCerts = 0, the constraint takes effect >immediately. > >In X.509, this can be seen in the following statements: > > >Clause 10.5.3: > For all certificates, the following actions are then performed: > > a) If explicit-policy-indicator is not set: > > If the requireExplicitPolicy constraint is present in the >certificate, perform the > following. For a SkipCerts value of 0, set the >explicit-policy-indicator. > >Clause 10.5.4: > For the end-certificate, the following actions are then performed: > > a) If explicit-policy-indicator is set, check that the >authorities-constrained-policy-set table is not empty. > (NOTE: As a result of DR 289, X.509 now requires that one also >check that the user-constrained-policy-set > is not empty). > > > >In RFC 3280: > >section 6.1.4 (processing of intermediate certificates): > > (i) If a policy constraints extension is included in the > certificate, modify the explicit_policy and policy_mapping state > variables as follows: > > (1) If requireExplicitPolicy is present and is less than > explicit_policy, set explicit_policy to the value of > requireExplicitPolicy. > >section 6.1.5 (wrap-up procedure): > > (b) If a policy constraints extension is included in the > certificate and requireExplicitPolicy is present and has a value > of 0, set the explicit_policy state variable to 0. > > If either (1) the value of explicit_policy variable is greater than > zero, or (2) the valid_policy_tree is not NULL, then path processing > has succeeded. > > > >So, in both cases, if requireExplicitPolicy is present with >SkipCerts=0, >even in the final certificate in the path, then the path will be >rejected unless it is valid under at least one user acceptable policy. > The two documents also agree on the processing requirements when >skipCerts > 0. > >When Sharon mentioned a new defect report against X.509, she was >referring to the text in clause 8.4.2.3 that describes the >policyConstraints extension. There was concern that this text was >somewhat ambiguous. The text in clause 10, which provides detailed, >step-by-step, processing requirements for the fields in the >policyConstraints extension will not be changed. > > >There is, however, one place in which X.509 and RFC 3280 diverge in the >processing of the requireExplicitPolicy field of policyConstraints. > >X.509 states in clause 10.5.3: > > if the explicit-policy-pending indicator is set and the certificate >is not a self-issued intermediate certificate, > decrement the corresponding skip-certificates value and, if this >value becomes zero, set explicit-policy-indicator. > >RFC 3280 states in section 6.1.5 (prcessing of the final certificate in >the path): > > (a) If certificate n was not self-issued and explicit_policy is > not 0, decrement explicit_policy by 1. > > >Thus, in X.509 a self-issued end certificate counts when determining >whether the path is long enough to "turn on" the constraint. In RFC >3280, a self-issued end certifcate does not count. > >Since, as a general rule, self-issued end certificates are treated the >same as certificates that are not self-issued, I believe this was an >error in RFC 3280. > >Dave > > > From owner-ietf-pkix@mail.imc.org Thu Feb 27 23:29:57 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03054 for ; Thu, 27 Feb 2003 23:29:57 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S4AMq17875 for ietf-pkix-bks; Thu, 27 Feb 2003 20:10:22 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S4ALY17871 for ; Thu, 27 Feb 2003 20:10:21 -0800 (PST) Received: from chokhani (149.washington-15rh15rt.dc.dial-access.att.net[12.91.132.149]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003022804101511200ig0o9e>; Fri, 28 Feb 2003 04:10:16 +0000 From: "Santosh Chokhani" To: "'Sharon Boeyen'" , "'n Russ Housley'" , "Tim Polk" Cc: , Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 23:10:44 -0500 Message-ID: <004901c2dedf$5e37be60$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <9A4F653B0A375841AC75A8D17712B9C9061ABFF3@sottmxs04.entrust.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1S4ALY17872 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Russ and Tim: I would propose the following changes. CHANGE 1 The sentence in 4.2.1.12 currently state: "If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. When an explicit policy is required, it is necessary for all certificates in the path to contain an acceptable policy identifier in the certificate policies extension. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping." I propose that we change it to: "If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of certificates (including this certificate) that may appear in the path before an explicit policy is required for the entire path. Thus, a value of skipCerts = 0 in any certificate in the path means that an explicit policy is required for the entire path. When an explicit policy is required, it is necessary for all certificates in the path to contain an acceptable policy identifier in the certificate policies extension. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping." CHANGE 2 At the end of Section 6.1.5, add "Otherwise, path processing has failed. CHANGE 3 skipCerts semantics is slightly different for requireExplicitPolicy field. Thus, a different variable name should be used for it. ACKNOWLEDGEMENT Many of the ideas here have come from Carl Wallace or discussions with him. All the credit should go to him. I will be glad to take any blame. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 11:02 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh and I did chat on the phone and worked through the processing steps in both 509 and 3280 for the example (see below). Both would have the same outcome for the path, however both Santosh and I believe the text in 3280 that describes the policyConstraints extension needs to be changed to align with both the 3280 path validation procedure and with 509 itself. Currently the text in 3280 clause 4.2.1.12 aligns with the pre DR 222 X.509 description, but the 3280 validation process aligns with the post DR 222 policy constraints. Santosh may propose some rewording for 4.2.1.12. Here is how X.509 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 10.5.3 sets the pending variable to 1 - when processing certificate 3 clause 10.5.3 decrements the pending variable to 0 and sets the explicit-policy-indicator flag on. Clause 10.5.3 and 10.5.4 perform the checks to satisfy the explicit-policy-indicator flag. Here is how RFC 3280 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 6.1.4 step i sets the pending variable to 1 - when processing certificate 2 clause 6.1.5 step a decrements the pending variable to 0. - the very last test conducted at the end of 6.1.5 (see paragraph immediately above 6.1.6) says that the path succeeds if explicit-policy is greater than zero. In this example explicit-policy has reached zero and therefore the path fails. Because X.509 requires only that an implementation be "functionally equivalent to the external behaviour resulting from this procedure" the RFC 3280 path validation algorithm is conformant because the external behaviour is the same. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Thursday, February 27, 2003 10:15 AM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: My reading is very simple. My reading is as follows and it applies in general and not just to the last certificate in chain or other esoteric stuff. 2000 edition of X.509 starts applying the skipCerts for requireExplicitPolicy to the certificate in which it is asserted. 3280 applies the skipCerts for requireExplicitPolicy to the next certificate. For example, in the example Kodo cited (and in a private e-mail he agreed with me), 3280 will not require explicit policy for the path and X.509 will. The reasons are articulated in this thread by me. I will call you to discuss this. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 10:05 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > From owner-ietf-pkix@mail.imc.org Fri Feb 28 00:23:26 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03938 for ; Fri, 28 Feb 2003 00:23:26 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S4wi519236 for ietf-pkix-bks; Thu, 27 Feb 2003 20:58:44 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S4wgY19232 for ; Thu, 27 Feb 2003 20:58:42 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1S4wYU03336; Fri, 28 Feb 2003 13:58:34 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1S4wX417373; Fri, 28 Feb 2003 13:58:33 +0900 (JST) Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.109.63.71]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h1S4wWH05882; Fri, 28 Feb 2003 13:58:32 +0900 (JST) Received: from smtp5.necst.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-02/23/03) with ESMTP id NAA02448; Fri, 28 Feb 2003 13:58:30 +0900 (JST) From: k-fujino@pb.jp.nec.com Received: by smtp5.necst.nec.co.jp id h1S4wUX23736 ; Fri, 28 Feb 2003 13:58:30 +0900 (JST) Received: from ecpc15 by smtp5.necst.nec.co.jp with SMTP id h1S4wTU23733 ; Fri, 28 Feb 2003 13:58:29 +0900 (JST) To: Santosh Chokhani , Cc: Subject: RE: SkipCerts Question [RFC3280] Reply-To: k-fujino@pb.jp.nec.com In-reply-to: <004301c2dedd$87873900$9900a8c0@Chokhani> References: <004301c2dedd$87873900$9900a8c0@Chokhani> Message-Id: <20030228135829k-fujino@smtp.necst.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.08D] ID:NECST0 Date: Fri, 28 Feb 2003 13:58:29 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit All: I'm very sorry. I found my misunderstanding. During the "Basic certificate Processing" (e) valid_policy_tree truns NULL. During the "Wrap-up" (a), the counter turns 0. So the path processing fails. Therefore the cert2 is required to have an explicit policy. cert0 cert1:requireExplicitPolicy=1 cert2 Thank you very much, Kozo -----Original Message----- From:"Santosh Chokhani" Date:Thu, 27 Feb 2003 22:57:35 -0500 Subject:RE: SkipCerts Question [RFC3280] >Kozo: > >Based on your comment, I have reviewed the path validation sections you cite >in 3280. These sections seem to be correct to me. The first one is >decrementing the counter. The second one is taking the low water mark of >the pending constraint and the constraint imposed in the new certificate. I >also think the order is correct, i.e., the pending counter should be >decremented before taking the low water mark of the current state variable >and the new constraint. > >Please tell me what part is wrong? > >-----Original Message----- >From: k-fujino@pb.jp.nec.com [mailto:k-fujino@pb.jp.nec.com] >Sent: Thursday, February 27, 2003 8:51 PM >To: ietf-pkix@imc.org >Cc: Santosh Chokhani; sharon.boeyen@entrust.com >Subject: RE: SkipCerts Question [RFC3280] > > >Santosh: > >According to the RFC3280, > after decrementing explicit_policy, > the value would be reset. > >Therefore if some changes are needed, >the following also need to be changed. > >Thank you, > Kozo > >----- >6.1.4 Preparation for Certificate i+1 > > > >(h) If the issuer and subject names are not identical: > > (1) If explicit_policy is not 0, decrement explicit_policy by 1. > > > >(i) If a policy constraints extension is included in the > certificate, modify the explicit_policy and policy_mapping state > variables as follows: > > $B!!(B(1) If requireExplicitPolicy is present and is less than > explicit_policy, set explicit_policy to the value of > requireExplicitPolicy. >----- > > >-----Original Message----- >From:"Santosh Chokhani" >Date:Thu, 27 Feb 2003 15:55:59 -0500 >Subject:RE: SkipCerts Question [RFC3280] >> >>David: >> >>As Sharon notes, the text in the description of the extension needs to >>change. It will also nice to note that if skipCert < = 0 and >>valid_policy_tree = null, there is policy failure. >> >>I will propose some changes to both sections. The first one in my mind >>is a must (i.e., the description of the extension). The second one >>(i.e., in the path validation) is to simply add clarity that other wise >>path validation fails. I will propose some text later in response to >>Sharon's e-mail. >> >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org >>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper >>Sent: Thursday, February 27, 2003 11:21 AM >>To: ietf-pkix@imc.org >>Subject: Re: SkipCerts Question [RFC3280] >> >> >> >>Santosh Chokhani wrote: >> >>>I do not understand your first point. Are you saying that X.509 will >>>be changed to align with 3280 and in that case skipCerts = 0 for >>>requireExplicitPolicy will also take effect in the next certificate? >>>Or, are you saying that the difference between 3280 and X.509 will >>>remain? I assume you agree that I am reading 3280 correctly. >>> >>Santosh, >> >>X.509 and RFC 3280 both state that if a certificate includes >>requireExplicitPolicy with skipCerts = 0, the constraint takes effect >>immediately. >> >>In X.509, this can be seen in the following statements: >> >> >>Clause 10.5.3: >> For all certificates, the following actions are then performed: >> >> a) If explicit-policy-indicator is not set: >> >> If the requireExplicitPolicy constraint is present in the >>certificate, perform the >> following. For a SkipCerts value of 0, set the >>explicit-policy-indicator. >> >>Clause 10.5.4: >> For the end-certificate, the following actions are then performed: >> >> a) If explicit-policy-indicator is set, check that the >>authorities-constrained-policy-set table is not empty. >> (NOTE: As a result of DR 289, X.509 now requires that one also >>check that the user-constrained-policy-set >> is not empty). >> >> >> >>In RFC 3280: >> >>section 6.1.4 (processing of intermediate certificates): >> >> (i) If a policy constraints extension is included in the >> certificate, modify the explicit_policy and policy_mapping state >> variables as follows: >> >> (1) If requireExplicitPolicy is present and is less than >> explicit_policy, set explicit_policy to the value of >> requireExplicitPolicy. >> >>section 6.1.5 (wrap-up procedure): >> >> (b) If a policy constraints extension is included in the >> certificate and requireExplicitPolicy is present and has a value >> of 0, set the explicit_policy state variable to 0. >> >> If either (1) the value of explicit_policy variable is greater than >> zero, or (2) the valid_policy_tree is not NULL, then path processing >> has succeeded. >> >> >> >>So, in both cases, if requireExplicitPolicy is present with >>SkipCerts=0, >>even in the final certificate in the path, then the path will be >>rejected unless it is valid under at least one user acceptable policy. >> The two documents also agree on the processing requirements when >>skipCerts > 0. >> >>When Sharon mentioned a new defect report against X.509, she was >>referring to the text in clause 8.4.2.3 that describes the >>policyConstraints extension. There was concern that this text was >>somewhat ambiguous. The text in clause 10, which provides detailed, >>step-by-step, processing requirements for the fields in the >>policyConstraints extension will not be changed. >> >> >>There is, however, one place in which X.509 and RFC 3280 diverge in the >>processing of the requireExplicitPolicy field of policyConstraints. >> >>X.509 states in clause 10.5.3: >> >> if the explicit-policy-pending indicator is set and the certificate >>is not a self-issued intermediate certificate, >> decrement the corresponding skip-certificates value and, if this >>value becomes zero, set explicit-policy-indicator. >> >>RFC 3280 states in section 6.1.5 (prcessing of the final certificate in >>the path): >> >> (a) If certificate n was not self-issued and explicit_policy is >> not 0, decrement explicit_policy by 1. >> >> >>Thus, in X.509 a self-issued end certificate counts when determining >>whether the path is long enough to "turn on" the constraint. In RFC >>3280, a self-issued end certifcate does not count. >> >>Since, as a general rule, self-issued end certificates are treated the >>same as certificates that are not self-issued, I believe this was an >>error in RFC 3280. >> >>Dave >> >> >> > From owner-ietf-pkix@mail.imc.org Fri Feb 28 11:48:56 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04411 for ; Fri, 28 Feb 2003 11:48:55 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SGCM822024 for ietf-pkix-bks; Fri, 28 Feb 2003 08:12:22 -0800 (PST) Received: from trinity.spray.se (trinity.spray.se [212.78.193.150]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SGCJY22016 for ; Fri, 28 Feb 2003 08:12:20 -0800 (PST) Received: from Laptop.spray.se (1Cust37.tnt15.stk3.swe.da.uu.net [213.116.222.37]) by trinity.spray.se (Postfix) with ESMTP id A72EF82F92F for ; Fri, 28 Feb 2003 17:12:09 +0100 (MET) Message-Id: <5.2.0.9.0.20030228164148.03449a30@pop.spray.se> X-Sender: stefan.retrospekt@spray.se@pop.spray.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 17:11:35 +0100 To: From: Stefan Santesson Subject: Son of RFC 3039 draft available In-Reply-To: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> References: <3E5E3AF5.20707@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, It seams that I mixed up the cut-off dates for Internet drafts submission and submitted the 00 draft on son of RFC 3039 (Qualified Certificates Profile) to late. So I do the second best thing and make the draft available from my own web site until it hits the PKIX charter page. You can get the preliminary draft from: http://216.219.254.34/retrospekt.com/pages/2/index.htm The only changes from RFC 3039 is: - Clarification of scope - Title attribute is moved from subjectDirectoryAttribute to the Subject field - Requirement to set non-repudiation exclusively if set is removed as a SHOULD requirement and left to local profiling. - Old references to RFC 2459 are updated to RFC 3280 The intention so far is to limit changes to editorial changes. The rationale behind these updates are: 1) Clarification of scope There are numerous if implementations that use RFC 3039 without issuing the certificates as Qualified Certificates. Especially the conventions regarding use of attributes in the subject field are of general value. The clarification of scope express more clearly than before that this standard can be used for any ID-certificate issued to humans and further includes mechanisms related to Qualified Certificates. This was true also with RFC 3039 but not so clearly expressed. 2) Title attribute Suggesting that this attribute should be placed in subject Directory attributes was a bad choice that no implementation that I know of has followed. Likewise, many applications that need to use the title attribute do not support use of subjectDirectoryAttributes. Use of the title attribute is common and use of subjectDirectoryAttributes is rare: This is a bad mix. 3) Non-repudiation. This change does not make any contribution to the meaning of this key usage declaration, but it suggest that this profile is the wrong place to have any opinion on whether this key usage bit should be set exclusively or not. The draft suggest that national legislation and local policies have to decide this as long as the meaning of the bits are consistent with RFC 3280. It should also be noted that Tim and Magnus has agreed to co-edit this document but they have not yet had the time to fully review this first draft so don't hit on them yet for things you don't like. Any comments and suggestions are welcome I'll be in San Francisco as well. /Stefan From owner-ietf-pkix@mail.imc.org Fri Feb 28 13:18:24 2003 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07969 for ; Fri, 28 Feb 2003 13:18:23 -0500 (EST) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SHl0D25822 for ietf-pkix-bks; Fri, 28 Feb 2003 09:47:00 -0800 (PST) Received: from amatabogados.com ([213.229.156.25]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1SHkwY25817 for ; Fri, 28 Feb 2003 09:46:58 -0800 (PST) Received: from host [80.26.116.141] by amatabogados.com (SMTPD32-4.07) id A12AA9B00DC; Fri, 28 Feb 2003 18:49:30 +0100 Message-ID: <001301c2df51$25125a60$0200a8c0@host> From: "Pere Fiol" To: "Ricardo Barroso" Cc: References: <3E5E3426.7070803@bull.net> <3E5E5627.6080405@multicert.com> Subject: Re: RFC 3161 Interoperability Site Date: Fri, 28 Feb 2003 18:45:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C2DF59.864753A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2DF59.864753A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I also have a TSA server and I'm very interesred in pass the = interoperability test ... my server is on tsa.semarket.com:318 (it's a = TCP service) ...and all the information about it is on = http://tsa.semarket.com Regards, Pere Fiol ----- Original Message -----=20 From: Ricardo Barroso=20 To: Denis Pinkas=20 Cc: Robert Zuccherato ; IETF-PKIX@imc.org=20 Sent: Thursday, February 27, 2003 7:17 PM Subject: Re: RFC 3161 Interoperability Site Hello! Denis, since we wan't to start soon our interoperability tests,=20 can you please send me that interoperability test matrix? Thanks in advance,=20 Ricardo Barroso MULTICERT S.A. Denis Pinkas wrote: Robert,=20 Thank you for posting this message.=20 However no implementation can yet claim to be "RFC 3161 compliant" = since no interoperability test has been performed up to now.=20 An interoperability test matrix has been sent to different people = (in fact all people I have been aware of) that have announced to support = the Time-Stamp Protocol from the IETF, but two companies (with = independent implementations) still need to fill-in the matrix so that we = can progress RFC 3161 to Proposed Standard.=20 The only "difficult" part is to test the error cases in both = directions.=20 Denis=20 Entrust would like to announce that we have made available an RFC = 3161 compliant TSA for interoperability test purposes. It is accessible = at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp = and supports the HTTP protocol as specified in RFC 3161. The CA = certificate required to verify the TSA certificate is available in Base = 64 format at = http://vsinterop.entrust.com:7001/verificationserver/ca.cer.=20 The site is for interoperability testing of the RFC 3161 HTTP = protocol only and is not guaranteed to be operational 24/7. If anyone = has any questions or any problems arise with the site, please direct = them to vsinterop-support@entrust.com.=20 Robert Zuccherato=20 ------=_NextPart_000_0010_01C2DF59.864753A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I also have a TSA server and I'm very = interesred in=20 pass the interoperability test ... my server is on tsa.semarket.com:318 = (it's a=20 TCP service) ...and all the information about it is on http://tsa.semarket.com
=
 
Regards,
Pere Fiol
----- Original Message -----
From:=20 Ricardo Barroso =
Cc: Robert Zuccherato ; = IETF-PKIX@imc.org=20
Sent: Thursday, February 27, = 2003 7:17=20 PM
Subject: Re: RFC 3161 = Interoperability=20 Site

Hello!

Denis, since we wan't to start soon our=20 interoperability tests,
can you please send me that = interoperability test=20 matrix?

Thanks in advance,
Ricardo Barroso
MULTICERT S.A.


Denis = Pinkas=20 wrote:

Robert,=20

Thank you for posting this message.

However no=20 implementation can yet claim to be "RFC 3161 compliant" since no=20 interoperability test has been performed up to now.

An=20 interoperability test matrix has been sent to different people (in = fact all=20 people I have been aware of) that have announced to support the = Time-Stamp=20 Protocol from the IETF, but two companies (with independent = implementations)=20 still need to fill-in the matrix so that we can progress RFC 3161 to = Proposed Standard.

The only "difficult" part is to test the = error=20 cases in both directions.

Denis

Entrust would like to announce that we = have made=20 available an RFC 3161 compliant TSA for interoperability test=20 purposes.  It is accessible at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timesta= mp=20 and supports the HTTP protocol as specified in RFC 3161.  The = CA=20 certificate required to verify the TSA certificate is available in = Base 64=20 format at http= ://vsinterop.entrust.com:7001/verificationserver/ca.cer.=20
The site is for interoperability testing of the RFC 3161 HTTP = protocol=20 only and is not guaranteed to be operational 24/7.  If anyone = has any=20 questions or any problems arise with the site, please direct them = to vsinterop-support@entrust.c= om.=20


        Robert = Zuccherato=20 =




= ------=_NextPart_000_0010_01C2DF59.864753A0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SHl0D25822 for ietf-pkix-bks; Fri, 28 Feb 2003 09:47:00 -0800 (PST) Received: from amatabogados.com ([213.229.156.25]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1SHkwY25817 for ; Fri, 28 Feb 2003 09:46:58 -0800 (PST) Received: from host [80.26.116.141] by amatabogados.com (SMTPD32-4.07) id A12AA9B00DC; Fri, 28 Feb 2003 18:49:30 +0100 Message-ID: <001301c2df51$25125a60$0200a8c0@host> From: "Pere Fiol" To: "Ricardo Barroso" Cc: References: <3E5E3426.7070803@bull.net> <3E5E5627.6080405@multicert.com> Subject: Re: RFC 3161 Interoperability Site Date: Fri, 28 Feb 2003 18:45:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C2DF59.864753A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C2DF59.864753A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I also have a TSA server and I'm very interesred in pass the = interoperability test ... my server is on tsa.semarket.com:318 (it's a = TCP service) ...and all the information about it is on = http://tsa.semarket.com Regards, Pere Fiol ----- Original Message -----=20 From: Ricardo Barroso=20 To: Denis Pinkas=20 Cc: Robert Zuccherato ; IETF-PKIX@imc.org=20 Sent: Thursday, February 27, 2003 7:17 PM Subject: Re: RFC 3161 Interoperability Site Hello! Denis, since we wan't to start soon our interoperability tests,=20 can you please send me that interoperability test matrix? Thanks in advance,=20 Ricardo Barroso MULTICERT S.A. Denis Pinkas wrote: Robert,=20 Thank you for posting this message.=20 However no implementation can yet claim to be "RFC 3161 compliant" = since no interoperability test has been performed up to now.=20 An interoperability test matrix has been sent to different people = (in fact all people I have been aware of) that have announced to support = the Time-Stamp Protocol from the IETF, but two companies (with = independent implementations) still need to fill-in the matrix so that we = can progress RFC 3161 to Proposed Standard.=20 The only "difficult" part is to test the error cases in both = directions.=20 Denis=20 Entrust would like to announce that we have made available an RFC = 3161 compliant TSA for interoperability test purposes. It is accessible = at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp = and supports the HTTP protocol as specified in RFC 3161. The CA = certificate required to verify the TSA certificate is available in Base = 64 format at = http://vsinterop.entrust.com:7001/verificationserver/ca.cer.=20 The site is for interoperability testing of the RFC 3161 HTTP = protocol only and is not guaranteed to be operational 24/7. If anyone = has any questions or any problems arise with the site, please direct = them to vsinterop-support@entrust.com.=20 Robert Zuccherato=20 ------=_NextPart_000_0010_01C2DF59.864753A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I also have a TSA server and I'm very = interesred in=20 pass the interoperability test ... my server is on tsa.semarket.com:318 = (it's a=20 TCP service) ...and all the information about it is on http://tsa.semarket.com
=
 
Regards,
Pere Fiol
----- Original Message -----
From:=20 Ricardo Barroso =
Cc: Robert Zuccherato ; = IETF-PKIX@imc.org=20
Sent: Thursday, February 27, = 2003 7:17=20 PM
Subject: Re: RFC 3161 = Interoperability=20 Site

Hello!

Denis, since we wan't to start soon our=20 interoperability tests,
can you please send me that = interoperability test=20 matrix?

Thanks in advance,
Ricardo Barroso
MULTICERT S.A.


Denis = Pinkas=20 wrote:

Robert,=20

Thank you for posting this message.

However no=20 implementation can yet claim to be "RFC 3161 compliant" since no=20 interoperability test has been performed up to now.

An=20 interoperability test matrix has been sent to different people (in = fact all=20 people I have been aware of) that have announced to support the = Time-Stamp=20 Protocol from the IETF, but two companies (with independent = implementations)=20 still need to fill-in the matrix so that we can progress RFC 3161 to = Proposed Standard.

The only "difficult" part is to test the = error=20 cases in both directions.

Denis

Entrust would like to announce that we = have made=20 available an RFC 3161 compliant TSA for interoperability test=20 purposes.  It is accessible at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timesta= mp=20 and supports the HTTP protocol as specified in RFC 3161.  The = CA=20 certificate required to verify the TSA certificate is available in = Base 64=20 format at http= ://vsinterop.entrust.com:7001/verificationserver/ca.cer.=20
The site is for interoperability testing of the RFC 3161 HTTP = protocol=20 only and is not guaranteed to be operational 24/7.  If anyone = has any=20 questions or any problems arise with the site, please direct them = to vsinterop-support@entrust.c= om.=20


        Robert = Zuccherato=20 =




= ------=_NextPart_000_0010_01C2DF59.864753A0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1SGCM822024 for ietf-pkix-bks; Fri, 28 Feb 2003 08:12:22 -0800 (PST) Received: from trinity.spray.se (trinity.spray.se [212.78.193.150]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1SGCJY22016 for ; Fri, 28 Feb 2003 08:12:20 -0800 (PST) Received: from Laptop.spray.se (1Cust37.tnt15.stk3.swe.da.uu.net [213.116.222.37]) by trinity.spray.se (Postfix) with ESMTP id A72EF82F92F for ; Fri, 28 Feb 2003 17:12:09 +0100 (MET) Message-Id: <5.2.0.9.0.20030228164148.03449a30@pop.spray.se> X-Sender: stefan.retrospekt@spray.se@pop.spray.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 28 Feb 2003 17:11:35 +0100 To: From: Stefan Santesson Subject: Son of RFC 3039 draft available In-Reply-To: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> References: <3E5E3AF5.20707@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, It seams that I mixed up the cut-off dates for Internet drafts submission and submitted the 00 draft on son of RFC 3039 (Qualified Certificates Profile) to late. So I do the second best thing and make the draft available from my own web site until it hits the PKIX charter page. You can get the preliminary draft from: http://216.219.254.34/retrospekt.com/pages/2/index.htm The only changes from RFC 3039 is: - Clarification of scope - Title attribute is moved from subjectDirectoryAttribute to the Subject field - Requirement to set non-repudiation exclusively if set is removed as a SHOULD requirement and left to local profiling. - Old references to RFC 2459 are updated to RFC 3280 The intention so far is to limit changes to editorial changes. The rationale behind these updates are: 1) Clarification of scope There are numerous if implementations that use RFC 3039 without issuing the certificates as Qualified Certificates. Especially the conventions regarding use of attributes in the subject field are of general value. The clarification of scope express more clearly than before that this standard can be used for any ID-certificate issued to humans and further includes mechanisms related to Qualified Certificates. This was true also with RFC 3039 but not so clearly expressed. 2) Title attribute Suggesting that this attribute should be placed in subject Directory attributes was a bad choice that no implementation that I know of has followed. Likewise, many applications that need to use the title attribute do not support use of subjectDirectoryAttributes. Use of the title attribute is common and use of subjectDirectoryAttributes is rare: This is a bad mix. 3) Non-repudiation. This change does not make any contribution to the meaning of this key usage declaration, but it suggest that this profile is the wrong place to have any opinion on whether this key usage bit should be set exclusively or not. The draft suggest that national legislation and local policies have to decide this as long as the meaning of the bits are consistent with RFC 3280. It should also be noted that Tim and Magnus has agreed to co-edit this document but they have not yet had the time to fully review this first draft so don't hit on them yet for things you don't like. Any comments and suggestions are welcome I'll be in San Francisco as well. /Stefan Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S4wi519236 for ietf-pkix-bks; Thu, 27 Feb 2003 20:58:44 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S4wgY19232 for ; Thu, 27 Feb 2003 20:58:42 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1S4wYU03336; Fri, 28 Feb 2003 13:58:34 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1S4wX417373; Fri, 28 Feb 2003 13:58:33 +0900 (JST) Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.109.63.71]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h1S4wWH05882; Fri, 28 Feb 2003 13:58:32 +0900 (JST) Received: from smtp5.necst.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-02/23/03) with ESMTP id NAA02448; Fri, 28 Feb 2003 13:58:30 +0900 (JST) From: k-fujino@pb.jp.nec.com Received: by smtp5.necst.nec.co.jp id h1S4wUX23736 ; Fri, 28 Feb 2003 13:58:30 +0900 (JST) Received: from ecpc15 by smtp5.necst.nec.co.jp with SMTP id h1S4wTU23733 ; Fri, 28 Feb 2003 13:58:29 +0900 (JST) To: Santosh Chokhani , Cc: Subject: RE: SkipCerts Question [RFC3280] Reply-To: k-fujino@pb.jp.nec.com In-reply-to: <004301c2dedd$87873900$9900a8c0@Chokhani> References: <004301c2dedd$87873900$9900a8c0@Chokhani> Message-Id: <20030228135829k-fujino@smtp.necst.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.08D] ID:NECST0 Date: Fri, 28 Feb 2003 13:58:29 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All: I'm very sorry. I found my misunderstanding. During the "Basic certificate Processing" (e) valid_policy_tree truns NULL. During the "Wrap-up" (a), the counter turns 0. So the path processing fails. Therefore the cert2 is required to have an explicit policy. cert0 cert1:requireExplicitPolicy=1 cert2 Thank you very much, Kozo -----Original Message----- From:"Santosh Chokhani" Date:Thu, 27 Feb 2003 22:57:35 -0500 Subject:RE: SkipCerts Question [RFC3280] >Kozo: > >Based on your comment, I have reviewed the path validation sections you cite >in 3280. These sections seem to be correct to me. The first one is >decrementing the counter. The second one is taking the low water mark of >the pending constraint and the constraint imposed in the new certificate. I >also think the order is correct, i.e., the pending counter should be >decremented before taking the low water mark of the current state variable >and the new constraint. > >Please tell me what part is wrong? > >-----Original Message----- >From: k-fujino@pb.jp.nec.com [mailto:k-fujino@pb.jp.nec.com] >Sent: Thursday, February 27, 2003 8:51 PM >To: ietf-pkix@imc.org >Cc: Santosh Chokhani; sharon.boeyen@entrust.com >Subject: RE: SkipCerts Question [RFC3280] > > >Santosh: > >According to the RFC3280, > after decrementing explicit_policy, > the value would be reset. > >Therefore if some changes are needed, >the following also need to be changed. > >Thank you, > Kozo > >----- >6.1.4 Preparation for Certificate i+1 > > > >(h) If the issuer and subject names are not identical: > > (1) If explicit_policy is not 0, decrement explicit_policy by 1. > > > >(i) If a policy constraints extension is included in the > certificate, modify the explicit_policy and policy_mapping state > variables as follows: > > $B!!(B(1) If requireExplicitPolicy is present and is less than > explicit_policy, set explicit_policy to the value of > requireExplicitPolicy. >----- > > >-----Original Message----- >From:"Santosh Chokhani" >Date:Thu, 27 Feb 2003 15:55:59 -0500 >Subject:RE: SkipCerts Question [RFC3280] >> >>David: >> >>As Sharon notes, the text in the description of the extension needs to >>change. It will also nice to note that if skipCert < = 0 and >>valid_policy_tree = null, there is policy failure. >> >>I will propose some changes to both sections. The first one in my mind >>is a must (i.e., the description of the extension). The second one >>(i.e., in the path validation) is to simply add clarity that other wise >>path validation fails. I will propose some text later in response to >>Sharon's e-mail. >> >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org >>[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper >>Sent: Thursday, February 27, 2003 11:21 AM >>To: ietf-pkix@imc.org >>Subject: Re: SkipCerts Question [RFC3280] >> >> >> >>Santosh Chokhani wrote: >> >>>I do not understand your first point. Are you saying that X.509 will >>>be changed to align with 3280 and in that case skipCerts = 0 for >>>requireExplicitPolicy will also take effect in the next certificate? >>>Or, are you saying that the difference between 3280 and X.509 will >>>remain? I assume you agree that I am reading 3280 correctly. >>> >>Santosh, >> >>X.509 and RFC 3280 both state that if a certificate includes >>requireExplicitPolicy with skipCerts = 0, the constraint takes effect >>immediately. >> >>In X.509, this can be seen in the following statements: >> >> >>Clause 10.5.3: >> For all certificates, the following actions are then performed: >> >> a) If explicit-policy-indicator is not set: >> >> If the requireExplicitPolicy constraint is present in the >>certificate, perform the >> following. For a SkipCerts value of 0, set the >>explicit-policy-indicator. >> >>Clause 10.5.4: >> For the end-certificate, the following actions are then performed: >> >> a) If explicit-policy-indicator is set, check that the >>authorities-constrained-policy-set table is not empty. >> (NOTE: As a result of DR 289, X.509 now requires that one also >>check that the user-constrained-policy-set >> is not empty). >> >> >> >>In RFC 3280: >> >>section 6.1.4 (processing of intermediate certificates): >> >> (i) If a policy constraints extension is included in the >> certificate, modify the explicit_policy and policy_mapping state >> variables as follows: >> >> (1) If requireExplicitPolicy is present and is less than >> explicit_policy, set explicit_policy to the value of >> requireExplicitPolicy. >> >>section 6.1.5 (wrap-up procedure): >> >> (b) If a policy constraints extension is included in the >> certificate and requireExplicitPolicy is present and has a value >> of 0, set the explicit_policy state variable to 0. >> >> If either (1) the value of explicit_policy variable is greater than >> zero, or (2) the valid_policy_tree is not NULL, then path processing >> has succeeded. >> >> >> >>So, in both cases, if requireExplicitPolicy is present with >>SkipCerts=0, >>even in the final certificate in the path, then the path will be >>rejected unless it is valid under at least one user acceptable policy. >> The two documents also agree on the processing requirements when >>skipCerts > 0. >> >>When Sharon mentioned a new defect report against X.509, she was >>referring to the text in clause 8.4.2.3 that describes the >>policyConstraints extension. There was concern that this text was >>somewhat ambiguous. The text in clause 10, which provides detailed, >>step-by-step, processing requirements for the fields in the >>policyConstraints extension will not be changed. >> >> >>There is, however, one place in which X.509 and RFC 3280 diverge in the >>processing of the requireExplicitPolicy field of policyConstraints. >> >>X.509 states in clause 10.5.3: >> >> if the explicit-policy-pending indicator is set and the certificate >>is not a self-issued intermediate certificate, >> decrement the corresponding skip-certificates value and, if this >>value becomes zero, set explicit-policy-indicator. >> >>RFC 3280 states in section 6.1.5 (prcessing of the final certificate in >>the path): >> >> (a) If certificate n was not self-issued and explicit_policy is >> not 0, decrement explicit_policy by 1. >> >> >>Thus, in X.509 a self-issued end certificate counts when determining >>whether the path is long enough to "turn on" the constraint. In RFC >>3280, a self-issued end certifcate does not count. >> >>Since, as a general rule, self-issued end certificates are treated the >>same as certificates that are not self-issued, I believe this was an >>error in RFC 3280. >> >>Dave >> >> >> > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S4AMq17875 for ietf-pkix-bks; Thu, 27 Feb 2003 20:10:22 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S4ALY17871 for ; Thu, 27 Feb 2003 20:10:21 -0800 (PST) Received: from chokhani (149.washington-15rh15rt.dc.dial-access.att.net[12.91.132.149]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003022804101511200ig0o9e>; Fri, 28 Feb 2003 04:10:16 +0000 From: "Santosh Chokhani" To: "'Sharon Boeyen'" , "'n Russ Housley'" , "Tim Polk" Cc: , Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 23:10:44 -0500 Message-ID: <004901c2dedf$5e37be60$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <9A4F653B0A375841AC75A8D17712B9C9061ABFF3@sottmxs04.entrust.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1S4ALY17872 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ and Tim: I would propose the following changes. CHANGE 1 The sentence in 4.2.1.12 currently state: "If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. When an explicit policy is required, it is necessary for all certificates in the path to contain an acceptable policy identifier in the certificate policies extension. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping." I propose that we change it to: "If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of certificates (including this certificate) that may appear in the path before an explicit policy is required for the entire path. Thus, a value of skipCerts = 0 in any certificate in the path means that an explicit policy is required for the entire path. When an explicit policy is required, it is necessary for all certificates in the path to contain an acceptable policy identifier in the certificate policies extension. An acceptable policy identifier is the identifier of a policy required by the user of the certification path or the identifier of a policy which has been declared equivalent through policy mapping." CHANGE 2 At the end of Section 6.1.5, add "Otherwise, path processing has failed. CHANGE 3 skipCerts semantics is slightly different for requireExplicitPolicy field. Thus, a different variable name should be used for it. ACKNOWLEDGEMENT Many of the ideas here have come from Carl Wallace or discussions with him. All the credit should go to him. I will be glad to take any blame. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 11:02 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh and I did chat on the phone and worked through the processing steps in both 509 and 3280 for the example (see below). Both would have the same outcome for the path, however both Santosh and I believe the text in 3280 that describes the policyConstraints extension needs to be changed to align with both the 3280 path validation procedure and with 509 itself. Currently the text in 3280 clause 4.2.1.12 aligns with the pre DR 222 X.509 description, but the 3280 validation process aligns with the post DR 222 policy constraints. Santosh may propose some rewording for 4.2.1.12. Here is how X.509 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 10.5.3 sets the pending variable to 1 - when processing certificate 3 clause 10.5.3 decrements the pending variable to 0 and sets the explicit-policy-indicator flag on. Clause 10.5.3 and 10.5.4 perform the checks to satisfy the explicit-policy-indicator flag. Here is how RFC 3280 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 6.1.4 step i sets the pending variable to 1 - when processing certificate 2 clause 6.1.5 step a decrements the pending variable to 0. - the very last test conducted at the end of 6.1.5 (see paragraph immediately above 6.1.6) says that the path succeeds if explicit-policy is greater than zero. In this example explicit-policy has reached zero and therefore the path fails. Because X.509 requires only that an implementation be "functionally equivalent to the external behaviour resulting from this procedure" the RFC 3280 path validation algorithm is conformant because the external behaviour is the same. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Thursday, February 27, 2003 10:15 AM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: My reading is very simple. My reading is as follows and it applies in general and not just to the last certificate in chain or other esoteric stuff. 2000 edition of X.509 starts applying the skipCerts for requireExplicitPolicy to the certificate in which it is asserted. 3280 applies the skipCerts for requireExplicitPolicy to the next certificate. For example, in the example Kodo cited (and in a private e-mail he agreed with me), 3280 will not require explicit policy for the path and X.509 will. The reasons are articulated in this thread by me. I will call you to discuss this. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 10:05 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S3vEg17567 for ietf-pkix-bks; Thu, 27 Feb 2003 19:57:14 -0800 (PST) Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S3vAY17562 for ; Thu, 27 Feb 2003 19:57:10 -0800 (PST) Received: from chokhani (149.washington-15rh15rt.dc.dial-access.att.net[12.91.132.149]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003022803570711300n4lufe>; Fri, 28 Feb 2003 03:57:07 +0000 From: "Santosh Chokhani" To: , Cc: Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 22:57:35 -0500 Message-ID: <004301c2dedd$87873900$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030228105055k-fujino@smtp.necst.nec.co.jp> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kozo: Based on your comment, I have reviewed the path validation sections you cite in 3280. These sections seem to be correct to me. The first one is decrementing the counter. The second one is taking the low water mark of the pending constraint and the constraint imposed in the new certificate. I also think the order is correct, i.e., the pending counter should be decremented before taking the low water mark of the current state variable and the new constraint. Please tell me what part is wrong? -----Original Message----- From: k-fujino@pb.jp.nec.com [mailto:k-fujino@pb.jp.nec.com] Sent: Thursday, February 27, 2003 8:51 PM To: ietf-pkix@imc.org Cc: Santosh Chokhani; sharon.boeyen@entrust.com Subject: RE: SkipCerts Question [RFC3280] Santosh: According to the RFC3280, after decrementing explicit_policy, the value would be reset. Therefore if some changes are needed, the following also need to be changed. Thank you, Kozo ----- 6.1.4 Preparation for Certificate i+1 (h) If the issuer and subject names are not identical: (1) If explicit_policy is not 0, decrement explicit_policy by 1. (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: $B!!(B(1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. ----- -----Original Message----- From:"Santosh Chokhani" Date:Thu, 27 Feb 2003 15:55:59 -0500 Subject:RE: SkipCerts Question [RFC3280] > >David: > >As Sharon notes, the text in the description of the extension needs to >change. It will also nice to note that if skipCert < = 0 and >valid_policy_tree = null, there is policy failure. > >I will propose some changes to both sections. The first one in my mind >is a must (i.e., the description of the extension). The second one >(i.e., in the path validation) is to simply add clarity that other wise >path validation fails. I will propose some text later in response to >Sharon's e-mail. > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org >[mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper >Sent: Thursday, February 27, 2003 11:21 AM >To: ietf-pkix@imc.org >Subject: Re: SkipCerts Question [RFC3280] > > > >Santosh Chokhani wrote: > >>I do not understand your first point. Are you saying that X.509 will >>be changed to align with 3280 and in that case skipCerts = 0 for >>requireExplicitPolicy will also take effect in the next certificate? >>Or, are you saying that the difference between 3280 and X.509 will >>remain? I assume you agree that I am reading 3280 correctly. >> >Santosh, > >X.509 and RFC 3280 both state that if a certificate includes >requireExplicitPolicy with skipCerts = 0, the constraint takes effect >immediately. > >In X.509, this can be seen in the following statements: > > >Clause 10.5.3: > For all certificates, the following actions are then performed: > > a) If explicit-policy-indicator is not set: > > If the requireExplicitPolicy constraint is present in the >certificate, perform the > following. For a SkipCerts value of 0, set the >explicit-policy-indicator. > >Clause 10.5.4: > For the end-certificate, the following actions are then performed: > > a) If explicit-policy-indicator is set, check that the >authorities-constrained-policy-set table is not empty. > (NOTE: As a result of DR 289, X.509 now requires that one also >check that the user-constrained-policy-set > is not empty). > > > >In RFC 3280: > >section 6.1.4 (processing of intermediate certificates): > > (i) If a policy constraints extension is included in the > certificate, modify the explicit_policy and policy_mapping state > variables as follows: > > (1) If requireExplicitPolicy is present and is less than > explicit_policy, set explicit_policy to the value of > requireExplicitPolicy. > >section 6.1.5 (wrap-up procedure): > > (b) If a policy constraints extension is included in the > certificate and requireExplicitPolicy is present and has a value > of 0, set the explicit_policy state variable to 0. > > If either (1) the value of explicit_policy variable is greater than > zero, or (2) the valid_policy_tree is not NULL, then path processing > has succeeded. > > > >So, in both cases, if requireExplicitPolicy is present with >SkipCerts=0, >even in the final certificate in the path, then the path will be >rejected unless it is valid under at least one user acceptable policy. > The two documents also agree on the processing requirements when >skipCerts > 0. > >When Sharon mentioned a new defect report against X.509, she was >referring to the text in clause 8.4.2.3 that describes the >policyConstraints extension. There was concern that this text was >somewhat ambiguous. The text in clause 10, which provides detailed, >step-by-step, processing requirements for the fields in the >policyConstraints extension will not be changed. > > >There is, however, one place in which X.509 and RFC 3280 diverge in the >processing of the requireExplicitPolicy field of policyConstraints. > >X.509 states in clause 10.5.3: > > if the explicit-policy-pending indicator is set and the certificate >is not a self-issued intermediate certificate, > decrement the corresponding skip-certificates value and, if this >value becomes zero, set explicit-policy-indicator. > >RFC 3280 states in section 6.1.5 (prcessing of the final certificate in >the path): > > (a) If certificate n was not self-issued and explicit_policy is > not 0, decrement explicit_policy by 1. > > >Thus, in X.509 a self-issued end certificate counts when determining >whether the path is long enough to "turn on" the constraint. In RFC >3280, a self-issued end certifcate does not count. > >Since, as a general rule, self-issued end certificates are treated the >same as certificates that are not self-issued, I believe this was an >error in RFC 3280. > >Dave > > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1S2ARe14231 for ietf-pkix-bks; Thu, 27 Feb 2003 18:10:27 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1S2APY14227 for ; Thu, 27 Feb 2003 18:10:25 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1S2AIU06697; Fri, 28 Feb 2003 11:10:18 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1S2AHk25380; Fri, 28 Feb 2003 11:10:17 +0900 (JST) Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.109.63.71]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h1S29wH25647; Fri, 28 Feb 2003 11:10:16 +0900 (JST) Received: from smtp5.necst.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-02/23/03) with ESMTP id LAA14843; Fri, 28 Feb 2003 11:09:56 +0900 (JST) From: k-fujino@pb.jp.nec.com Received: by smtp5.necst.nec.co.jp id h1S1owu16303 ; Fri, 28 Feb 2003 10:50:58 +0900 (JST) Received: from ecpc15 by smtp5.necst.nec.co.jp with SMTP id h1S1ouU16300 ; Fri, 28 Feb 2003 10:50:56 +0900 (JST) To: Cc: Santosh Chokhani , sharon.boeyen@entrust.com Reply-To: k-fujino@pb.jp.nec.com Subject: RE: SkipCerts Question [RFC3280] In-reply-to: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> Message-Id: <20030228105055k-fujino@smtp.necst.nec.co.jp> References: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> Mime-Version: 1.0 X-Mailer: WeMail32[2.08D] ID:NECST0 Date: Fri, 28 Feb 2003 10:50:55 +0900 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh: According to the RFC3280, after decrementing explicit_policy, the value would be reset. Therefore if some changes are needed, the following also need to be changed. Thank you, Kozo ----- 6.1.4 Preparation for Certificate i+1 (h) If the issuer and subject names are not identical: (1) If explicit_policy is not 0, decrement explicit_policy by 1. (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: $B!!(B(1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. ----- -----Original Message----- From:"Santosh Chokhani" Date:Thu, 27 Feb 2003 15:55:59 -0500 Subject:RE: SkipCerts Question [RFC3280] > >David: > >As Sharon notes, the text in the description of the extension needs to >change. It will also nice to note that if skipCert < = 0 and >valid_policy_tree = null, there is policy failure. > >I will propose some changes to both sections. The first one in my mind is a >must (i.e., the description of the extension). The second one (i.e., in the >path validation) is to simply add clarity that other wise path validation >fails. I will propose some text later in response to Sharon's e-mail. > >-----Original Message----- >From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On >Behalf Of David A. Cooper >Sent: Thursday, February 27, 2003 11:21 AM >To: ietf-pkix@imc.org >Subject: Re: SkipCerts Question [RFC3280] > > > >Santosh Chokhani wrote: > >>I do not understand your first point. Are you saying that X.509 will >>be changed to align with 3280 and in that case skipCerts = 0 for >>requireExplicitPolicy will also take effect in the next certificate? >>Or, are you saying that the difference between 3280 and X.509 will >>remain? I assume you agree that I am reading 3280 correctly. >> >Santosh, > >X.509 and RFC 3280 both state that if a certificate includes >requireExplicitPolicy with skipCerts = 0, the constraint takes effect >immediately. > >In X.509, this can be seen in the following statements: > > >Clause 10.5.3: > For all certificates, the following actions are then performed: > > a) If explicit-policy-indicator is not set: > > If the requireExplicitPolicy constraint is present in the >certificate, perform the > following. For a SkipCerts value of 0, set the >explicit-policy-indicator. > >Clause 10.5.4: > For the end-certificate, the following actions are then performed: > > a) If explicit-policy-indicator is set, check that the >authorities-constrained-policy-set table is not empty. > (NOTE: As a result of DR 289, X.509 now requires that one also >check that the user-constrained-policy-set > is not empty). > > > >In RFC 3280: > >section 6.1.4 (processing of intermediate certificates): > > (i) If a policy constraints extension is included in the > certificate, modify the explicit_policy and policy_mapping state > variables as follows: > > (1) If requireExplicitPolicy is present and is less than > explicit_policy, set explicit_policy to the value of > requireExplicitPolicy. > >section 6.1.5 (wrap-up procedure): > > (b) If a policy constraints extension is included in the > certificate and requireExplicitPolicy is present and has a value > of 0, set the explicit_policy state variable to 0. > > If either (1) the value of explicit_policy variable is greater than > zero, or (2) the valid_policy_tree is not NULL, then path processing > has succeeded. > > > >So, in both cases, if requireExplicitPolicy is present with SkipCerts=0, >even in the final certificate in the path, then the path will be >rejected unless it is valid under at least one user acceptable policy. > The two documents also agree on the processing requirements when >skipCerts > 0. > >When Sharon mentioned a new defect report against X.509, she was >referring to the text in clause 8.4.2.3 that describes the >policyConstraints extension. There was concern that this text was >somewhat ambiguous. The text in clause 10, which provides detailed, >step-by-step, processing requirements for the fields in the >policyConstraints extension will not be changed. > > >There is, however, one place in which X.509 and RFC 3280 diverge in the >processing of the requireExplicitPolicy field of policyConstraints. > >X.509 states in clause 10.5.3: > > if the explicit-policy-pending indicator is set and the certificate >is not a self-issued intermediate certificate, > decrement the corresponding skip-certificates value and, if this >value becomes zero, set explicit-policy-indicator. > >RFC 3280 states in section 6.1.5 (prcessing of the final certificate in >the path): > > (a) If certificate n was not self-issued and explicit_policy is > not 0, decrement explicit_policy by 1. > > >Thus, in X.509 a self-issued end certificate counts when determining >whether the path is long enough to "turn on" the constraint. In RFC >3280, a self-issued end certifcate does not count. > >Since, as a general rule, self-issued end certificates are treated the >same as certificates that are not self-issued, I believe this was an >error in RFC 3280. > >Dave > > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RKtZb04703 for ietf-pkix-bks; Thu, 27 Feb 2003 12:55:35 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RKtYY04698 for ; Thu, 27 Feb 2003 12:55:34 -0800 (PST) Received: from chokhani (149.washington-15rh15rt.dc.dial-access.att.net[12.91.132.149]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003022720552911200ie6jfe>; Thu, 27 Feb 2003 20:55:29 +0000 From: "Santosh Chokhani" To: Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 15:55:59 -0500 Message-ID: <000d01c2dea2$a25bd230$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <3E5E3AF5.20707@nist.gov> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1RKtYY04700 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David: As Sharon notes, the text in the description of the extension needs to change. It will also nice to note that if skipCert < = 0 and valid_policy_tree = null, there is policy failure. I will propose some changes to both sections. The first one in my mind is a must (i.e., the description of the extension). The second one (i.e., in the path validation) is to simply add clarity that other wise path validation fails. I will propose some text later in response to Sharon's e-mail. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Thursday, February 27, 2003 11:21 AM To: ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Santosh Chokhani wrote: >I do not understand your first point. Are you saying that X.509 will >be changed to align with 3280 and in that case skipCerts = 0 for >requireExplicitPolicy will also take effect in the next certificate? >Or, are you saying that the difference between 3280 and X.509 will >remain? I assume you agree that I am reading 3280 correctly. > Santosh, X.509 and RFC 3280 both state that if a certificate includes requireExplicitPolicy with skipCerts = 0, the constraint takes effect immediately. In X.509, this can be seen in the following statements: Clause 10.5.3: For all certificates, the following actions are then performed: a) If explicit-policy-indicator is not set: If the requireExplicitPolicy constraint is present in the certificate, perform the following. For a SkipCerts value of 0, set the explicit-policy-indicator. Clause 10.5.4: For the end-certificate, the following actions are then performed: a) If explicit-policy-indicator is set, check that the authorities-constrained-policy-set table is not empty. (NOTE: As a result of DR 289, X.509 now requires that one also check that the user-constrained-policy-set is not empty). In RFC 3280: section 6.1.4 (processing of intermediate certificates): (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: (1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. section 6.1.5 (wrap-up procedure): (b) If a policy constraints extension is included in the certificate and requireExplicitPolicy is present and has a value of 0, set the explicit_policy state variable to 0. If either (1) the value of explicit_policy variable is greater than zero, or (2) the valid_policy_tree is not NULL, then path processing has succeeded. So, in both cases, if requireExplicitPolicy is present with SkipCerts=0, even in the final certificate in the path, then the path will be rejected unless it is valid under at least one user acceptable policy. The two documents also agree on the processing requirements when skipCerts > 0. When Sharon mentioned a new defect report against X.509, she was referring to the text in clause 8.4.2.3 that describes the policyConstraints extension. There was concern that this text was somewhat ambiguous. The text in clause 10, which provides detailed, step-by-step, processing requirements for the fields in the policyConstraints extension will not be changed. There is, however, one place in which X.509 and RFC 3280 diverge in the processing of the requireExplicitPolicy field of policyConstraints. X.509 states in clause 10.5.3: if the explicit-policy-pending indicator is set and the certificate is not a self-issued intermediate certificate, decrement the corresponding skip-certificates value and, if this value becomes zero, set explicit-policy-indicator. RFC 3280 states in section 6.1.5 (prcessing of the final certificate in the path): (a) If certificate n was not self-issued and explicit_policy is not 0, decrement explicit_policy by 1. Thus, in X.509 a self-issued end certificate counts when determining whether the path is long enough to "turn on" the constraint. In RFC 3280, a self-issued end certifcate does not count. Since, as a general rule, self-issued end certificates are treated the same as certificates that are not self-issued, I believe this was an error in RFC 3280. Dave Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RIKKm25300 for ietf-pkix-bks; Thu, 27 Feb 2003 10:20:20 -0800 (PST) Received: from mail.multicert.com ([62.48.185.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RIKIY25295 for ; Thu, 27 Feb 2003 10:20:18 -0800 (PST) Received: from multicert.com (unknown [192.168.0.125]) by mail.multicert.com (Postfix) with ESMTP id 0F8775B80C; Thu, 27 Feb 2003 18:14:59 +0000 (WET) Message-ID: <3E5E5627.6080405@multicert.com> Date: Thu, 27 Feb 2003 18:17:11 +0000 From: Ricardo Barroso User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: Robert Zuccherato , IETF-PKIX@imc.org Subject: Re: RFC 3161 Interoperability Site References: <3E5E3426.7070803@bull.net> Content-Type: multipart/alternative; boundary="------------050107050402010707080508" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --------------050107050402010707080508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello! Denis, since we wan't to start soon our interoperability tests, can you please send me that interoperability test matrix? Thanks in advance, Ricardo Barroso MULTICERT S.A. Denis Pinkas wrote: > > Robert, > > Thank you for posting this message. > > However no implementation can yet claim to be "RFC 3161 compliant" > since no interoperability test has been performed up to now. > > An interoperability test matrix has been sent to different people (in > fact all people I have been aware of) that have announced to support > the Time-Stamp Protocol from the IETF, but two companies (with > independent implementations) still need to fill-in the matrix so that > we can progress RFC 3161 to Proposed Standard. > > The only "difficult" part is to test the error cases in both directions. > > Denis > >> Entrust would like to announce that we have made available an RFC >> 3161 compliant TSA for interoperability test purposes. It is >> accessible at >> http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp >> and supports the HTTP protocol as specified in RFC 3161. The CA >> certificate required to verify the TSA certificate is available in >> Base 64 format at >> http://vsinterop.entrust.com:7001/verificationserver/ca.cer. >> The site is for interoperability testing of the RFC 3161 HTTP >> protocol only and is not guaranteed to be operational 24/7. If >> anyone has any questions or any problems arise with the site, please >> direct them to vsinterop-support@entrust.com. >> >> >> Robert Zuccherato >> > > --------------050107050402010707080508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello!

Denis, since we wan't to start soon our interoperability tests,
can you please send me that interoperability test matrix?

Thanks in advance,
Ricardo Barroso
MULTICERT S.A.


Denis Pinkas wrote:

Robert,

Thank you for posting this message.

However no implementation can yet claim to be "RFC 3161 compliant" since no interoperability test has been performed up to now.

An interoperability test matrix has been sent to different people (in fact all people I have been aware of) that have announced to support the Time-Stamp Protocol from the IETF, but two companies (with independent implementations) still need to fill-in the matrix so that we can progress RFC 3161 to Proposed Standard.

The only "difficult" part is to test the error cases in both directions.

Denis

Entrust would like to announce that we have made available an RFC 3161 compliant TSA for interoperability test purposes.  It is accessible at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp and supports the HTTP protocol as specified in RFC 3161.  The CA certificate required to verify the TSA certificate is available in Base 64 format at http://vsinterop.entrust.com:7001/verificationserver/ca.cer.
The site is for interoperability testing of the RFC 3161 HTTP protocol only and is not guaranteed to be operational 24/7.  If anyone has any questions or any problems arise with the site, please direct them to vsinterop-support@entrust.com.


        Robert Zuccherato




--------------050107050402010707080508-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RIC1S24809 for ietf-pkix-bks; Thu, 27 Feb 2003 10:12:01 -0800 (PST) Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RIBxY24801 for ; Thu, 27 Feb 2003 10:11:59 -0800 (PST) Received: from MarsXP ([148.233.248.105]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 27 Feb 2003 12:13:40 -0600 From: "Miguel Rodriguez" To: "'Denis Pinkas'" Cc: Subject: RE: RFC 3161 Interoperability Site Date: Thu, 27 Feb 2003 12:10:12 -0600 Message-ID: <000601c2de8b$78c25fa0$a600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3E5E3426.7070803@bull.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 27 Feb 2003 18:13:40.0515 (UTC) FILETIME=[F496F730:01C2DE8B] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, Can you send me (or tell me where can I get) a copy of the TSP interoperability test matrix? Regards, Miguel A Rodriguez SeguriDATA Mexico > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: Jueves, 27 de Febrero de 2003 09:52 a.m. > To: Robert Zuccherato > Cc: IETF-PKIX@imc.org > Subject: Re: RFC 3161 Interoperability Site > > > Robert, > > Thank you for posting this message. > > However no implementation can yet claim to be "RFC 3161 compliant" since > no > interoperability test has been performed up to now. > > An interoperability test matrix has been sent to different people (in fact > all people I have been aware of) that have announced to support the > Time-Stamp Protocol from the IETF, but two companies (with independent > implementations) still need to fill-in the matrix so that we can progress > RFC 3161 to Proposed Standard. > > The only "difficult" part is to test the error cases in both directions. > > Denis > > > Entrust would like to announce that we have made available an RFC 3161 > > compliant TSA for interoperability test purposes. It is accessible at > > http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp > > and supports the HTTP protocol as specified in RFC 3161. The CA > > certificate required to verify the TSA certificate is available in Base > > 64 format at > http://vsinterop.entrust.com:7001/verificationserver/ca.cer. > > > > The site is for interoperability testing of the RFC 3161 HTTP protocol > > only and is not guaranteed to be operational 24/7. If anyone has any > > questions or any problems arise with the site, please direct them to > > vsinterop-support@entrust.com. > > > > > > Robert Zuccherato > > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RGKTq17929 for ietf-pkix-bks; Thu, 27 Feb 2003 08:20:29 -0800 (PST) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RGKRY17925 for ; Thu, 27 Feb 2003 08:20:28 -0800 (PST) Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h1RGK0f1027794 for ; Thu, 27 Feb 2003 11:20:01 -0500 (EST) Message-ID: <3E5E3AF5.20707@nist.gov> Date: Thu, 27 Feb 2003 11:21:09 -0500 From: "David A. Cooper" Reply-To: david.cooper@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] References: <002d01c2de73$116a7530$9900a8c0@Chokhani> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh Chokhani wrote: >I do not understand your first point. Are you saying that X.509 will be >changed to align with 3280 and in that case skipCerts = 0 for >requireExplicitPolicy will also take effect in the next certificate? Or, >are you saying that the difference between 3280 and X.509 will remain? I >assume you agree that I am reading 3280 correctly. > Santosh, X.509 and RFC 3280 both state that if a certificate includes requireExplicitPolicy with skipCerts = 0, the constraint takes effect immediately. In X.509, this can be seen in the following statements: Clause 10.5.3: For all certificates, the following actions are then performed: a) If explicit-policy-indicator is not set: If the requireExplicitPolicy constraint is present in the certificate, perform the following. For a SkipCerts value of 0, set the explicit-policy-indicator. Clause 10.5.4: For the end-certificate, the following actions are then performed: a) If explicit-policy-indicator is set, check that the authorities-constrained-policy-set table is not empty. (NOTE: As a result of DR 289, X.509 now requires that one also check that the user-constrained-policy-set is not empty). In RFC 3280: section 6.1.4 (processing of intermediate certificates): (i) If a policy constraints extension is included in the certificate, modify the explicit_policy and policy_mapping state variables as follows: (1) If requireExplicitPolicy is present and is less than explicit_policy, set explicit_policy to the value of requireExplicitPolicy. section 6.1.5 (wrap-up procedure): (b) If a policy constraints extension is included in the certificate and requireExplicitPolicy is present and has a value of 0, set the explicit_policy state variable to 0. If either (1) the value of explicit_policy variable is greater than zero, or (2) the valid_policy_tree is not NULL, then path processing has succeeded. So, in both cases, if requireExplicitPolicy is present with SkipCerts=0, even in the final certificate in the path, then the path will be rejected unless it is valid under at least one user acceptable policy. The two documents also agree on the processing requirements when skipCerts > 0. When Sharon mentioned a new defect report against X.509, she was referring to the text in clause 8.4.2.3 that describes the policyConstraints extension. There was concern that this text was somewhat ambiguous. The text in clause 10, which provides detailed, step-by-step, processing requirements for the fields in the policyConstraints extension will not be changed. There is, however, one place in which X.509 and RFC 3280 diverge in the processing of the requireExplicitPolicy field of policyConstraints. X.509 states in clause 10.5.3: if the explicit-policy-pending indicator is set and the certificate is not a self-issued intermediate certificate, decrement the corresponding skip-certificates value and, if this value becomes zero, set explicit-policy-indicator. RFC 3280 states in section 6.1.5 (prcessing of the final certificate in the path): (a) If certificate n was not self-issued and explicit_policy is not 0, decrement explicit_policy by 1. Thus, in X.509 a self-issued end certificate counts when determining whether the path is long enough to "turn on" the constraint. In RFC 3280, a self-issued end certifcate does not count. Since, as a general rule, self-issued end certificates are treated the same as certificates that are not self-issued, I believe this was an error in RFC 3280. Dave Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RG2Wb16639 for ietf-pkix-bks; Thu, 27 Feb 2003 08:02:32 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RG2VY16635 for ; Thu, 27 Feb 2003 08:02:31 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Feb 2003 11:02:27 -0500 Message-ID: <9A4F653B0A375841AC75A8D17712B9C9061ABFF3@sottmxs04.entrust.com> From: Sharon Boeyen To: "'Santosh Chokhani'" , Sharon Boeyen , "'n Russ Housley'" Cc: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 11:02:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh and I did chat on the phone and worked through the processing steps in both 509 and 3280 for the example (see below). Both would have the same outcome for the path, however both Santosh and I believe the text in 3280 that describes the policyConstraints extension needs to be changed to align with both the 3280 path validation procedure and with 509 itself. Currently the text in 3280 clause 4.2.1.12 aligns with the pre DR 222 X.509 description, but the 3280 validation process aligns with the post DR 222 policy constraints. Santosh may propose some rewording for 4.2.1.12. Here is how X.509 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 10.5.3 sets the pending variable to 1 - when processing certificate 3 clause 10.5.3 decrements the pending variable to 0 and sets the explicit-policy-indicator flag on. Clause 10.5.3 and 10.5.4 perform the checks to satisfy the explicit-policy-indicator flag. Here is how RFC 3280 would process the sample path - when processing certificate 0 the pending flag is unset - when processing certificate 1 clause 6.1.4 step i sets the pending variable to 1 - when processing certificate 2 clause 6.1.5 step a decrements the pending variable to 0. - the very last test conducted at the end of 6.1.5 (see paragraph immediately above 6.1.6) says that the path succeeds if explicit-policy is greater than zero. In this example explicit-policy has reached zero and therefore the path fails. Because X.509 requires only that an implementation be "functionally equivalent to the external behaviour resulting from this procedure" the RFC 3280 path validation algorithm is conformant because the external behaviour is the same. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Thursday, February 27, 2003 10:15 AM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: My reading is very simple. My reading is as follows and it applies in general and not just to the last certificate in chain or other esoteric stuff. 2000 edition of X.509 starts applying the skipCerts for requireExplicitPolicy to the certificate in which it is asserted. 3280 applies the skipCerts for requireExplicitPolicy to the next certificate. For example, in the example Kodo cited (and in a private e-mail he agreed with me), 3280 will not require explicit policy for the path and X.509 will. The reasons are articulated in this thread by me. I will call you to discuss this. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 10:05 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFsmV15204 for ietf-pkix-bks; Thu, 27 Feb 2003 07:54:48 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFskY15196 for ; Thu, 27 Feb 2003 07:54:47 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23632; Thu, 27 Feb 2003 16:57:09 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA31958; Thu, 27 Feb 2003 15:48:18 +0100 Message-ID: <3E5E3426.7070803@bull.net> Date: Thu, 27 Feb 2003 16:52:06 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Robert Zuccherato CC: IETF-PKIX@imc.org Subject: Re: RFC 3161 Interoperability Site References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert, Thank you for posting this message. However no implementation can yet claim to be "RFC 3161 compliant" since no interoperability test has been performed up to now. An interoperability test matrix has been sent to different people (in fact all people I have been aware of) that have announced to support the Time-Stamp Protocol from the IETF, but two companies (with independent implementations) still need to fill-in the matrix so that we can progress RFC 3161 to Proposed Standard. The only "difficult" part is to test the error cases in both directions. Denis > Entrust would like to announce that we have made available an RFC 3161 > compliant TSA for interoperability test purposes. It is accessible at > http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp > and supports the HTTP protocol as specified in RFC 3161. The CA > certificate required to verify the TSA certificate is available in Base > 64 format at http://vsinterop.entrust.com:7001/verificationserver/ca.cer. > > The site is for interoperability testing of the RFC 3161 HTTP protocol > only and is not guaranteed to be operational 24/7. If anyone has any > questions or any problems arise with the site, please direct them to > vsinterop-support@entrust.com. > > > Robert Zuccherato > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFF8L11149 for ietf-pkix-bks; Thu, 27 Feb 2003 07:15:08 -0800 (PST) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFF7Y11145 for ; Thu, 27 Feb 2003 07:15:07 -0800 (PST) Received: from chokhani (4.washington-31rh15rt.dc.dial-access.att.net[12.91.164.4]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003022715150011100rfgoke>; Thu, 27 Feb 2003 15:15:01 +0000 From: "Santosh Chokhani" To: "'Sharon Boeyen'" , "'n Russ Housley'" Cc: , Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 10:15:29 -0500 Message-ID: <002d01c2de73$116a7530$9900a8c0@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <9A4F653B0A375841AC75A8D17712B9C9061ABFF1@sottmxs04.entrust.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1RFF7Y11146 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sharon: My reading is very simple. My reading is as follows and it applies in general and not just to the last certificate in chain or other esoteric stuff. 2000 edition of X.509 starts applying the skipCerts for requireExplicitPolicy to the certificate in which it is asserted. 3280 applies the skipCerts for requireExplicitPolicy to the next certificate. For example, in the example Kodo cited (and in a private e-mail he agreed with me), 3280 will not require explicit policy for the path and X.509 will. The reasons are articulated in this thread by me. I will call you to discuss this. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Thursday, February 27, 2003 10:05 AM To: 'Santosh Chokhani'; Sharon Boeyen; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RFEuX11130 for ietf-pkix-bks; Thu, 27 Feb 2003 07:14:56 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RFEsY11126 for ; Thu, 27 Feb 2003 07:14:55 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Feb 2003 10:14:50 -0500 Message-ID: From: Robert Zuccherato To: IETF-PKIX@imc.org Subject: RFC 3161 Interoperability Site Date: Thu, 27 Feb 2003 10:14:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2DE72.F7584370" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2DE72.F7584370 Content-Type: text/plain; charset="iso-8859-1" Entrust would like to announce that we have made available an RFC 3161 compliant TSA for interoperability test purposes. It is accessible at http://vsinterop.entrust.com:7001/verificationserver/rfc3161timestamp and supports the HTTP protocol as specified in RFC 3161. The CA certificate required to verify the TSA certificate is available in Base 64 format at http://vsinterop.entrust.com:7001/verificationserver/ca.cer. The site is for interoperability testing of the RFC 3161 HTTP protocol only and is not guaranteed to be operational 24/7. If anyone has any questions or any problems arise with the site, please direct them to vsinterop-support@entrust.com. Robert Zuccherato ------_=_NextPart_001_01C2DE72.F7584370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC 3161 Interoperability Site

Entrust would like to announce that we = have made available an RFC 3161 compliant TSA for interoperability test = purposes.  It is accessible at http://vsinterop.entrust.com:7001/verificationserver/r= fc3161timestamp and supports the HTTP protocol as specified in RFC = 3161.  The CA certificate required to verify the TSA certificate = is available in Base 64 format at http://vsinterop.entrust.com:7001/verificationserver/c= a.cer. 

The site is for interoperability = testing of the RFC 3161 HTTP protocol only and is not guaranteed to be = operational 24/7.  If anyone has any questions or any problems = arise with the site, please direct them to = vsinterop-support@entrust.com.


        Robert Zuccherato

------_=_NextPart_001_01C2DE72.F7584370-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1RF5YA10700 for ietf-pkix-bks; Thu, 27 Feb 2003 07:05:34 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1RF5WY10695 for ; Thu, 27 Feb 2003 07:05:32 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Thu, 27 Feb 2003 10:05:28 -0500 Message-ID: <9A4F653B0A375841AC75A8D17712B9C9061ABFF1@sottmxs04.entrust.com> From: Sharon Boeyen To: "'Santosh Chokhani'" , Sharon Boeyen , "'n Russ Housley'" Cc: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Date: Thu, 27 Feb 2003 10:05:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, I wasn't aware there was a difference. If there is we need to resolve that somehow. The X.509 text was changed via DR 222 against the 97 edition. That was the big DR that completely replaced the path processing text in 509 to address a number of primarily policy-related issues. I'm not sure I still have all the history of ballot comments etc, but I'm fairly sure that one of our goals was alignment between PKIX and 509 at the time. To try to clarify exactly what the difference is, do you agree with the following? a) If the final intermediate cert in the path causes the count to reach zero, the existence of an end certificate causes the path to be rejected in both 509 and PKIX if there isn't at least one acceptable policy in all certs in the path. If that is true, then as long as the final certificate in the path is always treated as an end certificates, as opposed to an intermediate certificate, I don't believe there is any misalignment between PKIX and 509. Am I missing something or do we just need to clarify that the final cert in a path is always treated treated as an end certificate regardless of whether it is a CA cert or an EE cert? Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Wednesday, February 26, 2003 8:53 PM To: 'Sharon Boeyen'; 'n Russ Housley' Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1R1qjl09914 for ietf-pkix-bks; Wed, 26 Feb 2003 17:52:45 -0800 (PST) Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1R1qid09910 for ; Wed, 26 Feb 2003 17:52:44 -0800 (PST) Received: from chokhani (124.washington-16rh15rt.dc.dial-access.att.net[12.91.134.124]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003022701523411200il8ese>; Thu, 27 Feb 2003 01:52:34 +0000 From: "Santosh Chokhani" To: "'Sharon Boeyen'" , "'n Russ Housley'" Cc: , Subject: RE: SkipCerts Question [RFC3280] Date: Wed, 26 Feb 2003 20:53:03 -0500 Message-ID: <001d01c2de02$f7f67420$7c865b0c@Chokhani> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <9A4F653B0A375841AC75A8D17712B9C9061ABFF0@sottmxs04.entrust.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1R1qid09911 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sharon: I do not understand your first point. Are you saying that X.509 will be changed to align with 3280 and in that case skipCerts = 0 for requireExplicitPolicy will also take effect in the next certificate? Or, are you saying that the difference between 3280 and X.509 will remain? I assume you agree that I am reading 3280 correctly. BTW, on the second point, I meant to say that the trust anchor issues a CA certificate and the CA is acting as an end entity and we want the requireExplicitPolicy to take affect immediately. -----Original Message----- From: Sharon Boeyen [mailto:sharon.boeyen@entrust.com] Sent: Wednesday, February 26, 2003 4:37 PM To: 'chokhani@orionsec.com'; n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QLb3A29821 for ietf-pkix-bks; Wed, 26 Feb 2003 13:37:03 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1QLb1d29816 for ; Wed, 26 Feb 2003 13:37:01 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id ; Wed, 26 Feb 2003 16:36:58 -0500 Message-ID: <9A4F653B0A375841AC75A8D17712B9C9061ABFF0@sottmxs04.entrust.com> From: Sharon Boeyen To: "'chokhani@orionsec.com'" , n Russ Housley Cc: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Subject: RE: SkipCerts Question [RFC3280] Date: Wed, 26 Feb 2003 16:36:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh I agree with you that the extension in cert 1 with a skip certs value of 1 DOES mean that the existence of cert 2 in the path reduces the skip certs value to 0 and the constraint takes effect immediately. This is not in contradiction with X.509 however, as a Defect Report was issued that aligned the two. The last time I looked at the wording in 509 however, I noticed that 2 additional changes are needed and submitted a new DR to the London meeting to fix them. I wasn't at the London meeting however and don't know what happened to the DR yet. However, one point I disagree with is with respect to your example of End-Entity certificates. If a trust anchor is issuing EE certs directly there is no certificate that they could include the policy constraints extension in. It is only permitted in CA certificates. EE certs however DO decrement the value of the skip certs for requiresExplicitPolicy and as such can have an effect on whether or not the policy is required. 509 did, as part of the original DR make that change to allow them to decrement the count, but did not change the requirement that the extension only be permitted in CA certs. Note, that this is the ONLY place where skipCerts is treated this way. For inhibitPolicyMapping and inhibitAnyPolicy, they take effect on subsequent certificates only, not the one that causes the count to reach zero and the certificates that need to align with the constraint are ONLY those that are subsequent to the zero count, whereas with requiresExplicitPolicy it is ALL certs in the path including those (if any) prior to the zero count being reached. Cheers, Sharon -----Original Message----- From: Santosh Chokhani [mailto:chokhani@orionsec.com] Sent: Friday, February 21, 2003 4:47 AM To: n Russ Housley Cc: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1QJv0R25600 for ietf-pkix-bks; Wed, 26 Feb 2003 11:57:00 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [204.167.114.129] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h1QJuxd25595 for ; Wed, 26 Feb 2003 11:56:59 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Feb 2003 19:57:01 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA18670; Wed, 26 Feb 2003 14:56:54 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <1WBW8QS3>; Wed, 26 Feb 2003 14:56:48 -0500 Message-ID: From: "Kaliski, Burt" To: "'Tom Gindin'" , Russ Housley Cc: "Manger, James H" , IETF-PKIX@imc.org Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Wed, 26 Feb 2003 14:56:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, Our intent is the encourage the use of a key pair with only one algorithm. The security analysis for each algorithm assumes a key pair is used with only the particular algorithm (and with a generally fixed set of underlying components). While we are not aware of any "bad" interactions if a key is used for both RSAES-OAEP and RSASSA-PSS, the security "assurance" may be reduced because the security analysis is no longer directly applicable. (If someone were to do the full security analysis for the use of a key pair with both algorithms, and the result were positive, then there would be motivation to change this recommendation.) Similarly, we would not recommend using a key with PKCS1-V1_5 and either of the newer schemes. But I understand that to encourage adoption of the new schemes, it may be necessary to allow a key pair to be used with more than one algorithm in the interim. -- Burt -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Saturday, February 22, 2003 8:15 AM To: Russ Housley; Kaliski, Burt Cc: Manger, James H; IETF-PKIX@imc.org Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Russ, Burt: Is the statement in section 6 of RFC 3447 (PKCS #2 2.1) really intended to suggest that TLS/SSL servers and S/MIME clients should not be implemented with single RSA key pairs which use RSA-PSS for signatures and also use RSA-OAEP for key encipherment? It seems to cover that case, although the examples given suggest that using two distinct signature-capable schemes is undesirable, as is using two distinct encryption-capable schemes, and so it is wrong to use PKCS1-V1_5 with either of the newer schemes. Tom Gindin Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1P2qmI11527 for ietf-pkix-bks; Mon, 24 Feb 2003 18:52:48 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1P2qld11523 for ; Mon, 24 Feb 2003 18:52:47 -0800 (PST) Received: (qmail 19079 invoked from network); 25 Feb 2003 02:45:57 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.165.110) by woodstock.binhost.com with SMTP; 25 Feb 2003 02:45:57 -0000 Message-Id: <5.2.0.9.2.20030224143338.02bcfe68@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 24 Feb 2003 16:27:58 -0500 To: BKaliski@rsasecurity.com, jimsch@exmsft.com From: Russ Housley Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Cc: IETF-PKIX@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Burt & Jim: Clearly there are some choices. I believe that use of the same object identifier is the best we can do given the current state of the world. The solution that we devise needs to be backward compatible. I do not think that assigning two OIDs for each possible use of an RSA or Elliptic Curve public key is desirable. We already need to assign one OID for the signature validation (or key management technique). Assigning a second OID for use in the subject public key info to say that the key can only be used in a particular manner is only useful if the parameters that are already associated with the currently assigned OID do not support the necessary information. Russ >[JS] 7. Section 3.2. I would like to see a different OID used for a >signature value from that used to encode the public key. This makes it >easier to process for encode/decode as there are not two structures with >the same OID. > >[BK] The OID is not used to encode the public key directly, but to encode an >AlgorithmID; the AlgorithmID is used to describe the public key. So, the >AlgorithmID has two meanings, one for the signature, one for the public key. >I agree this is potential problem, and am open to alternatives. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ONEku04532 for ietf-pkix-bks; Mon, 24 Feb 2003 15:14:46 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ONEkd04528 for ; Mon, 24 Feb 2003 15:14:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v2.2 Certificate Management Library (CML) Now Available Date: Mon, 24 Feb 2003 18:14:48 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v2.2 Certificate Management Library (CML) Now Available Thread-Index: AcI5gE4M/klWhmpWSMGjrjHpK3/8Ow== From: "Pawling, John" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1ONEkd04529 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, DigitalNet (formerly Getronics Government Solutions) has delivered the Version 2.2 Certificate Management Library (CML) for Microsoft Windows, Sun Solaris and Linux. The v2.2 CML and documentation is freely available at: . Applications requiring Public Key Infrastructure (PKI) security services can use the CML to meet their X.509 certificate and Certificate Revocation List (CRL) processing requirements. The v2.2 CML is described in the v2.2 CML Application Programming Interface (API) document. It implements the 2000 X.509 Recommendation certification path verification processing rules and SDN.706 profile. It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile requirements. There are some unsupported features such as Delta CRLs. The v2.2 CML Abstract Syntax Notation One (ASN.1) decodes X.509 Certificates and CRLs. It requires the v1.5 Enhanced SNACC ASN.1 software that is freely available from: . The CML provides robust certification path building capabilities such as using cross certificates. The CML uses the accompanying Storage and Retrieval Library (SRL) (optionally) to provide local certificate and CRL storage management functions. The SRL (optionally) provides remote directory retrieval capabilities using the Lightweight Directory Access Protocol (LDAP). The CML has been thoroughly tested including validating X.509 Certificates and CRLs created by a variety of Certification Authority (CA) products, and signed using the Digital Signature Algorithm (DSA) and RSA algorithms. Further enhancements, ports and testing of the CML are still in process. Further releases of the CML will be provided as significant capabilities are added. v2.2 CML includes the following enhancements (compared to v2.1 CML release): 1) Significantly improved robustness of the certification path building capabilities (especially the building of paths in cross-certified PKI environments). 2) Significantly improved performance and reduced memory requirements of CRL decoding and processing. 3) Enhanced the CML C++ library to support name constraints processing of the IPAddress GeneralName type. 4) Enhanced CML ASN.1 code to process both correct X.501 Clearance attribute syntax. 5) See the CML web site and CML API document for further details. v2.2 SRL includes the following enhancements (compared to v2.1 SRL release): 1) Enhanced SRL to remove the dependency on a local LDAP distribution located in the SMPDist directory. The new SRL uses the distribution that the customer is using on their platform. 2) Enhanced SRL to remove the dependency on LDAP header files. All source code for the CML is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the CML without paying any royalties or licensing fees. The CML was originally developed by the U.S. Government. DigitalNet is enhancing and supporting the CML under contract to the U.S. Government. The U.S. Government is furnishing the CML software at no cost to the vendor subject to the conditions of the CML Public License provided with the CML software. The CML makes calls to an algorithm-independent CTIL API that provides access to a variety of external crypto libraries. There is a CTIL for each crypto library that maps the generic CTIL API calls to the specific calls for that crypto library. DigitalNet provides CTILs for the Microsoft CAPI v2.0, Crypto++, RSA BSAFE, Spyrus SPEX/ and FORTEZZA Cryptologic Interface libraries. DigitalNet also provides a PKCS #11 CTIL that enables PKCS #11-compliant libraries to be used with the CML. The underlying, external crypto libraries are not distributed as part of the CML software. The CML has been successfully tested with the v2.2 S/MIME Freeware Library (SFL) that is freely available from . The CML has been successfully tested with the v2.2 Access Control Library (ACL) that is freely available to everyone from: . The CML has been successfully used to build and verify certificate paths used in the Bridge Certification Authority (BCA) demonstration which includes cross-certified hierarchical and non- hierarchical PKIs. The BCA Interoperability Test Suite (BITS) is a free and openly available test resource provided to facilitate vendor development of secure, interoperable Public Key Enabled applications. The CML has been used to successfully develop and verify the BITS X.509 certification paths available from . The National Institute of Standards and Technology (NIST) is providing a standard test suite of X.509 certificate paths that can be used for testing applications against RFC 2459. The CML was used to successfully process the NIST test data. The CML meets the requirements stated in the SDN.706 Certificate/ CRL Profile required by the U.S. Defense Message System (DMS) project. The Internet Mail Consortium (IMC) has established a CML web page and a CML mail list which is used to: distribute information regarding CML releases; discuss CML-related issues; and allow CML users to provide feedback, comments, bug reports, etc. Subscription information for the imc-cml mailing list is at the IMC web site listed above. All comments regarding the CML source code and documents are welcome. This CML release announcement was sent to several mail lists, but please send all messages regarding the CML to the imc-cml mail list ONLY. Please do not send messages regarding the CML to any of the IETF mail lists. We will respond to all messages sent to the imc-cml mail list. =========================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC =========================================== Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1OMZtm03167 for ietf-pkix-bks; Mon, 24 Feb 2003 14:35:55 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1OMZsd03163 for ; Mon, 24 Feb 2003 14:35:54 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: v1.5 Enhanced SNACC Freeware Now Available Date: Mon, 24 Feb 2003 17:35:56 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v1.5 Enhanced SNACC Freeware Now Available Thread-Index: AcI5cp6Z14OJyzHGQ8i472hAAgjQnA== From: "Pawling, John" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1OMZtd03164 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, DigitalNet (formerly Getronics Government Solutions) has delivered the v1.5 eSNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) Windows NT/98/2000/XP. The eSNACC software is freely available to everyone from: The eSNACC ASN.1 software can be used to ASN.1 encode and decode objects. In past releases, DigitalNet improved the eSNACC C++ library to implement the Distinguished Encoding Rules (DER), support large ASN.1 INTEGERs, and improve memory usage. v1.5 eSNACC enhancements (compared to v1.4 release): 1) Updated compiler to automatically read in ASN.1 module files listed in IMPORTS section of primary module. Added option for specifying directories to search when looking for imported ASN.1 modules. Now only primary ASN.1 module needs to be passed to the compiler. 2) Enhanced compiler to support OCTET STRING CONTAINS DER ENCODING feature. 3) Enhanced AsnBuf, ASNOcts, ASNAny class to expand as necessary when encoding and to decode directly from a file. CSM_Buffer moved out of eSNACC. 4) Enhanced C Library to use GenBuf to provide improved buffer processing capabilities. We successfully tested the v1.5 eSNACC ASN.1 C++ and C libraries using the Simple Network Management Protocol (SNMP) v1 test suite (18,000 test cases) developed by the University of Oulu. We tested the v1.5 eSNACC release with the v2.2 S/MIME Freeware Library (SFL) available from that uses the eSNACC ASN.1 software to encode and decode the IETF S/MIME v3 Cryptographic Message Syntax (RFC 3369) and Enhanced Security Services for S/MIME (RFC 2634) security protocol. We tested the v1.5 eSNACC release with the freeware v2.2 Certificate Management Library (CML) available from that uses the eSNACC ASN.1 software to encode and decode X.509 certificates, attribute certificates and Certificate Revocation Lists as specified in the 2000 X.509 Recommendation. We tested the v1.5 eSNACC release with the freeware v2.2 Access Control Library (ACL) available from that uses the eSNACC ASN.1 software to encode and decode security labels and other objects (such as Security Policy Information Files) required to provide rule based automated access control as specified in SDN.801. The eSNACC ASN.1 software implements the majority of the ASN.1 encoding/decoding rules as specified in the 1988 X.209 Recommendation. It implements the DER as specified in the 1997 X.690 Recommendation. It does not support all of the latest ASN.1 features, but there are strategies that allow it to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that do support the latest ASN.1 features. Also note that many of the PKIX specs, such as RFC 3280 and RFC 2630, include 1988-compliant ASN.1 syntax modules which can be compiled using the eSNACC compiler. The eSNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the eSNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the eSNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established an eSNACC web page . The IMC has established an eSNACC mail list which is used to: distribute information regarding eSNACC releases; discuss related issues; and provide a means for integrators to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We are still in the process of improving the eSNACC software. We welcome all feedback regarding the eSNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This release announcement was sent to several mail lists, but please send all messages regarding the eSNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the eSNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@DigitalNet.com DigitalNet Government Solutions, LLC ================================================= Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1O0HuM11201 for ietf-pkix-bks; Sun, 23 Feb 2003 16:17:56 -0800 (PST) Received: from center.kisa.or.kr ([211.252.150.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1O0Hnd11195 for ; Sun, 23 Feb 2003 16:17:49 -0800 (PST) Received: from LocalHost (localhost [127.0.0.1]) by center.kisa.or.kr (8.11.6+Sun/8.11.1) with ESMTP id h1O0F7L27292 for ; Mon, 24 Feb 2003 09:15:07 +0900 (KST) From: "InKyoung Jeun" To: Subject: FW: SkipCerts Question [RFC3280] Date: Mon, 24 Feb 2003 09:17:49 +0900 Message-ID: <001201c2db9a$2a3ecb00$b40310ac@LocalHost> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: -----Original Message----- From: InKyoung Jeun [mailto:ikjeun@kisa.or.kr] Sent: Friday, February 21, 2003 1:22 PM To: 'Russ Housley'; 'k-fujino@pb.jp.nec.com'; 'ietf-pkix@imc.org' Subject: RE: SkipCerts Question [RFC3280] Russ : I think cert2 is required to have an explicit policy. In the RFC3280 Basic Path validation, if i is equal to n, perform the wrap-up steps. Cert2 is n=i=2, so we must perform the wrap-up steps. During wrap-up steps, state variable explicit_Policy is set to 0. Because if cert2 is not self-issed and explicit policy is 1. Let's look at the result. If cert2 has not an explicit policy, valid_policy_tree in NULL and explicit_policy is 0. And the path processing has failed. So cert2 is required to have an explicit policy. Kyoung. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Friday, February 21, 2003 8:42 AM To: k-fujino@pb.jp.nec.com; ietf-pkix@imc.org Subject: Re: SkipCerts Question [RFC3280] Kozo: You understand correctly -- cert2 is not required to have an explicit policy. Russ At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: >Dear all, > >We are now testing our certificate path validation >program in Japan. >And I have a question on the "SkipCerts" in the RFC3280. > >Would you please tell me? > >----- >According to the RFC3280, > >4.2.1.12 Policy Constraints > > > >If the requireExplicitPolicy field is present, the value of >requireExplicitPolicy indicates the number of additional certificates >that may appear in the path before an explicit policy is required for >the entire path. >----- > >If there is a certificate path like the following, > cert0 > cert1 > cert2 > >and if the cert1 has the requireExplicitPolicy=1, > >is the cert2 required to have an explicit policy or not ? > >(Is the value applied to the cert1 > which has the requireExplicitPolicy=1?) > >I don't think the cert2 is required to have it, >but I'm not sure. > >Regards, > Kozo >-------------------------------------------------------- >Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >NEC System Technologies, Ltd. >Hiroshima, Japan Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1MDGsl09241 for ietf-pkix-bks; Sat, 22 Feb 2003 05:16:54 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1MDGqd09237 for ; Sat, 22 Feb 2003 05:16:52 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1MDGix7057636; Sat, 22 Feb 2003 08:16:44 -0500 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1MDGf2B124252; Sat, 22 Feb 2003 08:16:42 -0500 Importance: Normal Sensitivity: Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg To: Russ Housley , BKaliski@rsasecurity.com Cc: "Manger, James H" , IETF-PKIX@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Sat, 22 Feb 2003 08:14:53 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 02/22/2003 08:16:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Burt: Is the statement in section 6 of RFC 3447 (PKCS #2 2.1) really intended to suggest that TLS/SSL servers and S/MIME clients should not be implemented with single RSA key pairs which use RSA-PSS for signatures and also use RSA-OAEP for key encipherment? It seems to cover that case, although the examples given suggest that using two distinct signature-capable schemes is undesirable, as is using two distinct encryption-capable schemes, and so it is wrong to use PKCS1-V1_5 with either of the newer schemes. Tom Gindin Russ Housley @mail.imc.org on 02/21/2003 12:14:34 PM Sent by: owner-ietf-pkix@mail.imc.org To: "Manger, James H" cc: BKaliski@rsasecurity.com, IETF-PKIX@imc.org Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg James: Let be give you some background. PKCS#1 v2.1 includes a recommendation that RSA private key only be used with one scheme (such as PSS, OAEP, PKCS#1 v1.5 Signature, PKCS#1 v1.5 key transport, ...). Further, in the case of OAEP, PKCS#1 v2.1 recommends that an RSA private key make use only one mask generation function. The key usage extension can be used to distinguish RSA signature verification keys and RSA key transport keys. But it does not meet the above requirements. So, how can the private key owner's intentions be conveyed to another party? The use of subject public key info seems natural to me. This algorithm identifier is intended to convey to the certificate user information about the public key algorithm. I am opposed to a new certificate extension for algorithm constraints. In RFC 3279, there is a list of public key algorithms. For each algorithm, it specifies the OID to be carried in subject public key info and the format of the public key itself. If the algorithm is a signature algorithm, then there are additional OIDs that imply the use of particular one-way hash functions and the format of the signature value. Perhaps the explosion of OIDs for signature algorithm plus one-way hash function could have been avoided by using a parameter with an OID identifying the one-way hash function, but historically this was not done. People have code that handles this situation in a straightforward manner. While I do not mind exploring other alternatives, I do not think that we should deviate for the historical convention unless there are real unmet needs. In my opinion, the current convention is meeting all of the needs of today's certificate using applications. Russ At 04:29 PM 2/12/2003 +1000, Manger, James H wrote: >Constraining the algorithms with which a key is used is good security >practice so there is sense in including a constraint to this effect in a >certificate. However, I am not sure that: >a) the subjectPublicKeyInfo field should hold this constraint and >b) the syntax for the constraint should be an Alg.Id. > >Jim Schaad's comments #8 and #13 (confusion about how to compare the >parameters of a signature or encryption with the parameters from >subjectPublicKeyInfo) are due to the constraint being specified with an >Alg.Id, which is not quite appropriate (e.g. by including a saltLength >field that is irrelevant). > >Consider other possible (& reasonable?) constraints that you may wish to >express: > >1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 as the hash >algorithm. >[Cannot be expressed as RSASSA-PSS-params only has a single hashAlgorithm >field] > >2* Use this key for RSASSA-PSS signatures or RSAES-OAEP encryption, but >not with any other algorithms. >[Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > >3* Only use id-sha1-with-dss-signature for signing. >[Cannot be expressed as this signature OID has NULL parameters, but {p, q, >g} need to be specified.] > >4* Tell your signing software only to use RSASSA-PSS with this key, but >don't prevent some legacy apps from accepting your signature. >[Cannot be expressed as legacy apps reject the cert as they don't accept >id-RSASSA-PSS in subjectPublicKeyInfo. To work, the constraint needs to >be in a non-critical extension.] > > >A better solution would be to define a new extension to hold the >constraint. Mark it critical to guarantee enforcement of the constraint, >or non-critical to supply the info but maintain some backward compatibility. > >algorithmConstraints EXTENSION ::= { > SYNTAX AlgConstraintsSyntax > IDENTIFIED By id-ce-algorithmConstraints } > >AlgConstraintsSyntax ::= ...???????... this is the hard bit > > >A simple syntax would be: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID is in the sequence. > >Or the same simple syntax with more complex semantics: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID > -- and all the OIDs of any other Alg.Ids > -- in its parameters field (inc. defaults if absent) > -- are all in the sequence > >Or something really generic: > Filter -- see X.511 > -- applied to a "virtual entry" containing just the Alg.Id in > question > >Or... > > >---------- >From: Jim Schaad [mailto:jimsch@nwlink.com] >Sent: Saturday, 8 February 2003 4:59 AM >Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > >... > >---------- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Wednesday, 8 January 2003 12:30 AM > > Title : Additional Algorithms and Identifiers for RSA > Cryptography for use in the Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile > Author(s) : R. Housley, B. Kaliski > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > Pages : 22 > Date : 2003-1-6 > >This document supplements RFC 3279. It describes the conventions for >using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport >algorithm, and additional one-way hash functions with the PKCS #1 version >1.5 signature algorithm in the Internet X.509 Public Key Infrastructure >(PKI). Encoding formats, algorithm identifiers, and parameter formats are >specified. > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLiU426393 for ietf-pkix-bks; Fri, 21 Feb 2003 13:44:30 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1LLiTd26389 for ; Fri, 21 Feb 2003 13:44:29 -0800 (PST) Received: (qmail 8783 invoked from network); 21 Feb 2003 21:44:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.160.75) by woodstock.binhost.com with SMTP; 21 Feb 2003 21:44:19 -0000 Message-Id: <5.2.0.9.2.20030221123939.00bb8188@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Feb 2003 12:44:09 -0500 To: From: Russ Housley Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Cc: IETF-PKIX@imc.org, BKaliski@rsasecurity.com In-Reply-To: <004201c2d790$36df6df0$1600a8c0@soaringhawk.net> References: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmail.telstra.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim: You and I are closer to agreement than I realized. That is a good sign. I do not want to have more than one parameter syntax associated with a single OID. I do not want the RSAES-OAEP OID to have one parameter syntax when it is used in subject public key info and another parameter syntax when it is used in EnvelopedData. In my opinion, each OID should only have a single parameter syntax, otherwise the automatic parsing of the parameters filed will become context sensitive. Russ At 12:56 PM 2/18/2003 -0800, Jim Schaad wrote: >I disagree that the problem of specifing the constraints is based on the >fact that the restraints are specified in the Alg.Id field. > >I do agree that the constraints should be expressed differently. I >think that the signature and public key parameters structures should be >specified as different structures. I am not even sure that I like the >fact that PSS is using DEFAULT parameters. (This has the potential to >slow down moving to a larger hash algorithm since the size of the >certificate is going to increase.) > >My preference would be to specify the necessary constraints in the >parameters of the algorithm location. > >I disagree that there is a reason to worry about specifying a constraint >that says "My software should only use alg X, but display as alg Y". >This is an internal issue to the software and should not be imposed >externally. > >jim > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H > > Sent: Tuesday, February 11, 2003 10:30 PM > > To: IETF-PKIX@imc.org > > Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - > > binding key to 1 alg > > > > > > > > Constraining the algorithms with which a key is used is good > > security practice so there is sense in including a constraint > > to this effect in a certificate. However, I am not sure that: > > a) the subjectPublicKeyInfo field should hold this constraint and > > b) the syntax for the constraint should be an Alg.Id. > > > > Jim Schaad's comments #8 and #13 (confusion about how to > > compare the parameters of a signature or encryption with the > > parameters from subjectPublicKeyInfo) are due to the > > constraint being specified with an Alg.Id, which is not quite > > appropriate (e.g. by including a saltLength field that is irrelevant). > > > > Consider other possible (& reasonable?) constraints that you > > may wish to express: > > > > 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 > > as the hash algorithm. > > [Cannot be expressed as RSASSA-PSS-params only has a single > > hashAlgorithm field] > > > > 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP > > encryption, but not with any other algorithms. > > [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > > > > 3* Only use id-sha1-with-dss-signature for signing. > > [Cannot be expressed as this signature OID has NULL > > parameters, but {p, q, g} need to be specified.] > > > > 4* Tell your signing software only to use RSASSA-PSS with > > this key, but don't prevent some legacy apps from accepting > > your signature. > > [Cannot be expressed as legacy apps reject the cert as they > > don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, > > the constraint needs to be in a non-critical extension.] > > > > > > A better solution would be to define a new extension to hold > > the constraint. Mark it critical to guarantee enforcement of > > the constraint, or non-critical to supply the info but > > maintain some backward compatibility. > > > > algorithmConstraints EXTENSION ::= { > > SYNTAX AlgConstraintsSyntax > > IDENTIFIED By id-ce-algorithmConstraints } > > > > AlgConstraintsSyntax ::= ...???????... this is the hard bit > > > > > > A simple syntax would be: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID is in the sequence. > > > > Or the same simple syntax with more complex semantics: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID > > -- and all the OIDs of any other Alg.Ids > > -- in its parameters field (inc. defaults if absent) > > -- are all in the sequence > > > > Or something really generic: > > Filter -- see X.511 > > -- applied to a "virtual entry" containing just the > > Alg.Id in question > > > > Or... > > > > > > ---------- > > From: Jim Schaad [mailto:jimsch@nwlink.com] > > Sent: Saturday, 8 February 2003 4:59 AM > > Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > > > > ... > > > > ---------- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Wednesday, 8 January 2003 12:30 AM > > > > Title : Additional Algorithms and Identifiers > > for RSA Cryptography for use in the Internet X.509 Public Key > > Infrastructure Certificate and Certificate Revocation List > > (CRL) Profile > > Author(s) : R. Housley, B. Kaliski > > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > > Pages : 22 > > Date : 2003-1-6 > > > > This document supplements RFC 3279. It describes the > > conventions for using the RSASSA-PSS signature algorithm, the > > RSAES-OAEP key transport algorithm, and additional one-way > > hash functions with the PKCS #1 version 1.5 signature > > algorithm in the Internet X.509 Public Key Infrastructure > > (PKI). Encoding formats, algorithm identifiers, and > > parameter formats are specified. > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LLhA626355 for ietf-pkix-bks; Fri, 21 Feb 2003 13:43:10 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1LLh9d26351 for ; Fri, 21 Feb 2003 13:43:09 -0800 (PST) Received: (qmail 8648 invoked from network); 21 Feb 2003 21:42:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.160.75) by woodstock.binhost.com with SMTP; 21 Feb 2003 21:42:59 -0000 Message-Id: <5.2.0.9.2.20030221120326.00bc8dc0@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 21 Feb 2003 12:14:34 -0500 To: "Manger, James H" From: Russ Housley Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Cc: BKaliski@rsasecurity.com, IETF-PKIX@imc.org In-Reply-To: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmai l.telstra.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: James: Let be give you some background. PKCS#1 v2.1 includes a recommendation that RSA private key only be used with one scheme (such as PSS, OAEP, PKCS#1 v1.5 Signature, PKCS#1 v1.5 key transport, ...). Further, in the case of OAEP, PKCS#1 v2.1 recommends that an RSA private key make use only one mask generation function. The key usage extension can be used to distinguish RSA signature verification keys and RSA key transport keys. But it does not meet the above requirements. So, how can the private key owner's intentions be conveyed to another party? The use of subject public key info seems natural to me. This algorithm identifier is intended to convey to the certificate user information about the public key algorithm. I am opposed to a new certificate extension for algorithm constraints. In RFC 3279, there is a list of public key algorithms. For each algorithm, it specifies the OID to be carried in subject public key info and the format of the public key itself. If the algorithm is a signature algorithm, then there are additional OIDs that imply the use of particular one-way hash functions and the format of the signature value. Perhaps the explosion of OIDs for signature algorithm plus one-way hash function could have been avoided by using a parameter with an OID identifying the one-way hash function, but historically this was not done. People have code that handles this situation in a straightforward manner. While I do not mind exploring other alternatives, I do not think that we should deviate for the historical convention unless there are real unmet needs. In my opinion, the current convention is meeting all of the needs of today's certificate using applications. Russ At 04:29 PM 2/12/2003 +1000, Manger, James H wrote: >Constraining the algorithms with which a key is used is good security >practice so there is sense in including a constraint to this effect in a >certificate. However, I am not sure that: >a) the subjectPublicKeyInfo field should hold this constraint and >b) the syntax for the constraint should be an Alg.Id. > >Jim Schaad's comments #8 and #13 (confusion about how to compare the >parameters of a signature or encryption with the parameters from >subjectPublicKeyInfo) are due to the constraint being specified with an >Alg.Id, which is not quite appropriate (e.g. by including a saltLength >field that is irrelevant). > >Consider other possible (& reasonable?) constraints that you may wish to >express: > >1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 as the hash >algorithm. >[Cannot be expressed as RSASSA-PSS-params only has a single hashAlgorithm >field] > >2* Use this key for RSASSA-PSS signatures or RSAES-OAEP encryption, but >not with any other algorithms. >[Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > >3* Only use id-sha1-with-dss-signature for signing. >[Cannot be expressed as this signature OID has NULL parameters, but {p, q, >g} need to be specified.] > >4* Tell your signing software only to use RSASSA-PSS with this key, but >don't prevent some legacy apps from accepting your signature. >[Cannot be expressed as legacy apps reject the cert as they don't accept >id-RSASSA-PSS in subjectPublicKeyInfo. To work, the constraint needs to >be in a non-critical extension.] > > >A better solution would be to define a new extension to hold the >constraint. Mark it critical to guarantee enforcement of the constraint, >or non-critical to supply the info but maintain some backward compatibility. > >algorithmConstraints EXTENSION ::= { > SYNTAX AlgConstraintsSyntax > IDENTIFIED By id-ce-algorithmConstraints } > >AlgConstraintsSyntax ::= ...???????... this is the hard bit > > >A simple syntax would be: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID is in the sequence. > >Or the same simple syntax with more complex semantics: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID > -- and all the OIDs of any other Alg.Ids > -- in its parameters field (inc. defaults if absent) > -- are all in the sequence > >Or something really generic: > Filter -- see X.511 > -- applied to a "virtual entry" containing just the Alg.Id in > question > >Or... > > >---------- >From: Jim Schaad [mailto:jimsch@nwlink.com] >Sent: Saturday, 8 February 2003 4:59 AM >Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > >... > >---------- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Wednesday, 8 January 2003 12:30 AM > > Title : Additional Algorithms and Identifiers for RSA > Cryptography for use in the Internet X.509 Public Key Infrastructure > Certificate and Certificate Revocation List (CRL) Profile > Author(s) : R. Housley, B. Kaliski > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > Pages : 22 > Date : 2003-1-6 > >This document supplements RFC 3279. It describes the conventions for >using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport >algorithm, and additional one-way hash functions with the PKCS #1 version >1.5 signature algorithm in the Internet X.509 Public Key Infrastructure >(PKI). Encoding formats, algorithm identifiers, and parameter formats are >specified. > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1LGuvt11191 for ietf-pkix-bks; Fri, 21 Feb 2003 08:56:57 -0800 (PST) Received: from tholian.rsasecurity.com (tholian.rsasecurity.com [204.167.114.129] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id h1LGutd11187 for ; Fri, 21 Feb 2003 08:56:56 -0800 (PST) Received: from no.name.available by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Feb 2003 16:56:57 UT Received: from exna00.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA04864; Fri, 21 Feb 2003 11:56:48 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <1WBW62BK>; Fri, 21 Feb 2003 11:56:44 -0500 Message-ID: From: "Kaliski, Burt" To: "'jimsch@exmsft.com'" , "'Russ Housley'" Cc: IETF-PKIX@imc.org Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Date: Fri, 21 Feb 2003 11:56:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Jim, Sorry for my slow response to your comments. My replies are embedded below. I'm not fully committed to the approach of encoding algorithm usage restrictions into the "public key type", and am open to other suggestions. Your message illustrates the challenges with this approach. -- Burt -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, February 07, 2003 12:59 PM To: 'Russ Housley'; Kaliski, Burt Cc: IETF-PKIX@imc.org Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Gentlemen, 1. Can you make the title of the document another line longer? [BK] We'll try :-) 2. Please consider adding the following textto section 1.2 p 3. "Note: It is not possible to restict the use of a key either RSASSA-PSS and anything else. The same is true of RSAES-OAEP." [BK] Agreed. 3. In section 1.2 p 2 last sentence. I think it should be "signature and/or key transport". [BK] Our intent was that a key would be used only for one or other other, hence "or" not "and/or". 4. In section 2.1, there is a par of paragraphs about the use of NULL or ABSENT in encoding the hash functions. There appears to be a conflict between the two paragraphs. The first says use ABSENT. The second says use NULL. One or the other should be omitted, I would perfer the second as the first is the "standard" way of doing things. The second would require changes in my encoder/decoder utility functions. [BK] Both are allowed, due to confusion in implementations. The parameters should be absent, but if present must be NULL. The new RFC version of PKCS #1 v2.1 includes text on this, ftp://ftp.rfc-editor.org/in-notes/rfc3447.txt. 5. Section 3, para 1, last sentence: It appears to me that there should potentially be two different statements on conforming CAs. Some CAs will using RSASSA-PSS as the signing algorithm, while other will just encode a certificate with the RSASSA-PSS public key. Should these be seperated in conformant statements? [BK] Agreed, the conformance may be different for signing with RSASSA-PSS, vs. including public keys restricted to RSASSA-PSS. 6. Section 3.1 maskGenAlgorithm. Please remove the statement "It MUST be an algorithm identifier". This is a tautology. [BK] OK. 7. Section 3.2. I would like to see a different OID used for a signature value from that used to encode the public key. This makes it easier to process for encode/decode as there are not two structures with the same OID. [BK] The OID is not used to encode the public key directly, but to encode an AlgorithmID; the AlgorithmID is used to describe the public key. So, the AlgorithmID has two meanings, one for the signature, one for the public key. I agree this is potential problem, and am open to alternatives. 8. RSASSA-PSS-params and signature processing. I am confused about what should be done by a signature verifier/producer in checking the parameters of a signature againist the parameters of a signature. My first assumption was that all of the fields mattered and should be "equivalent". From reading the text I find that this is not the case and the saltLength is encoded in the certificate parameters but is wildcarded against the signature parameters. This type of behavior makes implementation difficult. My first assumption on this implemenation was a binary comparison. This would not work for a number of reasons the first being saltLength, the second being the requirements that I need to be able to match a defaulted parameter against an existing parameter (i.e. sha1Identifier present vs absent). [BK] I see the challenge. 9. Section 3.1 maskGenAlgorithm. The text at the end of the paragraph is missing some cases that would seem to be logical. The following should be matched: ABSENT {id-mgf1} {id-mgf1, {id-sha1}} {id-mgf1, {id-sha1, NULL}} It would be MUCH simplier if the "stupid" cases could be removed, but I don't know if that would match your worldview. [BK] The second case can be removed since MGF1 must have a parameter (no confusion on that). The others are needed, the first one for the default case, the third and fourth in case of confusion about SHA1's parameters (though MGF1 is explicit that it expects the SHA1 to have parameters). 10. Section 3.1 saltLength. There seems to be a mis-match between the default value in the ASN.1 structure and that in the text. The structure definition says 20. The description says the length of the hash output value. This implies that if I were to use md5 as in the hashAlgorithm field, the default value of the ASN.1 structure for saltLength would suddenly be 16 not 20. [BK] Yes, this is a problem, already propagated in PKCS #1 v2.1. Better not to have defaults ... what's your preference on fixing things? 11. Section 4.1, para 1 - missing id- from RSAES-OAEP in the first sentence. [BK] OK. 12. Section 4.1, maskGenFunc - see comment 9. [BK] See above. 13. Section 4.1, RSAES-OAEP-params comparison function. This comparison has some of the same problems as that of RSASSA-PSS. I don't know the proper way to compare pSourceFunc. I believe that the comparison here is dependent on the value of pSourceFunc.Algorithm. For a value of id-pSpecified, this field should be ignored. Are there other values (such as if nullOctetString is not of 0 length based on para 6 of the security considerations section). [BK] In general, this field is unused. But I can see cases where it might be used several different ways with a given public key, which means that a direct comparison might not be ideal. 14. Section 5. Please change "the parameters MUST be NULL" to "the parameters MUST be ABSENT". This matches SHA-1 convention. [BK] See answer to comment 4. The parameters SHOULD be absent but MAY be NULL, and receivers MUST accept either. 15. ASN.1 Module: Organization: It helps if the parameters structure is in the same section as the OID that uses the structure. Looking from the top to the very bottom for the parameters is messy. [BK] Agreed, will improve this. 16. ASN.1 Module: All of the rSASSA-PSS-*-Identifier structures need to be changed to rSASSA-PSS-*-Identifier AlgorithmIdentifier ::= { id-RSASSA-PSS, rSASSA-PSS-*-params } rSASSA-PSS-*-params RSASSA-PSS-params ::= { *-hash, mgf1*Identifier, 20, 1} The second level of initialization cannot be done in 1988 because the structure is an ANY. [BK] OK. 17. Section 7.1 [P1v2.1] Remove the first J. and the first comma. [BK] OK. Jim Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1L9ugt17028 for ietf-pkix-bks; Fri, 21 Feb 2003 01:56:42 -0800 (PST) Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1L9ufd17023 for ; Fri, 21 Feb 2003 01:56:41 -0800 (PST) Received: from 203.94.239.165 (localhost [127.0.0.1]) by host13.websitesource.com (8.10.2/8.10.2) with ESMTP id h1L9uYI15947; Fri, 21 Feb 2003 04:56:34 -0500 To: n Russ Housley From: Santosh Chokhani Subject: Re: SkipCerts Question [RFC3280] Reply-To: chokhani@orionsec.com CC: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org Date: Fri, 21 Feb 2003 04:47:00 -0500 X-Sender: chokhani@orionsec.com X-Originating-Host: 203.94.239.165 [203.94.239.165]; Fri, 21 Feb 2003 09:56:34 GMT X-Mailer: WebMail Check v2.3.21 (2000-7-19) X-Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; AT&T CSM6.0), JavaScript: On Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kozo and Russ: Both of your e-mails are ambiguous to me. Let me try to provide a clear answer and hopefully it will relate to the question being asked. 1. For require explicit policy, the skipCerts starts applying to the certificate in which the value is asserted. 3280 is in contradiction in this area with X.509. The reason it was done is so that in a case where trust anchor issues end entity certificates, the infrastructure can control turning on of this feature. 2. DFor requireExpliclityPolicy once a value of zero is reached, requires a common policy in each certificate (taking policy mapping into consideration). Furthermore, if user initializes the path validation with one or more policies (other than anyPolicy), at least one of the user policies must appear in each certificate (again taking policy mapping into consideration). 3. 3280 is incomplete in the area of processing requireExplicitPolicy related stuff. Specifically, it does not define how there is policy failure due to the requireExplicitPolicy being set. In Kozo's scenario, cert2 need not have requireExplicitPolicy field. But, since skipCert applies to cert1, by the time cert2 is processed, requireExplicitPolicy flag is set and all three certiifcates cert0, cert1, and cert2 must have at least one common policy asserted. In addition, if user initialized the path processing with some explicit policy(s), at least one of those policies must be common to all three certificates. Any other interpretation by 3280 makes 3280 inconsistent with X.509 in the area of policy processing. At Thursday, 20 February 2003, Russ Housley wrote: >Kozo: > >You understand correctly -- cert2 is not required to have an explicit policy. > >Russ > >At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: > >>Dear all, >> >>We are now testing our certificate path validation >>program in Japan. >>And I have a question on the "SkipCerts" in the RFC3280. >> >>Would you please tell me? >> >>----- >>According to the RFC3280, >> >>4.2.1.12 Policy Constraints >> >> >> >>If the requireExplicitPolicy field is present, the value of >>requireExplicitPolicy indicates the number of additional certificates >>that may appear in the path before an explicit policy is required for >>the entire path. >>----- >> >>If there is a certificate path like the following, >> cert0 >> cert1 >> cert2 >> >>and if the cert1 has the requireExplicitPolicy=1, >> >>is the cert2 required to have an explicit policy or not ? >> >>(Is the value applied to the cert1 >> which has the requireExplicitPolicy=1?) >> >>I don't think the cert2 is required to have it, >>but I'm not sure. >> >>Regards, >> Kozo >>-------------------------------------------------------- >>Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >>NEC System Technologies, Ltd. >>Hiroshima, Japan > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KNgnj08803 for ietf-pkix-bks; Thu, 20 Feb 2003 15:42:49 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1KNgmd08799 for ; Thu, 20 Feb 2003 15:42:48 -0800 (PST) Received: (qmail 17482 invoked from network); 20 Feb 2003 23:42:40 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (131.107.52.146) by woodstock.binhost.com with SMTP; 20 Feb 2003 23:42:40 -0000 Message-Id: <5.2.0.9.2.20030220184116.038b7720@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 20 Feb 2003 18:42:06 -0500 To: k-fujino@pb.jp.nec.com, ietf-pkix@imc.org From: Russ Housley Subject: Re: SkipCerts Question [RFC3280] In-Reply-To: <20030217194548k-fujino@smtp.necst.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Kozo: You understand correctly -- cert2 is not required to have an explicit policy. Russ At 07:45 PM 2/17/2003 +0900, k-fujino@pb.jp.nec.com wrote: >Dear all, > >We are now testing our certificate path validation >program in Japan. >And I have a question on the "SkipCerts" in the RFC3280. > >Would you please tell me? > >----- >According to the RFC3280, > >4.2.1.12 Policy Constraints > > > >If the requireExplicitPolicy field is present, the value of >requireExplicitPolicy indicates the number of additional certificates >that may appear in the path before an explicit policy is required for >the entire path. >----- > >If there is a certificate path like the following, > cert0 > cert1 > cert2 > >and if the cert1 has the requireExplicitPolicy=1, > >is the cert2 required to have an explicit policy or not ? > >(Is the value applied to the cert1 > which has the requireExplicitPolicy=1?) > >I don't think the cert2 is required to have it, >but I'm not sure. > >Regards, > Kozo >-------------------------------------------------------- >Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) >NEC System Technologies, Ltd. >Hiroshima, Japan Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KKvxX05162 for ietf-pkix-bks; Thu, 20 Feb 2003 12:57:59 -0800 (PST) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KKvtd05158 for ; Thu, 20 Feb 2003 12:57:56 -0800 (PST) Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h1KKujf2012773; Thu, 20 Feb 2003 15:56:45 -0500 (EST) Message-Id: <5.1.0.14.2.20030220144712.0210d4c0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 20 Feb 2003 14:57:14 -0500 To: ietf-pkix@imc.org From: Tim Polk Subject: DPD/DPV Protocol Selection Cc: kent@bbn.com, Denis Pinkas , Peter Sylvester , Russ Housley , Ambarish Malpani , Michael Myers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, After some delay, it is finally time to settle on a single PKIX WG protocol for DPD/DPV. Steve and I have been mulling over the results from the strawpoll, as well as the technical content of the messages posted to the list. As you all are aware, we have been adamant that the WG advance only one protocol for DPD/DPV. However, that is not the only important factor. We are also adamant that (1) the protocol must have adequate support among implementers, (2) the protocol MUST satisfy the requirements specified in RFC 3379, and (3) the protocol be mature enough for completion soon. As the co-chairs, we needed to satisfy ourselves that the process was not a beauty contest, and had chosen a technically sound engineering solution. After much consideration, Steve and I are satisfied that SCVP is the best choice as the PKIX WG protocol for DPD/DPV. Let me outline the rationale: (1) The protocol must have adequate support among implementers. The strawpoll voting results were: SCVP 26; OCSP 15; DVCS 8; and CVP 2 out of 51 total votes. These numbers include a vote from Denis for CVP, even though he never officially submitted one, but exclude XKMS and ABSTAIN votes. The numbers are clear if not overwhelming. SCVP garnered just a bit more than 50% of the votes. OCSP got just under 30%. DVCS got almost 16% and CVP 4%. Based on the strawpoll, SCVP has the most support from respondents. OCSP also has relatively strong support. DVCS and CVP fall short in this category. (2) The protocol MUST satisfy the requirements specified in RFC 3379. It is my opinion that each of the four protocols *could* satisfy the requirements, given sufficient time. The question before us, though, is how close are the current proposals. Based on the respective compliance matrices, and the subsequent analysis performed by Denis, none of the current submissions is perfect. However, the compliance matrices imply that SCVP is closer to satisfying the requirements than either OCSP or DVCS. While no one performed that same analysis for Denis' matrix, I believe that CVP's compliance is roughly that of SCVP, since it was designed using 3379. So, SCVP and CVP seem closest to the requirements at this time. (3) The protocol be mature enough for completion soon. OCSP and DVCS have been RFCs for some time, so their base protocols are clearly mature. However, the extensions that are needed to support DPD/DPV are significantly less mature. Moreover, the changes needed by clients and servers to make use of these extensions to OCSP are substantial, vastly greater in complexity that the current OCSP protocol. Thus the installed OCSP client & server base for OCSP does not represent a significant head start for this protocol vs. the others. CVP is a very recent development, having cycled at Internet-Draft just a few times. SCVP is not an RFC, but is currently at draft 11, we have implementation experience, and it has been tweaked and polished throughout the requirements process. In short, SCVP appears best positioned for swift completion. Based on this analysis, we are affirming the results of the strawpoll, and SCVP is *the* PKIX WG protocol for DPD/DPV. I want to encourage everyone to stay involved, even if your favorite protocol was not SCVP. We are in the home stretch, but there is still work to do. Here is the way forward, in our view. Denis' analysis of the SCVP compliance matrix raises an initial set of questions. These issues need to be discussed on the list, and if the WG agrees that changes to SCVP are required, modifications will be proposed (by the editors, or WG membership). Once rough consensus is achieved on those issues, the editors can submit a new draft. At that point, we intend to initiate WG Last Call. Any final issues can be hammered out, then the document forwarded to the ADs. Steve and I want to thank everyone for their participation. First, the editors should be applauded for their efforts in developing the compliance matrices. We know that was a difficult and time-consuming task. Denis' analysis of the SCVP, OCSP, and DVCS compliance matrices was a very significant contribution. Those that reviewed, commented, and voted in the strawpoll put in significant efforts as well. Finally, we need to recognize Denis and Russ for completing RFC 3379, which made it possible to complete the selection process. Thanks, Tim Polk Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KHpK923304 for ietf-pkix-bks; Thu, 20 Feb 2003 09:51:20 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KHpId23299 for ; Thu, 20 Feb 2003 09:51:18 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1KHp9Es090718; Thu, 20 Feb 2003 12:51:09 -0500 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1KHp4DK098566; Thu, 20 Feb 2003 12:51:05 -0500 Importance: Normal Sensitivity: Subject: Re: SMIME and disclaimers To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: chris.gilbert@Royalmail.com, ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Thu, 20 Feb 2003 12:50:47 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 02/20/2003 12:51:07 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: Leaving a disclaimer outside the signature base removes most of the point of having one. It needs to be in the footer or in a signed attribute. Having it in the certificate is fine if you always want the disclaimer - see the many NR discussions on this list, as you know. Tom Gindin I/T Architect - Security IBM Business Consulting Services - Public Sector Phone (301) 803-3460 pgut001@cs.auckland.ac.nz (Peter Gutmann)@mail.imc.org on 02/19/2003 11:30:41 PM Sent by: owner-ietf-pkix@mail.imc.org To: chris.gilbert@Royalmail.com, ietf-pkix@imc.org cc: Subject: Re: SMIME and disclaimers chris.gilbert@Royalmail.com writes: >Discounting whether disclaimers carry any worthwhile legal weight, >technically is it feasible to add a disclaimer to outgoing SMIME messages at >the outgoing server without breaking the signature ? Stick 'em in the unsigned attributes. Benefits: - Doesn't break the signature. - It's much easier for users to ignore them there than tacked onto the end of the message. Actually, another option would be: - Put them in the certPolicies. God knows there's everything else in there already, so one more piece of cruft won't hurt. Peter :-). Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KFvPE17855 for ietf-pkix-bks; Thu, 20 Feb 2003 07:57:25 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KFvNd17851 for ; Thu, 20 Feb 2003 07:57:24 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26772; Thu, 20 Feb 2003 16:59:40 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA15065; Thu, 20 Feb 2003 15:51:39 +0100 Message-ID: <3E54FA48.20203@bull.net> Date: Thu, 20 Feb 2003 16:54:48 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: David Chadwick CC: pkix Subject: Re: I-D ACTION:draft-ietf-pkix-ldap-ac-schema-00.txt References: <200302191204.HAA20120@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, Would it be possible that you re-issue this draft according to the requirements for the presentation of an RFC, i.e. 72 characters per line, 58 lines per page, a page numbering and no "tab" characters ? Thank you. Denis > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. > > Title : Internet X.509 Public Key Infrastructure LDAP Schema > for X.509 Attribute Certificates > Author(s) : D. Chadwick, M. Sahalayev > Filename : draft-ietf-pkix-ldap-ac-schema-00.txt > Pages : 0 > Date : 2003-2-14 > > This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-pkix-ldap-ac-schema-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1KCfsh05806 for ietf-pkix-bks; Thu, 20 Feb 2003 04:41:54 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1KCfrd05800 for ; Thu, 20 Feb 2003 04:41:53 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09442; Thu, 20 Feb 2003 07:38:03 -0500 (EST) Message-Id: <200302201238.HAA09442@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-tap-00.txt Date: Thu, 20 Feb 2003 07:38:03 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Trusted Archive Protocol (TAP) Author(s) : C. Wallace, S. Chokhani Filename : draft-ietf-pkix-tap-00.txt Pages : 34 Date : 2003-2-19 A Trusted Archive Authority (TAA) is a service that supports long- term non-repudiation by maintaining secure storage of cryptographically refreshed information. This document defines a set of transactions for interacting with a Trusted Archive Authority (TAA) and establishes a means of representing archived information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-tap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-tap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-tap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-19142304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-tap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-tap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-19142304.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1K4V1Q20057 for ietf-pkix-bks; Wed, 19 Feb 2003 20:31:01 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1K4Uxd20050 for ; Wed, 19 Feb 2003 20:30:59 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1K4Uvx8019690; Thu, 20 Feb 2003 17:30:57 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1K4Ufg18311; Thu, 20 Feb 2003 17:30:41 +1300 Date: Thu, 20 Feb 2003 17:30:41 +1300 Message-Id: <200302200430.h1K4Ufg18311@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: chris.gilbert@Royalmail.com, ietf-pkix@imc.org Subject: Re: SMIME and disclaimers Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: chris.gilbert@Royalmail.com writes: >Discounting whether disclaimers carry any worthwhile legal weight, >technically is it feasible to add a disclaimer to outgoing SMIME messages at >the outgoing server without breaking the signature ? Stick 'em in the unsigned attributes. Benefits: - Doesn't break the signature. - It's much easier for users to ignore them there than tacked onto the end of the message. Actually, another option would be: - Put them in the certPolicies. God knows there's everything else in there already, so one more piece of cruft won't hurt. Peter :-). Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1JC8UP11636 for ietf-pkix-bks; Wed, 19 Feb 2003 04:08:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1JC8Sd11632 for ; Wed, 19 Feb 2003 04:08:29 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20120; Wed, 19 Feb 2003 07:04:39 -0500 (EST) Message-Id: <200302191204.HAA20120@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldap-ac-schema-00.txt Date: Wed, 19 Feb 2003 07:04:38 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure LDAP Schema for X.509 Attribute Certificates Author(s) : D. Chadwick, M. Sahalayev Filename : draft-ietf-pkix-ldap-ac-schema-00.txt Pages : 0 Date : 2003-2-14 This document describes an LDAP schema for X.509 attribute certificates (ACs). Each AC is broken down into a set of attribute types. These attributes can then be stored in an AC entry. An object class is defined for this AC entry. Each attribute type uses an existing LDAP syntax, so that no new matching rules need to be defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldap-ac-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-14105229.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-ac-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-ac-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-14105229.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1J6XoL00645 for ietf-pkix-bks; Tue, 18 Feb 2003 22:33:50 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1J6Xnd00641 for ; Tue, 18 Feb 2003 22:33:49 -0800 (PST) Received: from sesione (unknown[12.242.154.153]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <2003021906334605300qm8dme>; Wed, 19 Feb 2003 06:33:46 +0000 From: "Khaja Ahmed" To: , Subject: RE: SMIME and disclaimers Date: Tue, 18 Feb 2003 22:35:34 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <00256CD0.004A3E20.00@postoffice.co.uk> Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The simplest way would be to add the disclaimer in the footer of all outbound messages like the footer / signature in your own message below. Of course if you want it to be done only for signed messages it will be harder. Most likely you will need some custom MIME aware thing to create and add a MIME body part (assuming multipart)with the disclaimer text. Either of these things can be handled at the mail client or the server that relays your mail. Khaja > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]On Behalf Of > chris.gilbert@Royalmail.com > Sent: Monday, February 17, 2003 5:31 AM > To: ietf-pkix@imc.org > Subject: SMIME and disclaimers > > > > > > All, > > I don't imagine for a moment that we're the only ones looking at > this issue. > > Discounting whether disclaimers carry any worthwhile legal > weight, technically > is it feasible to add a disclaimer to outgoing SMIME messages at > the outgoing > server without breaking the signature ? The multipart nature of > MIME suggests > that it is at least plausible to place the disclaimer in its own > MIME boundary > such that it doesn't interfere with signed portions in the parts > of the message > that originate at the client. > > Opinions appreciated. > > Chris > > Royal Mail is a trading name of Royal Mail Group plc. Registered > in England and > Wales. > Registered number 4138203. Registered office at 148 Old Street, > LONDON EC1V 9HQ > > This email and any attachments are confidential and intended > for the addressee > only. If you are not the named recipient, you must not use, > disclose, reproduce, > copy or distribute the contents of this communication. If you > have received this > in error, please contact the sender and then delete this email > from your system. > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1J0UlE21944 for ietf-pkix-bks; Tue, 18 Feb 2003 16:30:47 -0800 (PST) Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1J0Ukd21940 for ; Tue, 18 Feb 2003 16:30:46 -0800 (PST) Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA06179 for ; Wed, 19 Feb 2003 11:30:40 +1100 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpd0s41k8; Wed Feb 19 11:30:24 2003 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA03438 for ; Wed, 19 Feb 2003 11:30:23 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdaR3cV_; Wed Feb 19 11:29:54 2003 Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA19552 for ; Wed, 19 Feb 2003 11:29:54 +1100 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Wed, 19 Feb 2003 10:29:29 +1000 Message-ID: <73388857A695D31197EF00508B08F29806EE1767@ntmsg0131.corpmail.telstra.com.au> Thread-Topic: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Thread-Index: AcLXkKu0MatTsbDaTN2xB3LELvBaTgAF1/Aw From: "Manger, James H" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1J0Ukd21941 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, I am not entirely clear which fields you are referring to when you say "the Alg.Id field" and "the algorithm location". I guess these refer to components within a certificate's subjectPublicKeyInfo field. > specify the necessary constraints in the parameters of the algorithm location. The subjectPublicKeyInfo.algorithm.parameters field is already needed to specify parameters for the public key: NULL for an RSA key; {p, q, g} for a DSA key; a curve for an ECDSA key; {prime, base, len} for a DH key; ... Do you really think we should change all these existing syntaxes to include constraints, instead of placing the constraints in their own field? The constraints are specific to signature or encryption algorithms -- not directly to key types. There are a number of supporting techniques (hash functions, mask generation algorithms etc) that many signature and encryption algorithms have in common. These are the sort of items that we will want to constrain. However, these supporting techniques have nothing to do with the type of key. Combining key parameters with constraints on supporting techniques does not seem that sensible. > "My software should only use alg X, but display as alg Y" Is this referring to my point 4? This is not what I was suggesting. The criticality flag in an extension allows you to choose your own balance between security & backward-compatibility. Placing constraints in the subjectPublicKeyInfo.algorithm.parameters fields does not allow this choice. > -----Original Message----- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Wednesday, 19 February 2003 7:56 AM > To: Manger, James H; IETF-PKIX@imc.org > Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg > > I disagree that the problem of specifing the constraints is based on the > fact that the restraints are specified in the Alg.Id field. > > I do agree that the constraints should be expressed differently. I > think that the signature and public key parameters structures should be > specified as different structures. I am not even sure that I like the > fact that PSS is using DEFAULT parameters. (This has the potential to > slow down moving to a larger hash algorithm since the size of the > certificate is going to increase.) > > My preference would be to specify the necessary constraints in the > parameters of the algorithm location. > > I disagree that there is a reason to worry about specifying a constraint > that says "My software should only use alg X, but display as alg Y". > This is an internal issue to the software and should not be imposed > externally. > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H > > Sent: Tuesday, February 11, 2003 10:30 PM > > > > Constraining the algorithms with which a key is used is good > > security practice so there is sense in including a constraint > > to this effect in a certificate. However, I am not sure that: > > a) the subjectPublicKeyInfo field should hold this constraint and > > b) the syntax for the constraint should be an Alg.Id. > > > > Jim Schaad's comments #8 and #13 (confusion about how to > > compare the parameters of a signature or encryption with the > > parameters from subjectPublicKeyInfo) are due to the > > constraint being specified with an Alg.Id, which is not quite > > appropriate (e.g. by including a saltLength field that is irrelevant). > > > > Consider other possible (& reasonable?) constraints that you > > may wish to express: > > > > 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 > > as the hash algorithm. > > [Cannot be expressed as RSASSA-PSS-params only has a single > > hashAlgorithm field] > > > > 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP > > encryption, but not with any other algorithms.> > > [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > > > > 3* Only use id-sha1-with-dss-signature for signing. > > [Cannot be expressed as this signature OID has NULL > > parameters, but {p, q, g} need to be specified.] > > > > 4* Tell your signing software only to use RSASSA-PSS with > > this key, but don't prevent some legacy apps from accepting > > your signature. > > [Cannot be expressed as legacy apps reject the cert as they > > don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, > > the constraint needs to be in a non-critical extension.] > > > > > > A better solution would be to define a new extension to hold > > the constraint. Mark it critical to guarantee enforcement of > > the constraint, or non-critical to supply the info but > > maintain some backward compatibility. > > > > algorithmConstraints EXTENSION ::= { > > SYNTAX AlgConstraintsSyntax > > IDENTIFIED By id-ce-algorithmConstraints } > > > > AlgConstraintsSyntax ::= ...???????... this is the hard bit > > > > > > A simple syntax would be: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID is in the sequence. > > > > Or the same simple syntax with more complex semantics: > > SEQUENCE OF OBJECT IDENTIFIER > > -- An Alg.Id is acceptable iff its OID > > -- and all the OIDs of any other Alg.Ids > > -- in its parameters field (inc. defaults if absent) > > -- are all in the sequence > > > > Or something really generic: > > Filter -- see X.511 > > -- applied to a "virtual entry" containing just the > > Alg.Id in question > > > > Or... > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IKwZw15486 for ietf-pkix-bks; Tue, 18 Feb 2003 12:58:35 -0800 (PST) Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IKwYd15481 for ; Tue, 18 Feb 2003 12:58:34 -0800 (PST) Received: from smtp1.pacifier.net (smtp1 [64.255.237.171]) by mx4.pacifier.net (Postfix) with ESMTP id 80C176A7D4; Tue, 18 Feb 2003 12:58:36 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 2E97F6EF22; Tue, 18 Feb 2003 12:58:35 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Manger, James H'" , Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Tue, 18 Feb 2003 12:56:29 -0800 Message-ID: <004201c2d790$36df6df0$1600a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmail.telstra.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I disagree that the problem of specifing the constraints is based on the fact that the restraints are specified in the Alg.Id field. I do agree that the constraints should be expressed differently. I think that the signature and public key parameters structures should be specified as different structures. I am not even sure that I like the fact that PSS is using DEFAULT parameters. (This has the potential to slow down moving to a larger hash algorithm since the size of the certificate is going to increase.) My preference would be to specify the necessary constraints in the parameters of the algorithm location. I disagree that there is a reason to worry about specifying a constraint that says "My software should only use alg X, but display as alg Y". This is an internal issue to the software and should not be imposed externally. jim > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Manger, James H > Sent: Tuesday, February 11, 2003 10:30 PM > To: IETF-PKIX@imc.org > Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - > binding key to 1 alg > > > > Constraining the algorithms with which a key is used is good > security practice so there is sense in including a constraint > to this effect in a certificate. However, I am not sure that: > a) the subjectPublicKeyInfo field should hold this constraint and > b) the syntax for the constraint should be an Alg.Id. > > Jim Schaad's comments #8 and #13 (confusion about how to > compare the parameters of a signature or encryption with the > parameters from subjectPublicKeyInfo) are due to the > constraint being specified with an Alg.Id, which is not quite > appropriate (e.g. by including a saltLength field that is irrelevant). > > Consider other possible (& reasonable?) constraints that you > may wish to express: > > 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 > as the hash algorithm. > [Cannot be expressed as RSASSA-PSS-params only has a single > hashAlgorithm field] > > 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP > encryption, but not with any other algorithms. > [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] > > 3* Only use id-sha1-with-dss-signature for signing. > [Cannot be expressed as this signature OID has NULL > parameters, but {p, q, g} need to be specified.] > > 4* Tell your signing software only to use RSASSA-PSS with > this key, but don't prevent some legacy apps from accepting > your signature. > [Cannot be expressed as legacy apps reject the cert as they > don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, > the constraint needs to be in a non-critical extension.] > > > A better solution would be to define a new extension to hold > the constraint. Mark it critical to guarantee enforcement of > the constraint, or non-critical to supply the info but > maintain some backward compatibility. > > algorithmConstraints EXTENSION ::= { > SYNTAX AlgConstraintsSyntax > IDENTIFIED By id-ce-algorithmConstraints } > > AlgConstraintsSyntax ::= ...???????... this is the hard bit > > > A simple syntax would be: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID is in the sequence. > > Or the same simple syntax with more complex semantics: > SEQUENCE OF OBJECT IDENTIFIER > -- An Alg.Id is acceptable iff its OID > -- and all the OIDs of any other Alg.Ids > -- in its parameters field (inc. defaults if absent) > -- are all in the sequence > > Or something really generic: > Filter -- see X.511 > -- applied to a "virtual entry" containing just the > Alg.Id in question > > Or... > > > ---------- > From: Jim Schaad [mailto:jimsch@nwlink.com] > Sent: Saturday, 8 February 2003 4:59 AM > Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt > > ... > > ---------- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Wednesday, 8 January 2003 12:30 AM > > Title : Additional Algorithms and Identifiers > for RSA Cryptography for use in the Internet X.509 Public Key > Infrastructure Certificate and Certificate Revocation List > (CRL) Profile > Author(s) : R. Housley, B. Kaliski > Filename : draft-ietf-pkix-rsa-pkalgs-00.txt > Pages : 22 > Date : 2003-1-6 > > This document supplements RFC 3279. It describes the > conventions for using the RSASSA-PSS signature algorithm, the > RSAES-OAEP key transport algorithm, and additional one-way > hash functions with the PKCS #1 version 1.5 signature > algorithm in the Internet X.509 Public Key Infrastructure > (PKI). Encoding formats, algorithm identifiers, and > parameter formats are specified. > http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IHZ2M09034 for ietf-pkix-bks; Tue, 18 Feb 2003 09:35:02 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IHZ0d09030 for ; Tue, 18 Feb 2003 09:35:00 -0800 (PST) Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1IHYoSc065014; Tue, 18 Feb 2003 12:34:50 -0500 Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1IHYlcC113754; Tue, 18 Feb 2003 12:34:47 -0500 Importance: Normal Sensitivity: Subject: Re: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 To: Holger Ebel Cc: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Tue, 18 Feb 2003 12:34:24 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.11 +SPRs MIAS5EXFG4, MIAS5AUFPV and DHAG4Y6R7W, MATTEST |November 8th, 2002) at 02/18/2003 12:34:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Holger: With respect to your digestAlgorithm and digestEncryptionAlgorithm points, the use of the term "digestEncryptionAlgorithm" really applies best to RSA signatures and only to one mode of those. PKCS#1has two distinct signature schemes: the traditional one, which is the only mode defined within RFC 2313 and 2437 and is described in the new RFC 3447 as RSASSA-PKCS1-V1_5-SIGN; and the newly recommended one, which is described in RFC 3447 as RSASSA-PSS-SIGN. In the older mode, the plain text encrypted by the RSA key contains the actual algorithm ID of the hash algorithm used - see RFC 3447 section 9.2 step 2 or RFC 2437 section 9.2.1 step 2. In the newer mode, the hash algorithm used cannot be recovered so easily from the plain text - see RFC 3447 section 9.1.1 and 9.1.2. This is especially the case because the mask generation function is typically based on a hash algorithm which need not be the same as the hash algorithm used in the signature calculation, although it is recommended in RFC 3447 that they be the same. Please note that although RFC 3447 is brand new, it is essentially the same as PKCS#1 version 2.1, whichhas been actively under development since at least September 1999 (including the PSS scheme) and was finalized in June 2002. Tom Gindin Holger Ebel @mail.imc.org on 02/17/2003 09:28:56 AM Sent by: owner-ietf-pkix@mail.imc.org To: ietf-pkix@imc.org cc: Subject: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 Hello, after working through these specs and decoding many example signatures I still have the following questions regarding the meaning of the signatureAlgorithm/digestEncryptionAlgorithm in these standards mentioned above. (To be more precise, the appearance of these in the SignerInfo structure of the SignedData contentType) If this topic does not belong to this list, it would be nice if someone can point me at the responsible mailing list. Please note that I use the term signatureAlgorithm for the combination of a digest and a digestEncryption algorithm in the following mail. (To be honest, this could also be the subject of my mail: Do the successors of PKCS#7 mean "SignatureAlgorithm" alike.) ;-) With respect, I would like to summarize first how I get these standards. PKCS#7 PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm and a digestEncryptionAlgorithm. So if the signatureAlgorithm is md5WithRSAEncryption (1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5) and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1). Or if the signatureAlgorithm is sha1WithRSAEncryption (1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (1.3.14.3.2.26) and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1). (The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2) All the PKCS#7 'samples' I've found strictly follows these rules, there is a digest- and a digestEncryption algorithm. CMS CMS (RFC 2630/3369/3370) introduced the term signatureAlgorithm in the SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm of PKCS#7 while the digestAlgorithm field still remains. Here the value of the signatureAlgorithm must contain a signatureAlgoOID (sha1WithRSAEncryption, md5WithRSAEncryption, RipeMD160WithRsaEncryption or sha1WithDsaEncryption) and the digestAlgorithmValue must be equals to the one defined in the signatureAlgorithm. The only Exception is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 in conjunction with a digestAlgorithm as defined in PKCS#7 for backward compatibility. When this OID is used, it is assumed that the digestAlgo is SHA-1, but may be also MD5. (RFC 3370) The CMS samples I've found (e.g. csrc.nist.gov/pki/testing/x509paths.html, ISISMTT TestSuite) following these rules. Now my questions: (1) Did I get the standard mentioned above right regarding the signatureAlgo/digestEncryptionAlgorithm? (2) How should I handle a CMS (2630) signature where the value of the digestAlgorithm does not match the 'included' digestAlgorithm in the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo OID at the digestInfo field and a Sha1WithRSA OID in the signature- algorithm field). (3) When a component claims that it can produce valid RFC 2630 signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 the only exception from the rule? (4) Having the following signatureAlgorithms, is the usage of these for PKCS#7 and RFC 2630 signatures allowed and correct? (having valid signatures according the corresponding standard) --------------------------------------------------------------------------- SignatureAlgorithm digestAlgo (I) signatureAlgo (RFC 2630) (II) digestEncrAlgo(PKCS#7) --------------------------------------------------------------------------- (A) sha1WithRSA 1.3.14.3.2.26 (Ia) 1.2.840.113549.1.1.5 (1.2.840.113549.1.1.5) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (B) md5WithRSA 1.2.840.1x9.2.5 (Ia) 1.2.840.113549.1.1.4 (1.2.840.113549.1.1.4) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (C) ripeMD160WithRsa 1.3.36.3.2.1 (Ia) 1.3.36.3.3.1.2 (1.3.36.3.3.1.2) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (D) sha1WithDsa 1.3.14.3.2.26 (Ia) 1.2.840.10040.4.3 (1.2.840.10040.4.3) (Ib) 1.2.840.10040.4.1 (?) (II) 1.2.840.10040.4.1 --------------------------------------------------------------------------- (5) Or is the signatureAlgorithm check performed this way (for 2630): If the signatureAlgo field contains a digestEncryptionOID, the signatureAlgo is the digestEncryptionOID plus the digestOID. If the signatureAlgo field contains a signatureAlgo, the signatureAlgo equals the found signatureAlgo. The included digestAlgo is not observed/ must be the same as the one which is contained in the signatureAlgo? Thanks in advance Best Regards Holger Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1IGaus07439 for ietf-pkix-bks; Tue, 18 Feb 2003 08:36:56 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1IGatd07435 for ; Tue, 18 Feb 2003 08:36:55 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h1IGapA8009306; Tue, 18 Feb 2003 17:36:51 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <022b01c2d76a$8788cd30$0500a8c0@arport> From: "Anders Rundgren" To: "Hallam-Baker, Phillip" , "'Eric Norman'" , "PKIX list" References: Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Tue, 18 Feb 2003 17:26:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Phill, >I did look into fixing SMTP to upport that mode. But SMTP is >really, really yukky, there are a lot of moving parts, lots of legacy >stuff. When I wrote my posting the other day I referred to SMTP which sure is as yucky as you say. However, MIME-encode mail which is pretty much standard, offers an "X-" extension which is similar to an X.509.v3 non-critical extension. Using MIME this should not be a problem. If you look into this mail you will find an X-OLE-something which hardly can be anything but an undocumented MS-feature. Anders Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HFKZa26720 for ietf-pkix-bks; Mon, 17 Feb 2003 07:20:35 -0800 (PST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HFKYd26716 for ; Mon, 17 Feb 2003 07:20:34 -0800 (PST) Received: from [192.168.0.244] ([67.118.214.168]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0HAG00HYSLAAVR@mta6.snfc21.pbi.net> for ietf-pkix@imc.org; Mon, 17 Feb 2003 07:20:36 -0800 (PST) Date: Mon, 17 Feb 2003 07:20:33 -0800 From: Aram Perez Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP In-reply-to: To: PKIX Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Microsoft-Entourage/10.1.1.2418 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallam-Baker, Phillip wrote: [snip] >> So how does something like XKMS solve this? Because it >> appears that the >> issue is not just Alice getting Bob's certificate, it's how >> does Alice get >> all the intermediate certificates (that may or may not have a >> unique email). > > XKMS does not impose a particular data model on the problem. The XKMS > service can use local knowledge of the trust topology structure to > assist finding the certification paths and can pre-calculate and cache > such paths. The directory approach forces the client to do this work > since the searches required do not conform to the restrictions of the > data model. It appears that XKMS is moving the problem from the client to the server, since how does the XKMS service learn the "trust topology structure" for a new unknown user. Regards, Aram Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HERxM24692 for ietf-pkix-bks; Mon, 17 Feb 2003 06:27:59 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HERvd24688 for ; Mon, 17 Feb 2003 06:27:57 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id IAA24828 for ; Sat, 22 Feb 2003 08:11:36 +0100 Received: from authentidate.de (input.authentidate.de [192.168.42.73]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1HERk929476 for ; Mon, 17 Feb 2003 15:27:46 +0100 X-Authentication-Warning: gate.wisnet.de: Host input.authentidate.de [192.168.42.73] claimed to be authentidate.de Message-ID: <3E50F1A8.7000701@authentidate.de> Date: Mon, 17 Feb 2003 15:28:56 +0100 From: Holger Ebel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: signatureAlgorithm in PKCS#7/RFC 2630/RFC 3369/70 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, after working through these specs and decoding many example signatures I still have the following questions regarding the meaning of the signatureAlgorithm/digestEncryptionAlgorithm in these standards mentioned above. (To be more precise, the appearance of these in the SignerInfo structure of the SignedData contentType) If this topic does not belong to this list, it would be nice if someone can point me at the responsible mailing list. Please note that I use the term signatureAlgorithm for the combination of a digest and a digestEncryption algorithm in the following mail. (To be honest, this could also be the subject of my mail: Do the successors of PKCS#7 mean "SignatureAlgorithm" alike.) ;-) With respect, I would like to summarize first how I get these standards. PKCS#7 PKCS#7 1.5 (RFC 2315) clearly distinguishes between a digestAlgorithm and a digestEncryptionAlgorithm. So if the signatureAlgorithm is md5WithRSAEncryption (1.2.840.113549.1.1.4), the digestAlgorithm is md5 (1.2.840.113549.2.5) and the digestEncryptionAlgorithm is RSA (1.2.840.113549.1.1.1). Or if the signatureAlgorithm is sha1WithRSAEncryption (1.2.840.113549.1.1.5), the digestAlgorithm is sha1 (1.3.14.3.2.26) and the digestEncryptionAlgorithm is again RSA (1.2.840.113549.1.1.1). (The same for RipeMD160WithRsaEncryption (1.3.36.3.3.1.2) All the PKCS#7 'samples' I've found strictly follows these rules, there is a digest- and a digestEncryption algorithm. CMS CMS (RFC 2630/3369/3370) introduced the term signatureAlgorithm in the SignerInfo structure, which has 'replaced' the digestEncryptionAlgorithm of PKCS#7 while the digestAlgorithm field still remains. Here the value of the signatureAlgorithm must contain a signatureAlgoOID (sha1WithRSAEncryption, md5WithRSAEncryption, RipeMD160WithRsaEncryption or sha1WithDsaEncryption) and the digestAlgorithmValue must be equals to the one defined in the signatureAlgorithm. The only Exception is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 in conjunction with a digestAlgorithm as defined in PKCS#7 for backward compatibility. When this OID is used, it is assumed that the digestAlgo is SHA-1, but may be also MD5. (RFC 3370) The CMS samples I've found (e.g. csrc.nist.gov/pki/testing/x509paths.html, ISISMTT TestSuite) following these rules. Now my questions: (1) Did I get the standard mentioned above right regarding the signatureAlgo/digestEncryptionAlgorithm? (2) How should I handle a CMS (2630) signature where the value of the digestAlgorithm does not match the 'included' digestAlgorithm in the signatureAlgorithm field. (e.g. having a RIPEMD160 digestAlgo OID at the digestInfo field and a Sha1WithRSA OID in the signature- algorithm field). (3) When a component claims that it can produce valid RFC 2630 signatures, is the usage of the 'old' RSA OID 1.2.840.113549.1.1.1 the only exception from the rule? (4) Having the following signatureAlgorithms, is the usage of these for PKCS#7 and RFC 2630 signatures allowed and correct? (having valid signatures according the corresponding standard) --------------------------------------------------------------------------- SignatureAlgorithm digestAlgo (I) signatureAlgo (RFC 2630) (II) digestEncrAlgo(PKCS#7) --------------------------------------------------------------------------- (A) sha1WithRSA 1.3.14.3.2.26 (Ia) 1.2.840.113549.1.1.5 (1.2.840.113549.1.1.5) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (B) md5WithRSA 1.2.840.1x9.2.5 (Ia) 1.2.840.113549.1.1.4 (1.2.840.113549.1.1.4) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (C) ripeMD160WithRsa 1.3.36.3.2.1 (Ia) 1.3.36.3.3.1.2 (1.3.36.3.3.1.2) (Ib) 1.2.840.113549.1.1.1 (II) 1.2.840.113549.1.1.1 (D) sha1WithDsa 1.3.14.3.2.26 (Ia) 1.2.840.10040.4.3 (1.2.840.10040.4.3) (Ib) 1.2.840.10040.4.1 (?) (II) 1.2.840.10040.4.1 --------------------------------------------------------------------------- (5) Or is the signatureAlgorithm check performed this way (for 2630): If the signatureAlgo field contains a digestEncryptionOID, the signatureAlgo is the digestEncryptionOID plus the digestOID. If the signatureAlgo field contains a signatureAlgo, the signatureAlgo equals the found signatureAlgo. The included digestAlgo is not observed/ must be the same as the one which is contained in the signatureAlgo? Thanks in advance Best Regards Holger Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HDUpH23210 for ietf-pkix-bks; Mon, 17 Feb 2003 05:30:51 -0800 (PST) Received: from mail3.consignia.com (mail.royalmail.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HDUod23205 for ; Mon, 17 Feb 2003 05:30:50 -0800 (PST) Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 2A16B18FB17 for ; Mon, 17 Feb 2003 13:31:06 +0000 (GMT) Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 00256CD0.004A4053 ; Mon, 17 Feb 2003 13:31:01 +0000 X-Lotus-FromDomain: POSTOFFICE From: chris.gilbert@Royalmail.com To: ietf-pkix@imc.org Message-ID: <00256CD0.004A3E20.00@postoffice.co.uk> Date: Mon, 17 Feb 2003 13:30:35 +0000 Subject: SMIME and disclaimers Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I don't imagine for a moment that we're the only ones looking at this issue. Discounting whether disclaimers carry any worthwhile legal weight, technically is it feasible to add a disclaimer to outgoing SMIME messages at the outgoing server without breaking the signature ? The multipart nature of MIME suggests that it is at least plausible to place the disclaimer in its own MIME boundary such that it doesn't interfere with signed portions in the parts of the message that originate at the client. Opinions appreciated. Chris Royal Mail is a trading name of Royal Mail Group plc. Registered in England and Wales. Registered number 4138203. Registered office at 148 Old Street, LONDON EC1V 9HQ This email and any attachments are confidential and intended for the addressee only. If you are not the named recipient, you must not use, disclose, reproduce, copy or distribute the contents of this communication. If you have received this in error, please contact the sender and then delete this email from your system. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1HAkKY18071 for ietf-pkix-bks; Mon, 17 Feb 2003 02:46:20 -0800 (PST) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1HAkJd18067 for ; Mon, 17 Feb 2003 02:46:19 -0800 (PST) Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id h1HAkDU25292 for ; Mon, 17 Feb 2003 19:46:13 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate52.nec.co.jp [10.7.69.191]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id h1HAkD320053 for ; Mon, 17 Feb 2003 19:46:13 +0900 (JST) Received: from vcheck1.nes.nec.co.jp (vcheck1.nes.nec.co.jp [10.109.63.71]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id h1HAkCH04920 for ; Mon, 17 Feb 2003 19:46:12 +0900 (JST) Received: from smtp4.necst.nec.co.jp (localhost [127.0.0.1]) by vcheck1.nes.nec.co.jp (8.9.3/3.7W-01/28/03) with ESMTP id TAA21479 for ; Mon, 17 Feb 2003 19:46:08 +0900 (JST) From: k-fujino@pb.jp.nec.com Received: by smtp4.necst.nec.co.jp id h1HAjor11096 ; Mon, 17 Feb 2003 19:45:50 +0900 (JST) Received: from ecpc15 by smtp4.necst.nec.co.jp with SMTP id h1HAjme11093 for ; Mon, 17 Feb 2003 19:45:50 +0900 (JST) To: ietf-pkix@imc.org Subject: SkipCerts Question [RFC3280] Reply-To: k-fujino@pb.jp.nec.com Message-Id: <20030217194548k-fujino@smtp.necst.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.08D] ID:NECST0 Date: Mon, 17 Feb 2003 19:45:48 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear all, We are now testing our certificate path validation program in Japan. And I have a question on the "SkipCerts" in the RFC3280. Would you please tell me? ----- According to the RFC3280, 4.2.1.12 Policy Constraints If the requireExplicitPolicy field is present, the value of requireExplicitPolicy indicates the number of additional certificates that may appear in the path before an explicit policy is required for the entire path. ----- If there is a certificate path like the following, cert0 cert1 cert2 and if the cert1 has the requireExplicitPolicy=1, is the cert2 required to have an explicit policy or not ? (Is the value applied to the cert1 which has the requireExplicitPolicy=1?) I don't think the cert2 is required to have it, but I'm not sure. Regards, Kozo -------------------------------------------------------- Kozo FUJINO (TEL: +81-82-264-8544 FAX: +81-82-264-8549) NEC System Technologies, Ltd. Hiroshima, Japan Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1GCvvU02850 for ietf-pkix-bks; Sun, 16 Feb 2003 04:57:57 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1GCvtd02841 for ; Sun, 16 Feb 2003 04:57:56 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Sun, 16 Feb 2003 05:56:21 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/16/2003 07:59:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: somewhat addenda to question about '83 OSI .... while iso/x3s3.3 couldn't have a work item for standard that violated OSI (i.e. HSP, high-speed protocol .... direct from level4/transport to LAN/MAC interface which sits in the middle of level3/network) .... x3s3.3 could have a work item that studied HSP. note also that IP also violated OSI ... since it is a layer that sits between level4/transport layer and level3/network layer .... the inter-networking layer. however, IETF doesn't have any qualms about having IP interface directly to LAN/MAC. as before ... internet archeological references from 82/83: http://www.garlic.com/~lynn/rfcietf.htm#history 20th anniversary of the internet! http://www.garlic.com/~lynn/2002p.html#38 20th anniversary of the internet http://www.garlic.com/~lynn/2002p.html#39 20th anniversary of the internet http://www.garlic.com/~lynn/2002q.html#22 20th anniversary of the internet and a little more thread drift, a recent archeological reference to something else that i was doing about that time http://www.garlic.com/~lynn/2003c.html#75 The relational model and relational algebra - why did SQL become the industry standard? and the whole thing about thread between loosely-coupled, sysplex, high availability, cluster, supercomputers, and electronic commerce: http://www.garlic.com/~lynn/2001i.html#52 -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1G9XMb19687 for ietf-pkix-bks; Sun, 16 Feb 2003 01:33:22 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1G9XLd19683 for ; Sun, 16 Feb 2003 01:33:21 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h1G9XEoC001697; Sun, 16 Feb 2003 10:33:14 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <005901c2d59d$07343940$0500a8c0@arport> From: "Anders Rundgren" To: "Hallam-Baker, Phillip" , "PKIX list" , "Eric Norman" , "Russ Housley" References: Subject: Getting the encryption key. Was: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Sun, 16 Feb 2003 10:23:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Going off on a tangent here, but it's a tangent that doesn't seem >to have been explored. >Why can't Alice get Bob's up-to-date encryption certificate >when she clicks on Bob's mailto URL? Right on Eric! I think the whole S/MIME-thing is pretty awkward to use for anybody. I have toyed with the following idea for a while: An SMTP-extension holding an optional "encryption certificate lookup object" would allow a more dynamic use of encryption. This object should preferably be distributed as a part of a standard e-mail message, and hopefully "land" in the address book completely automatically. This extension could also be supplied in an X.509 extension. Phill: XKMS et. al. _do_ need an SMTP extension to become fully useful. To go from a mailto directly, doesn't this require an enhanced mailto URL unless mail clients are supposed to do XKMS/LDAP/CertStore "fishing" using DNS SRV-records etc? I'm not so sure that such "fishing" will prove to be very fruitful as it requires mail-providers (e-mail domain owners) to maintain keys that often come from other domains (TTP CAs). That needs yet another special-purpose directory "behind the scene" to work. Since you anyway have to upgrade e-mail and browser software on a regular basis due to viruses and "improvements", I can't see that an encrypted-mailto URL and an SMTP-extension would be such major PITAs. Existing systems would not break AFAIK. All other suggestions also effectively require as a minimum (apart from possible CA changes), updated e-mail client software. But is this a W3C, SMTP, S/MIME, or PKIX-issue? Anders R Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1G2bwt16804 for ietf-pkix-bks; Sat, 15 Feb 2003 18:37:58 -0800 (PST) Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1G2bud16800 for ; Sat, 15 Feb 2003 18:37:56 -0800 (PST) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 22765805 for ietf-pkix@imc.org; Sat, 15 Feb 2003 20:37:59 -0600 Date: Sat, 15 Feb 2003 20:37:58 -0600 (CST) From: Eric Norman To: PKIX list Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/signed; BOUNDARY="-2140662931-1575522160-1045363079=:20274"; protocol="application/x-pkcs7-signature"; micalg=sha1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2140662931-1575522160-1045363079=:20274 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: On Sat, 15 Feb 2003, Hallam-Baker, Phillip wrote: > I did look into fixing SMTP to upport that mode. But SMTP is > really, really yukky, there are a lot of moving parts, lots of legacy > stuff. I'm thinking something simpler. Methinks I confused the idea by using the phrase "mailto URL". Perhaps I should have referred to it as whatever you click on to send electronic mail to someone. Trying to do it with SMTP would couple the message encryption process with the process of injecting the message into the delivery system; I don't think that's a good thing. > The proposal I am pushing is using the DNS to locate a discovery > service (SRV already supports this), with my preferred discovery service > being XKMS locate which is a lot simpler to implement than LDAP. Since some browsers already support a MIME type for receiving encryption certificates, I'm thinking that the "send me mail" link that someone puts on (for instance) their home page includes an attribute that says how to fetch their encryption key (probably from their home page file space in this case). > > -----Original Message----- > > From: Eric Norman [mailto:ejnorman@doit.wisc.edu] > > Sent: Saturday, February 15, 2003 6:04 PM > > To: PKIX list > > Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP > > > > > > On Fri, 14 Feb 2003, Aram Perez wrote: > > > > > Hallam-Baker, Phillip wrote: > > > > > > > Alice wants to send email to Bob > > > > Alice does not know Bob's Certificate > > > > Alice does know Bob's email address. > > > > Bob's name is not unique > > > > > > But Bob's email is unique. Why can't Alice look up Bob's > > certificate by his > > > unique email address? > > > > Going off on a tangent here, but it's a tangent that doesn't seem > > to have been explored. > > > > Why can't Alice get Bob's up-to-date encryption certificate > > when she clicks on Bob's mailto URL? > > > > > > Eric Norman > > > > "I may be just a butterfly, > > but watch out if I flap my wings". > > > > > > > Eric Norman "Congress shall make no law restricting the size of integers that may be multiplied together, or the number of times that an integer may be multiplied by itself, or the modulus by which an integer may be reduced". ---2140662931-1575522160-1045363079=:20274 Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename="smime.p7s" MIIHNQYJKoZIhvcNAQcCoIIHJjCCByICAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBUswggKVMIIB/qADAgECAgICejANBgkqhkiG9w0BAQQFADCB kTELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xIDAe BgNVBAsTF0ludGVybmV0MiBEZW1vbnN0cmF0aW9uMRgwFgYDVQQDEw9IRVBL SSBDbGllbnQgQ0EwHhcNMDIwODI0MTkwNjE5WhcNMDMwOTI5MTkwNjE5WjCB vzELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xKzAp BgNVBAsTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxFDAS BgNVBAMTC0VyaWMgTm9ybWFuMSUwIwYJKoZIhvcNAQkBFhZlam5vcm1hbkBk b2l0Lndpc2MuZWR1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALReNRkixlpT urV2ogd3BCWgxihjl0j6+a7EGnV+SCCBsqjWqKcVTCedD49lTbHLnmgejUd+ tfdiy5Dg+//ZpMUCAwEAAaMQMA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQB/5AydG4TKKO6ZFiI9d/m03260pf4lBp81mlD3B9IQl0ofJ1gl NtZlTZyC1N4x+c82eqMNBIBrcA/dcaoy0LyNWRrRtt+et+JkNXfrhLuwUWtQ NR8Gq3i00C2th4DienwNbh9FoVo6gru6sC3i4TRxwKnDbKus6r2xvKlOQt3E azCCAq4wggIXoAMCAQICAgG/MA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTAeFw0wMTA3MTcxODI0MzFaFw0yMzA2MTMxODI0MzFaMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6xU1OJP0g+mU9srwrQLC zWXAMlkv3DKb+lEugUQTTV8/bi+ZgcG3oan7ZcxpiN+k+3biz8vcxIbxCMcI NZvi0u0mdDoLjaAtZtqvORMgbm3XkJhzgtGMmaxFLUBlhebSdd7YeV4/X4lJ FAIE3hcaXWayirI+jwGkaD0UgELs3ysCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQCkRVbjdpKkibnoRNqoDGWxu1Bno4eS pw0GlIwkveeyhURWvBA2neUzBuFlG2JinTx7/YtHYf19vwzN+GSEzv7cUl0l p27Uc0iamMYxzCCkgSvwgOn87FrdNgVA6e1QYvjzu0XdvbVyBqr0zH5a0Cel /kzV7l/+idyjGPeNHC1lqzGCAbIwggGuAgEBMIGYMIGRMQswCQYDVQQGEwJV UzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAwHgYD VQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50ZXJu ZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBDQQIC AnowCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wMzAyMTYwMjM3NThaMCMGCSqGSIb3DQEJBDEWBBQM 2sjHgxQ9JQ3OagWYgfifZnH3STBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAOiXwOXJnwBTanVRscWYC OBZgTiQbo+akgbhM5FxjOawhCG5FUf5uW1oVnh5RWJ36n0Brif8wMjNGpQ96 4Q5viQ== ---2140662931-1575522160-1045363079=:20274-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1G1hjG15541 for ietf-pkix-bks; Sat, 15 Feb 2003 17:43:45 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1G1hhd15535 for ; Sat, 15 Feb 2003 17:43:43 -0800 (PST) Received: from MOU1WNEXC03.verisign.com (verisign.com [65.205.251.57] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1G1h8Cq026386; Sat, 15 Feb 2003 17:43:08 -0800 (PST) Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id <15SG6RHQ>; Sat, 15 Feb 2003 17:43:45 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Eric Norman'" , PKIX list Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Sat, 15 Feb 2003 17:43:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000E_01C2D532.EE2309F0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C2D532.EE2309F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Eric, I did look into fixing SMTP to upport that mode. But SMTP is really, really yukky, there are a lot of moving parts, lots of legacy stuff. The proposal I am pushing is using the DNS to locate a discovery service (SRV already supports this), with my preferred discovery service being XKMS locate which is a lot simpler to implement than LDAP. It would also be possible to implement an HTTP interface on top of NAPTR but SRV is not quite up to it. Phill > -----Original Message----- > From: Eric Norman [mailto:ejnorman@doit.wisc.edu] > Sent: Saturday, February 15, 2003 6:04 PM > To: PKIX list > Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP > > > On Fri, 14 Feb 2003, Aram Perez wrote: > > > Hallam-Baker, Phillip wrote: > > > > > Alice wants to send email to Bob > > > Alice does not know Bob's Certificate > > > Alice does know Bob's email address. > > > Bob's name is not unique > > > > But Bob's email is unique. Why can't Alice look up Bob's > certificate by his > > unique email address? > > Going off on a tangent here, but it's a tangent that doesn't seem > to have been explored. > > Why can't Alice get Bob's up-to-date encryption certificate > when she clicks on Bob's mailto URL? > > > Eric Norman > > "I may be just a butterfly, > but watch out if I flap my wings". > > > ------=_NextPart_000_000E_01C2D532.EE2309F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNjAx NDM0NFowIwYJKoZIhvcNAQkEMRYEFLaOdBtxrDJmgq/xwB/wiK1VC7BMMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAZ27+j6Nk4T8vhV21mOSHVHNojpfOI0c4IK2ByZuK+rjR9ncT jJHQY7z/n2JhoS99Jo689Y6c7ZFx0rejWH9kBLGGh5PcZUrVR3fdcQcKzdMgvCPFuJjwuCUjUk3d FtYLhhyPUke7QDYvY48HB0OmhquDvIoRYplv0SFNe9nSp1sAAAAAAAA= ------=_NextPart_000_000E_01C2D532.EE2309F0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1FN3t912951 for ietf-pkix-bks; Sat, 15 Feb 2003 15:03:55 -0800 (PST) Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1FN3rd12947 for ; Sat, 15 Feb 2003 15:03:54 -0800 (PST) Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.5.9) with ESMTP-TLS id 22764708 for ietf-pkix@imc.org; Sat, 15 Feb 2003 17:03:55 -0600 Date: Sat, 15 Feb 2003 17:03:52 -0600 (CST) From: Eric Norman To: PKIX list Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/signed; BOUNDARY="-2140662931-1674615169-1045350236=:20274"; protocol="application/x-pkcs7-signature"; micalg=sha1 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---2140662931-1674615169-1045350236=:20274 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 14 Feb 2003, Aram Perez wrote: > Hallam-Baker, Phillip wrote: > > > Alice wants to send email to Bob > > Alice does not know Bob's Certificate > > Alice does know Bob's email address. > > Bob's name is not unique > > But Bob's email is unique. Why can't Alice look up Bob's certificate by his > unique email address? Going off on a tangent here, but it's a tangent that doesn't seem to have been explored. Why can't Alice get Bob's up-to-date encryption certificate when she clicks on Bob's mailto URL? Eric Norman "I may be just a butterfly, but watch out if I flap my wings". ---2140662931-1674615169-1045350236=:20274 Content-Type: APPLICATION/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename="smime.p7s" MIIHNQYJKoZIhvcNAQcCoIIHJjCCByICAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBUswggKVMIIB/qADAgECAgICejANBgkqhkiG9w0BAQQFADCB kTELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xIDAe BgNVBAsTF0ludGVybmV0MiBEZW1vbnN0cmF0aW9uMRgwFgYDVQQDEw9IRVBL SSBDbGllbnQgQ0EwHhcNMDIwODI0MTkwNjE5WhcNMDMwOTI5MTkwNjE5WjCB vzELMAkGA1UEBhMCVVMxEjAQBgNVBAgTCVdpc2NvbnNpbjEQMA4GA1UEBxMH TWFkaXNvbjEgMB4GA1UEChMXVW5pdmVyc2l0eSBvZiBXaXNjb25zaW4xKzAp BgNVBAsTIkRpdmlzaW9uIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3kxFDAS BgNVBAMTC0VyaWMgTm9ybWFuMSUwIwYJKoZIhvcNAQkBFhZlam5vcm1hbkBk b2l0Lndpc2MuZWR1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBALReNRkixlpT urV2ogd3BCWgxihjl0j6+a7EGnV+SCCBsqjWqKcVTCedD49lTbHLnmgejUd+ tfdiy5Dg+//ZpMUCAwEAAaMQMA4wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQQFAAOBgQB/5AydG4TKKO6ZFiI9d/m03260pf4lBp81mlD3B9IQl0ofJ1gl NtZlTZyC1N4x+c82eqMNBIBrcA/dcaoy0LyNWRrRtt+et+JkNXfrhLuwUWtQ NR8Gq3i00C2th4DienwNbh9FoVo6gru6sC3i4TRxwKnDbKus6r2xvKlOQt3E azCCAq4wggIXoAMCAQICAgG/MA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTAeFw0wMTA3MTcxODI0MzFaFw0yMzA2MTMxODI0MzFaMIGRMQswCQYDVQQG EwJVUzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAw HgYDVQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50 ZXJuZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBD QTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA6xU1OJP0g+mU9srwrQLC zWXAMlkv3DKb+lEugUQTTV8/bi+ZgcG3oan7ZcxpiN+k+3biz8vcxIbxCMcI NZvi0u0mdDoLjaAtZtqvORMgbm3XkJhzgtGMmaxFLUBlhebSdd7YeV4/X4lJ FAIE3hcaXWayirI+jwGkaD0UgELs3ysCAwEAAaMTMBEwDwYDVR0TAQH/BAUw AwEB/zANBgkqhkiG9w0BAQQFAAOBgQCkRVbjdpKkibnoRNqoDGWxu1Bno4eS pw0GlIwkveeyhURWvBA2neUzBuFlG2JinTx7/YtHYf19vwzN+GSEzv7cUl0l p27Uc0iamMYxzCCkgSvwgOn87FrdNgVA6e1QYvjzu0XdvbVyBqr0zH5a0Cel /kzV7l/+idyjGPeNHC1lqzGCAbIwggGuAgEBMIGYMIGRMQswCQYDVQQGEwJV UzESMBAGA1UECBMJV2lzY29uc2luMRAwDgYDVQQHEwdNYWRpc29uMSAwHgYD VQQKExdVbml2ZXJzaXR5IG9mIFdpc2NvbnNpbjEgMB4GA1UECxMXSW50ZXJu ZXQyIERlbW9uc3RyYXRpb24xGDAWBgNVBAMTD0hFUEtJIENsaWVudCBDQQIC AnowCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wMzAyMTUyMzAzNTVaMCMGCSqGSIb3DQEJBDEWBBRQ thBxUKrT7qSsejv637RZlBEwADBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzAN BggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAARAa53giZokvQ29QOk/3Uac fOBLLClrPA359mjCos4w3GmFoJ0eQrMZrk6puESEclpl8rSvYbwGF2qkPKQ5 KNT3WQ== ---2140662931-1674615169-1045350236=:20274-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1F2LIp00573 for ietf-pkix-bks; Fri, 14 Feb 2003 18:21:18 -0800 (PST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1F2LHd00569 for ; Fri, 14 Feb 2003 18:21:17 -0800 (PST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53] (may be forged)) by pigeon.verisign.com (8.12.1/) with ESMTP id h1F2JLiq011738; Fri, 14 Feb 2003 18:19:21 -0800 (PST) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <15SCLY2C>; Fri, 14 Feb 2003 18:21:19 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Aram Perez'" , PKIX Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 14 Feb 2003 18:21:19 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_01B4_01C2D46F.052A45B0"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_01B4_01C2D46F.052A45B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > I'm afraid I don't understand. AFAIK, LDAP/X.500/SQL all can > be set up to > return a certificate given a unique email. Is the issue that > companies/organizations do not set up their LDAP/X.500/SQL > data stores to > allow this? You can go rabbit hunting with a howitzer, but that does not make it the best choice. The point is that you do not need anything more than exact match and in fact you will not have anything else available in the internet case. So you do better with a system that is designed for that and that alone. > So how does something like XKMS solve this? Because it > appears that the > issue is not just Alice getting Bob's certificate, it's how > does Alice get > all the intermediate certificates (that may or may not have a > unique email). XKMS does not impose a particular data model on the problem. The XKMS service can use local knowledge of the trust topology structure to assist finding the certification paths and can pre-calculate and cache such paths. The directory approach forces the client to do this work since the searches required do not conform to the restrictions of the data model. Phill ------=_NextPart_000_01B4_01C2D46F.052A45B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNTAy MjEyMVowIwYJKoZIhvcNAQkEMRYEFPQF1G19lfa0J7dPhpqTmaJXnj2oMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAnR05EXITfrTDOmXsILsASszfS9dB+AY5+AIZFFbC5jyL0CB0 eefam+1XtVelDeH79xZ47ItiSZKBsVdOXHyS0QKCiP/HRzacPefLLMrBSC6qbS9CP1UK9FG4rTn7 53AdJXkKMtKOWr0qeEMlx79u7gOYMD1jSG5gafrhCORQhlYAAAAAAAA= ------=_NextPart_000_01B4_01C2D46F.052A45B0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EM0gE23435 for ietf-pkix-bks; Fri, 14 Feb 2003 14:00:42 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EM0fd23424 for ; Fri, 14 Feb 2003 14:00:41 -0800 (PST) Subject: surrogate/agent addenda (long) To: epay@ca0.net Cc: "Anders Rundgren" , ietf-pkix@imc.org, "Torsten Hentschel" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 15:02:02 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 05:02:11 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I claim that I can model an operational environment in terms of entities and permissions (for simplification attributes are also modeled as a kind of permission). Registry is defined to be the method that an operatinal environment uses to map entities to permissions. A registry may be a single operational thing or it may be made up multiple things both explicit and implicit. Digital signatures and public keys are used to authenticate entities to the operational environment. The operatinnal environment uses public keys in the registry to represent entities (since they are unique to the authentication of the entity). The mapping between public keys and permissions is a function of the registry entry. CA/PKI further extends the kinds of permissions to "delagation". A CA entity/public key is given the permission of delegation. A CA uses its own registry to provide a mapping between entities, public keys, and permissions. A CA then signs a static, stale copy of some of the fields in its registry and calls it a certificate. An operational environment can authenticate delegated permissions from a signed certificate by using the public key of a CA entity from its own registry. Just for some convention I'll call delegation entities: surrogates/agents. Full blown PKI defines the possibility of a multi-level delegation as a trust hierarchy. So my repeated assertion is that if the operational environment accesses a surrogate/agent registry entry (local, remote, online, etc) then correspond surrogate/agenty certificate can be shown to beredundant and superfluous. So, I've managed to explain this redundant and superfluous characteristic in a number of different ways: 1) a registry entry can contain anything that a certificate can contain, therefor all fields that can occur in a certificate can also be placed in a surrogate/agent registry entry. Also, for every field that can exist in a certificate can be placed in a registry entry. When all fields from a certificate are placed in a registry entry, the certificate can be compressed to zero bytes. These certificates aren't actually redundant and superfluous, they are just zero bytes. 2) the creation of a registry entry for a surrogate/agent is equivalent to a registration authority business process. anything that is done during a CA's RA process can be done during the creation of a registry entry for the surrogate/agent. If necessary, this can be viewed as caching the certificate in the surrogate/agent registry entry. Then while the certificate isn't strictly redundant and superfluous, any transmission of the certificate is redundant and superfluous since the operational environment already has access to the cached entry. This is especially useful when the inclusion of a certificate in a transmission represents a painful bloating of the total transmission size. 3) when there is a directly accessable registry entry (local, remote, online, etc) for a surrogate/agent, then the certificate may just represent information indirection .... somewhat like DNS system mapping of hostname to ip-address. the registry entry contains some value that can be matched to a field in the certificate. This provides a indirection mapping between the permissions in the registry entry and the entity's public key in the certificate (authenticated & deligated by the CA signatures and the CA entry in a directly accessable registry entry). However, since nay value that can occur in a certificate can also be placed in the registry entry, the public key from certificate entry can be directly placed in the surrogate/agent registry entry, eliminating the indirection provided by the certificate and making the use of the certificate redundant and superfluous . 4) an operational environment may require direct access to a surrogate/agent registry entry (local, remote, online, etc) because of permissions expressed in terms of aggregation information (information that is maintained in the registry entry that represents information aggregation and is a difficult paradigm for a static, stale certificate) or permissions expressed in terms of real-time or near real-time information (again difficult paradigm for a static, stale certificate). 5) If a static, stale certificate provides an identifier that is used to index a surrogate/agent registry entry (local, remote, online, etc) then it is also possible to include the same identifier as part of the message digitally signed by the surrogate/agent. As before, such a surrogate/agent registry entry can include anything that a certificate can include, including the public key of the surrogate/agent. By directly placing the public key in the surrogate/agent registry entry, and directly accessing the surrogate/agent registry entry using an identifier from the signed message, then the signed message can be authenticated using the public key from the directly accessed surrogate/agent registry entry. The directly accessed surrogate/agent registry entry can contain any other field that might exist in the certificate, including all possible permission values. Since the digital signed message can be authenticated without having to resort to the certificate and since the directly accessed surrogate/agent registry entry can contain any field that a certificate can contain, the static, stale certificate transmitted as part of the message is redundant and superfluous . The simplest scenario for a static, stale certificate is in an operational environment that only accesses a CA delegation registry entries and permissions are solely established on the basis of the contents of the CA registry entry and the contents of the certificate. This is the employee certificate that is used for door entry. The door entry operational environment only contains the public key of one or more CAs. The door is opened purely based on being able to validate the CA's signature on the certificate and then validate the employee's signature using the public key in the certificate. For opening the door, there is no recourse to any employee specific entry. This is the typical "offline" door operation typical of low value situations. Higher value door operations tend to be "online" in the sense that they directly access employee specific registry information. Such online permission entry can be based on timely information (like has the employee been fired within the past couple hours) or aggregation (what other things has the employee done in the recent past). It is in the accessing of the employee registry entry (local, remote, online, etc) for timely and/or aggregated information that makes the use of the static, stale certificate redundant and superfluous. Similarly a portable device can either be "offline" in the sense that its operation is totally determined from just a CA public key registry and a static, stale certificate (and doesn't have direct access to the surrogate/agent registry entry). Lets say there are large number of "public" portable device and anybody can utilize any device so long as they have a valid certificate for device useage. However, a certificate can become redundant and superluous if the device has a surrogate/agent specific registry entry that it references (since it is possible to register any information that might be found in a certificate, in a surrogate/agent registry entry). A portable device that might contain a surrogate/agent specific registry entry might be a owner-specific paradigm (i.e. the surrogate/agent registry entry in the device corresponds to the owner). A onwer-specific paradigm could be implemented with certificates if the certificate contained the device specific identifier. The device would only work when a certificate was presented that contained the device-specific identifier in one of the certificate fields. Lets say we are looking at a hardware token implementation as keys for automobiles. For an owner specific paradigm there can be a certificate/PKI based implementation or a certificate-less based implementation. In the PKI-based implementation the automobile's internal permission registry table contains one or more CA public keys. The car starts for any hardware token that has a digital signed certificate that specifies the specific automobile serial number and authenticated by any of the CA public keys (and of course the hardware token signs a valid message that is authenticated from the public key in the certificate). The certificate-less implementation replaces the CA public keys in the automobile's internal permission registry table with public keys of the owner's hardware tokens. Then only the directly listed hardware tokens are able to start the automobile. In the certificate-less scheme, there would be a administration mode used in conjunction with a valid hardware token to add/delete public keys in the automobile's registry. In the PKI-based implementation for "owned" automobile operation, it becomes somewhat more problamatical to invalidate hardware tokens (aka certificates) for the automobile. One method would be to create registry entries for invalidated certificates (aka public key/hardware token). However, I would assert as soon as surrogate/agent specific entries are required for invalidated public keys .... then the infrastructure has been established making certificate-less operation KISS (aka static, stale certificates being redundant and superfluous). Just create a positive list/registry of public keys .... possibly totally eliminating the delegation permission associated with CA public keys. The automobile registry than has permissions like administrative mode, start automobile, open trunk, open doors, etc for each public key (aka hardware token). It is problamatical whether CA public keys would be retained in the automobile registry solely associated with manufacture and service operation. Standard automobile operation would be straight certificate-less with the owner's hardware tokens being directly registered in the automobile's registry table. However, there might be non-ownership related permissions like various service operations. There could be a manufacture CA delegation permissions associated with service operation and independent of automobile serial/identification. The manufacture's public key would be in the automobile's table with delegation permissions. The manufacture would sign public key certificates for service operations, enabling service specific permissions for all cars from the manufacture. However, CRLs really become a nightmare in this situation. I would contend that a much KISS solution is that the service operation goes online with the manufacture (in much the same way that POS terminal do online transaction) and that the automobile authenticates the service operation by accessing the manufacture's online database. The manufacture's public key is still in the automobile registry .... not for purposes of validatting certificates but for purposes of validating online communcation with the manufacture for authentication of real-time service organization delegation. As a result, the operation is online with direct access to registry entries for service organizations and therefor service organization certificates are redundant and superfluous. past references regarding compression of certificates to zero bytes: http://www.garlic.com/~lynn/aepay3.htm#aadsrel1 AADS related information http://www.garlic.com/~lynn/aepay3.htm#aadsrel2 AADS related information ... summary http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt)) http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures http://www.garlic.com/~lynn/aadsm5.htm#spki2 Simple PKI http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/aepay10.htm#76 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ? http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key? http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates past references to methodology of registry operation caching certificate kind of information (making certificate transmission redundant and superfluous) http://www.garlic.com/~lynn/aepay3.htm#x959discus X9.59 discussions at X9A & X9F http://www.garlic.com/~lynn/aepay6.htm#dspki5 use of digital signatures and PKI (addenda) http://www.garlic.com/~lynn/aepay7.htm#3dsecure 3D Secure Vulnerabilities? Photo ID's and Payment Infrastructure http://www.garlic.com/~lynn/aadsm4.htm#8 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm8.htm#softpki16 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm8.htm#softpki20 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#cfppki4 CFP: PKI research workshop http://www.garlic.com/~lynn/aepay10.htm#33 pk-init draft (not yet a RFC) http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2001d.html#69 Block oriented I/O over IP http://www.garlic.com/~lynn/2001e.html#43 Can I create my own SSL key? http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key? http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties http://www.garlic.com/~lynn/2002f.html#57 IBM competes with Sun w/new Chips http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends http://www.garlic.com/~lynn/2002m.html#17 A new e-commerce security proposal http://www.garlic.com/~lynn/2003.html#52 SSL & Man In the Middle Attack past discussions of static, stale certificate issues vis-a-vis aggregated/timely information: http://www.garlic.com/~lynn/aadsmail.htm#vbank Statistical Attack Against Virtual Banks (fwd) http://www.garlic.com/~lynn/aadsmore.htm#hcrl3 Huge CRLs http://www.garlic.com/~lynn/aadsmore.htm#client2 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsmore.htm#client4 Client-side revocation checking capability http://www.garlic.com/~lynn/aadsm2.htm#arch4 A different architecture? (was Re: certificate path http://www.garlic.com/~lynn/aadsm2.htm#availability A different architecture? (was Re: certificate path http://www.garlic.com/~lynn/aadsm2.htm#mauthauth Human Nature http://www.garlic.com/~lynn/aadsm2.htm#pkikrb PKI/KRB http://www.garlic.com/~lynn/aadsm4.htm#01 redundant and superfluous (addenda) http://www.garlic.com/~lynn/aadsm4.htm#0 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact... http://www.garlic.com/~lynn/aadsm5.htm#pkimort PKI: Evolve or Die http://www.garlic.com/~lynn/aadsm7.htm#rhose10 when a fraud is a sale, Re: Rubber hose attack http://www.garlic.com/~lynn/aadsm8.htm#softpki2 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI http://www.garlic.com/~lynn/aadsm8.htm#softpki14 DNSSEC (RE: Software for PKI) http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI http://www.garlic.com/~lynn/aadsm9.htm#softpki24 Software for PKI http://www.garlic.com/~lynn/aadsm9.htm#cfppki8 CFP: PKI research workshop http://www.garlic.com/~lynn/aadsmail.htm#variations variations on your account-authority model (small clarification) http://www.garlic.com/~lynn/aepay2.htm#aadspriv Account Authority Digital Signatures ... in support of x9.59 http://www.garlic.com/~lynn/aepay3.htm#openclose open CADS and closed AADS http://www.garlic.com/~lynn/aepay4.htm#comcert16 Merchant Comfort Certificates http://www.garlic.com/~lynn/aepay4.htm#x9flb12 LB#12 Protection Profiles http://www.garlic.com/~lynn/aepay6.htm#crlwork do CRL's actually work? http://www.garlic.com/~lynn/aepay6.htm#dspki3 use of digital signatures and PKI (addenda) http://www.garlic.com/~lynn/aadsm11.htm#39 ALARMED ... Only Mostly Dead ... RIP PKI .. addenda http://www.garlic.com/~lynn/aadsm11.htm#40 ALARMED ... Only Mostly Dead ... RIP PKI ... part II http://www.garlic.com/~lynn/aadsm11.htm#42 ALARMED ... Only Mostly Dead ... RIP PKI ... part III http://www.garlic.com/~lynn/aadsm12.htm#20 draft-ietf-pkix-warranty-ext-01 http://www.garlic.com/~lynn/aadsm12.htm#26 I-D ACTION:draft-ietf-pkix-usergroup-01.txt http://www.garlic.com/~lynn/aadsm12.htm#27 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#32 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki http://www.garlic.com/~lynn/aadsm12.htm#52 First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#54 TTPs & AADS Was: First Data Unit Says It's Untangling Authentication http://www.garlic.com/~lynn/aadsm12.htm#55 TTPs & AADS (part II) http://www.garlic.com/~lynn/aadsm13.htm#0 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#1 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#2 OCSP value proposition http://www.garlic.com/~lynn/aadsm13.htm#3 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#4 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#6 OCSP and LDAP http://www.garlic.com/~lynn/aadsm13.htm#7 OCSP and LDAP http://www.garlic.com/~lynn/aepay10.htm#31 some certification & authentication landscape summary from recent threads http://www.garlic.com/~lynn/aepay10.htm#34 some certification & authentication landscape summary from recent threads http://www.garlic.com/~lynn/aepay10.htm#37 landscape & p-cards http://www.garlic.com/~lynn/aepay10.htm#75 Invisible Ink, E-signatures slow to broadly catch on (addenda) http://www.garlic.com/~lynn/98.html#0 Account Authority Digital Signature model http://www.garlic.com/~lynn/98.html#41 AADS, X9.59, & privacy http://www.garlic.com/~lynn/2000.html#37 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2000.html#42 "Trusted" CA - Oxymoron? http://www.garlic.com/~lynn/2000b.html#92 Question regarding authentication implementation http://www.garlic.com/~lynn/2001.html#67 future trends in asymmetric cryptography http://www.garlic.com/~lynn/2001c.html#8 Server authentication http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security' site. http://www.garlic.com/~lynn/2001d.html#8 Invalid certificate on 'security' site. http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key? http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me http://www.garlic.com/~lynn/2001m.html#41 Solutions to Man in the Middle attacks? http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties http://www.garlic.com/~lynn/2002k.html#8 Avoiding JCL Space Abends http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification http://www.garlic.com/~lynn/2002n.html#40 Help! Good protocol for national ID card? http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', how curruptable are they to http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', how curruptable are they to -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1ELgxh22973 for ietf-pkix-bks; Fri, 14 Feb 2003 13:42:59 -0800 (PST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1ELgwd22969 for ; Fri, 14 Feb 2003 13:42:58 -0800 (PST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h1ELh151025600 for ; Fri, 14 Feb 2003 13:43:01 -0800 (PST) Received: from [10.10.110.50] ([65.200.9.2]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id HABIZO00.NT0 for ; Fri, 14 Feb 2003 13:43:00 -0800 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 14 Feb 2003 13:42:58 -0800 Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP From: Aram Perez To: PKIX Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hallam-Baker, Phillip wrote: > >>>> May be in different environments different such >> technologies might be >>>> usefull. What I am missing in this discussion is a clear list of >>>> requirements for certificate retrieval. >>> >>> Alice wants to send email to Bob >>> Alice does not know Bob's Certificate >>> Alice does know Bob's email address. >>> Bob's name is not unique >> >> But Bob's email is unique. Why can't Alice look up Bob's >> certificate by his >> unique email address? > > That is the whole big-thing point as Rowan Atkinson would say. I'm afraid I don't understand. AFAIK, LDAP/X.500/SQL all can be set up to return a certificate given a unique email. Is the issue that companies/organizations do not set up their LDAP/X.500/SQL data stores to allow this? > > >> Can you please restate exactly what this "Web of Trust cert >> path discovery >> requirement" is? > > OK, you want to sent a meesage from UC Irvine to the Sorbone Paris. > There is a certification path through the HEBCA bridge, the > FBCA, le Ponte Authoritee Certification Franglaise and le Ecole > Nationalle Ponte Authoritee Certification. > > So to get from A to B you have to know that there is a trust > relationship that goes through the four bridge CAs, it is also a pretty > strong one that is maintained under fairly strict scrutiny. But getting > from A to B is going to be either inefficient or impossible unless you > know that there is a structure here you can exploit. So how does something like XKMS solve this? Because it appears that the issue is not just Alice getting Bob's certificate, it's how does Alice get all the intermediate certificates (that may or may not have a unique email). Aram Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EL2iX22002 for ietf-pkix-bks; Fri, 14 Feb 2003 13:02:44 -0800 (PST) Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EL2hd21998 for ; Fri, 14 Feb 2003 13:02:43 -0800 (PST) Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <1T4XVLL6>; Fri, 14 Feb 2003 16:02:39 -0500 Message-ID: From: Carlisle Adams To: "'Jeffrey I. Schiller'" , Stephen Farrell Cc: ietf-pkix@imc.org, "Steven M. Bellovin" Subject: RE: AD Review of draft-ietf-pkix-rfc2510bis-07.txt Date: Fri, 14 Feb 2003 16:02:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2D46C.68244880" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2D46C.68244880 Content-Type: text/plain Hi Jeff, Thanks for your preliminary feedback on rfc2510bis-07.txt. We will split the references into Normative and Informational, as you suggest, and will add a more explicit reference in Section 2.2.2. As for your comment regarding the PKCS #10 protocol exchange over SSL (the model for certificate issuance employed by popular browsers), it is generally accepted that this mechanism is common and workable. It is also too limited for some environments. - It is not always the case that certificate issuance takes place over SSL-protected connections, and so total reliance upon the presence of an underlying secure channel seems unwise. It would be better to have protection mechanisms built into the issuance request/response protocol itself, if possible. - Passing a secret value along with the PKCS #10 in a form post, while authenticating the sender to some degree, does not authenticate the content of the PKCS #10: there is no cryptographic binding between the secret value and the data inside the PKCS #10 message. Again, conveying these together through a secure underlying transport such as SSL can help, but what if that transport isn't there? And, even if it is there, no binding exists once the two pieces pop out the other end, so if the CA doesn't act on this issuance request immediately, the value of the sender authentication is lost. It would be better to have a strong cryptographic binding between the shared secret used for sender authentication and the issuance request. - This has been discussed many times over the PKIX list over the past several years, but PKCS #10 does not readily accommodate key pairs that are to be used for purposes other than signing. If I have a key pair that can only be used for encryption, how can I use the private key to sign the PKCS #10 request? If I want to certify my Diffie-Hellman public key, how can I use my corresponding private key to sign the request (RFC 2875 provides a couple of mechanisms, but these do stretch the "spirit" of PKCS #10 somewhat). It would be better to have a protocol message (including subsequent challenge/response messages, if necessary) that can easily handle certificate issuance requests for different kinds of key pairs. - The syntax of PKCS #10 assumes that the requester already knows its own DistinguishedName (DN), as well as the DN of the CA. In many applications this will not be the case: as part of the issuance process, the CA will assign a DN to the entity and include this DN in the response (i.e., in the issued certificate). It would be better to have flexibility in the request message to allow the sender to be identified in some other way. - PKCS #10, even for environments in which it is a suitable technology, does not do anything more than request certificate issuance. Every other aspect of certificate life cycle management (update/renewal, revocation, recovery, etc.) needs protocol messages beyond PKCS #10. It would be better to have a single, comprehensive suite of protocols that encompasses the full life cycle of certificate use. For all the above reasons (and perhaps others that I couldn't remember off the top of my head), CMP/CRMF was created. In an attempt to accommodate the current browser-based solution, a PKCS #10 message can be carried in a CMP envelope, but this isn't really recommended. CMP/CRMF is intended to provide all the functionality of PKCS #10, while addressing every one of its limitations. Significant implementation and interoperability experience has shown that it does this quite successfully in many different kinds of environments. Carlisle. ------_=_NextPart_001_01C2D46C.68244880 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: AD Review of draft-ietf-pkix-rfc2510bis-07.txt

Hi Jeff,

Thanks for your = preliminary feedback on rfc2510bis-07.txt.  We will split the = references into Normative and Informational, as you suggest, and will = add a more explicit reference in Section 2.2.2.

As for your comment = regarding the PKCS #10 protocol exchange over SSL (the model for = certificate issuance employed by popular browsers), it is generally = accepted that this mechanism is common and workable.  It is also = too limited for some environments.

 - It is not = always the case that certificate issuance takes place over = SSL-protected connections, and so total reliance upon the presence of = an underlying secure channel seems unwise.  It would be better to = have protection mechanisms built into the issuance request/response = protocol itself, if possible.

 - Passing a = secret value along with the PKCS #10 in a form post, while = authenticating the sender to some degree, does not authenticate the = content of the PKCS #10:  there is no cryptographic binding = between the secret value and the data inside the PKCS #10 = message.  Again, conveying these together through a secure = underlying transport such as SSL can help, but what if that transport = isn't there?  And, even if it is there, no binding exists once the = two pieces pop out the other end, so if the CA doesn't act on this = issuance request immediately, the value of the sender authentication is = lost.  It would be better to have a strong cryptographic binding = between the shared secret used for sender authentication and the = issuance request.

 - This has = been discussed many times over the PKIX list over the past several = years, but PKCS #10 does not readily accommodate key pairs that are to = be used for purposes other than signing.  If I have a key pair = that can only be used for encryption, how can I use the private key to = sign the PKCS #10 request?  If I want to certify my Diffie-Hellman = public key, how can I use my corresponding private key to sign the = request (RFC 2875 provides a couple of mechanisms, but these do stretch = the "spirit" of PKCS #10 somewhat).  It would be better = to have a protocol message (including subsequent challenge/response = messages, if necessary) that can easily handle certificate issuance = requests for different kinds of key pairs.

 - The syntax = of PKCS #10 assumes that the requester already knows its own = DistinguishedName (DN), as well as the DN of the CA.  In many = applications this will not be the case:  as part of the issuance = process, the CA will assign a DN to the entity and include this DN in = the response (i.e., in the issued certificate).  It would be = better to have flexibility in the request message to allow the sender = to be identified in some other way.

 - PKCS #10, = even for environments in which it is a suitable technology, does not do = anything more than request certificate issuance.  Every other = aspect of certificate life cycle management (update/renewal, = revocation, recovery, etc.) needs protocol messages beyond PKCS = #10.  It would be better to have a single, comprehensive suite of = protocols that encompasses the full life cycle of certificate = use.


For all the above = reasons (and perhaps others that I couldn't remember off the top of my = head), CMP/CRMF was created.  In an attempt to accommodate the = current browser-based solution, a PKCS #10 message can be carried in a = CMP envelope, but this isn't really recommended.  CMP/CRMF is = intended to provide all the functionality of PKCS #10, while addressing = every one of its limitations.  Significant implementation and = interoperability experience has shown that it does this quite = successfully in many different kinds of environments.

Carlisle.

------_=_NextPart_001_01C2D46C.68244880-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EK7wD19081 for ietf-pkix-bks; Fri, 14 Feb 2003 12:07:58 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EK7ud19075 for ; Fri, 14 Feb 2003 12:07:56 -0800 (PST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1EK7JCq014332; Fri, 14 Feb 2003 12:07:19 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <15SFDBQR>; Fri, 14 Feb 2003 12:07:59 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Aram Perez'" , PKIX Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 14 Feb 2003 12:07:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_017A_01C2D43A.DCBEF910"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_017A_01C2D43A.DCBEF910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > >> May be in different environments different such > technologies might be > >> usefull. What I am missing in this discussion is a clear list of > >> requirements for certificate retrieval. > > > > Alice wants to send email to Bob > > Alice does not know Bob's Certificate > > Alice does know Bob's email address. > > Bob's name is not unique > > But Bob's email is unique. Why can't Alice look up Bob's > certificate by his > unique email address? That is the whole big-thing point as Rowan Atkinson would say. > Can you please restate exactly what this "Web of Trust cert > path discovery > requirement" is? OK, you want to sent a meesage from UC Irvine to the Sorbone Paris. There is a certification path through the HEBCA bridge, the FBCA, le Ponte Authoritee Certification Franglaise and le Ecole Nationalle Ponte Authoritee Certification. So to get from A to B you have to know that there is a trust relationship that goes through the four bridge CAs, it is also a pretty strong one that is maintained under fairly strict scrutiny. But getting from A to B is going to be either inefficient or impossible unless you know that there is a structure here you can exploit. Cf the difficulty of IP routing without the concept of clouds. Phill ------=_NextPart_000_017A_01C2D43A.DCBEF910 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNDIw MDc1OVowIwYJKoZIhvcNAQkEMRYEFAbNsccScq/07wbgrsCKsjY/mERGMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAbr+M907I8ebcwvZ1E1evWRqNlpL//cXFcT2jtsNkjNRdKVNK 76TzQPn6MRoar3wgoEqGXOu/sK2KTQtDoDoswgXWXh78GVgTZIPukxGA6V0vQypSW4WymfHw6RaB PqNOvCKmzcNgW4Z1/ahUJ9/EemEA7AfWTa4PbR+htBLT8FMAAAAAAAA= ------=_NextPart_000_017A_01C2D43A.DCBEF910-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIGr514139 for ietf-pkix-bks; Fri, 14 Feb 2003 10:16:53 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EIGnd14124 for ; Fri, 14 Feb 2003 10:16:49 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 10:31:24 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 01:18:19 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: one of the factors driving 7816 standardization/commoditization in the '80s was that 7816 was a portable computing device ... but was dependent upon somewhat ubiquitous deployment of (stationary) input/output stations. the spread of integrated portable input/output technology (cellphones & pds) in the early '90s started to chip away at the original 7816 target market (i.e. portable computing devices w/o requirement for ubiquitous input/output stations. further eroding this target market is the spread of numerous contractless/wireless technologies. a big part of the 7816 standardization was the requirement for physical interoperability between the portable 7816 devices and the input/output stations. contactless technologies enable arbitrary form-factors .... further chiping away at the 7816 market segment. one of the targets for iso 14443 is a current primary 7816 market segment, point-of-sale .... where the contact infrastructure is showing failures .... especially in high-traffic areas. contactless/wireless breaks the requirement for form-factor specific implementation (required by contact interoperability) and starts to allow interoperability with devices regardless of their form factor. for the aads chip strawman http://www.garlic.com/~lynn/index.html#aadstraw in '98 timeframe, i had somewhat facetiously claimed that i would take a $500 milspec part and cost-reduce it by two-orders of magnitude while improving the integrity. at an assurance panel in the TCPA track at the intel developer's conference, i claimed that the chip met all the function/requirements of the TPM (and was finalized much earlier) and was equivalent to the best of integrity from gov. agencies. One of the TCPA people in the audience commented that wasn't fair since I didn't have a committee of 200 people helping me. One of the people on the panel from a gov. TLA replied that it was possibly true except in the area of radiation hardening. other past tcpa related posts: http://www.garlic.com/~lynn/aadsm12.htm#0 maximize best case, worst case, or average case? (TCPA) http://www.garlic.com/~lynn/aadsm12.htm#14 Challenge to TCPA/Palladium detractors http://www.garlic.com/~lynn/aadsm12.htm#15 Challenge to TCPA/Palladium detractors http://www.garlic.com/~lynn/aadsm12.htm#16 Feasability of Palladium / TCPA http://www.garlic.com/~lynn/aadsm12.htm#17 Overcoming the potential downside of TCPA http://www.garlic.com/~lynn/aadsm12.htm#18 Overcoming the potential downside of TCPA http://www.garlic.com/~lynn/aadsm12.htm#19 TCPA not virtualizable during ownership change (Re: Overcoming the potential downside of TCPA) http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM] http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates - Security Issues http://www.garlic.com/~lynn/aadsm12.htm#63 Intertrust, Can Victor Shear Bring Down Microsoft? -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIGrq14137 for ietf-pkix-bks; Fri, 14 Feb 2003 10:16:53 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EIGmd14122 for ; Fri, 14 Feb 2003 10:16:48 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 10:16:18 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 01:18:18 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: one of the factors driving 7816 standardization/commoditization in the '80s was that 7816 was a portable computing device ... but was dependent upon somewhat ubiquitous deployment of (stationary) input/output stations. the appearance of intergrated portable input/output technology (cellphones & pds) in the early '90s started to chip away at the original 7816 target market. further eroding this target market is the spread of numerous contractless/wireless technologies. a big part of the 7816 standardization was the requirement for physical interoperability between the portable 7816 devices and the input/output stations. contactless technologies enable arbritrary form-factors .... further chiping away at the 7816 standardization. for the aads chip strawman http://www.garlic.com/~lynn/index.html#aadstraw in '98 timeframe, i had somewhat facetiously claimed that i would take a $500 milspec part and cost-reduce it by two-orders of magnitude while improving the integrity. at an assurance panel in the TCPA track at the intel developer's conference, i claimed that the chip met all the function/requirements of the TPM (and was finalized much earlier) and was equivalent to the best of integrity from gov. agencies. One of the TCPA people in the audience commented that wasn't fair since I didn't have a committee of 200 people helping me. One of the people on the panel from a gov. TLA replied that it was possibly true except in the area of radiation hardening. past tcpa related posts: -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EIGrX14138 for ietf-pkix-bks; Fri, 14 Feb 2003 10:16:53 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EIGnd14128 for ; Fri, 14 Feb 2003 10:16:50 -0800 (PST) Subject: RE: A challenge To: epay@ca0.net Cc: "Anders Rundgren" , ietf-pkix@imc.org, "Torsten Hentschel" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 14 Feb 2003 11:12:15 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/14/2003 01:18:20 PM MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384" Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384 Content-type: text/plain; charset=us-ascii the point was offline from the registry in login there is either 1) registry in the unit requiring logging in which contains a binding between some identity and the permission's (i.e. what things can log in and do). 2) or a purely ROM logging-in process that accepts any and all certificates signed by some prespecified CA .... and will perform whatever operations indicated by the certificate. in previous posting outlining a logging in scenario where there is some local registry in the device .... that is also certificate based .... the local device registry has both the list of acceptable public key certificates as well as some list of acceptable identification information from one or more certificates. The person presents a certificate, an attempt is made to validate the CA signature from the list of valid CA public keys in the registry .... and then some identification information contained in the certificate (say a person's name) is used to look up a registry entry for "certificates" that are allowed to log in and possibly their mapping to permissions and authorization. The public key from the certificate can be used to validate a signed message .... either before or after the lookup to see if there is a userid registry entry that corresponds to some identification field in the certificate (say person's name). My assertion is that in the case where there is registry of valid userids with a mapping to a value in the certificate .... the whole infrastructure is equivalent to "information indirection" paradigm provided by the certificate infrastructure. Say I buy a mobile device .... and want to establish my "ownership" by registering my certificate in the device as the true owner. So in the device are: 1) table of CA public keys 2) certificate with my public key and maybe my name signed by one of the CAs 3) login message 4) my signature on the login message I assert that the levels of indirection can be totally eliminated by instead replacing the table of CA public keys with a table of "owner" public keys .... and mapping the table of "owner" public keys directly to permissions. The table of CA public keys are eliminated and replaced with a table of owner "public keys". The registry mapping some certificate field unique identifier to permissions is eliminated and instead the registry of permissions are mapped directly to owner "public keys". The information indirection provided by the CA PKI infrastructure and the certificates are eliminated. The issue with regard to being offline from the registry is where there is no local registry which maps a certificate field to local device permissions. The local device has no access to the registry mapping certificate field to permissions ... and therefore must totally rely on information within the certificate as to what permissions are entitled. This "offline" infrastructure has only a CA table of public keys in the device. Certificates are presented signed by any of the acceptable CAs. The device then extracts all permissions directly from the certificate because it doesn't have online (or otherwise) access to the registry of permissions for this device. So my original assertion is that if the device has access (online or otherwise) to the registry of permissions for the device .... the indirection infrastructure provided by PKI certificate based operation can be collapsed to replacing the CA table of acceptable public keys with a separate registry of permissions to a single combined registry table containing the acceptable public keys and the associated permissions. So looking at PKI from the reverse standpoint, a PKI is an extension of the single combined registry table to a two level structure (in its basic form). The simple door entry scenario previously described is a singled combined registry table .... where the "owner" is directly mapped to permissions. The permission "owner" is able to authorize agents or surrogates by way of certificates. An "owner" can directly enter by signing a message with their public key ... or they can authorize others to enter by signing certificates containing the surrogate/agent's public key. The door entry validates the surrogate certificate as coming from a valid owner ... and then validates the agent/surrogate's digital signature. The door entry system doesn't require any access to any registry containing any information regarding anything about the surrogate/agent. The assertion is that anytime that the local environment needs a local registry regarding specific surrogate/agent operation .... then the certificates are a form of information indirection and likely redundant and superfluous .... since the surrogate/agent's public key can be directly added to the single permissions table. Logically permissions are a single table. For arbritrary implementation reasons the table of permissions for CA public keys .... may be implied permission of only signing certificates for delegating authority to surrogate/agents. However, the permission table may be expanded for CA public keys to the type of delegation that specific CA can perform. However, as soon as there has to be a local decision with regard to a surrogate/agent permissions in a local registry directly accessable by the device .... then I claim that the levels of indirection provided by a certificate can be eliminated and the surrogate/agent's public key be directly registered. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm "Tom Jones \(.NET\)" cc: "Anders Rundgren" , , "Torsten Hentschel" 02/14/2003 09:31 AM Subject: RE: A challenge Please respond to epay it is kind-of hard to get your point from this post. Note that the point of logon is that mobile computers need to work off-line. So any logon proceedure needs to accomodate off-line as well as on-line. As you point out, cert were designed in an off-line scenario. Seems to fit the problem nicely. If we don't have smart cards with certs in them, we need to put the cert (binding) in every mobile device that would use that info. That would assume that the mobile device was more secure than the smart card/cert combo, and had more current info. My experience w/ mobile devices, including cell phones, leads me to believe that neither of these is true. ..tom ________________________________ From: lynn.wheeler@firstdata.com [mailto:lynn.wheeler@firstdata.com] Sent: Thu 2/13/2003 8:27 AM To: Tom Jones (.NET) Cc: Anders Rundgren; ietf-pkix@imc.org; Torsten Hentschel Subject: RE: A challenge my previously post in this thread was more on the semantics of certificates http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) rather than the most recent post http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge which is about 7816 contact smartcard. one of the issues is that 7816 also pretty much dictates the packaging and form factor. migration away from 7816 contact to any of the contactless/wireless conventions also can totally open up the packaging and form factor issues. my certificate assertion wasn't that you can't have certificates representing a binding/association registration process, my assertion was that the certificates .... were actually that ... just a representation of a binding/association registration process (along with a side note that in an online environment the use of certificates as a representation of the binding/association registration process would frequently redundant and superfluous ... not that it wouldn't work). My primary points were 1) that it seems that sometimes that the certificates are mistaken for the binding/associationr registration business process ... as opposed to just a representation of the binding/association registration business process (originally targeted for recipients who would never have been involved in any binding/assication registration business process) .... and 2) that sometimes such semantic confusion can complicate processes with regard to which are addressing the binding/association registration business process and which are addressing just the management of things that represent that binding/association registration business process (especially in an online environment when having separate representations can be redundant and superflous). However, just because something may be redundant and superfluous doesn't mean that it can't work. The issue in something like login .... is supposedly something has been registered to allow login .... in the PKI/certificate case, presumably what has been registered is some information that is bound in a PKI certificate (name, serial number, etc) ... in addition, the login process has the public key registration of acceptable certification authorities (that can be used to validate acceptable certificates to the login process). I've never claimed that doesn't work ... I've just claimed that frequently it is possible to show semantic equivalence between the login process registration of some value out of a certificate and the login process registration of the public key directly; The PKI registration process provides a type of information mapping indirection (somewhat like DNS provides a real-time mapping between hostnames and ip-address) .... where the CA digital signature asserts to the equivalence of the information (like a person's name or userid) bound in a certificate and a public key. The login process then has a set of registered CA public keys. In the PKI scenario, the login process gets a signed message that has an appended digital signature and an appended certificate. The login process finds the registered CA public key and validates the certificate, it then uses the public key in the certificate to validate the signed message. At this point it presumably has a proven equivalence between the entity sending the message and some bound information in the certificate (like a name). The login process can then have its own registry that maps between names found in certificates and userids .... and uses that to establish a valid login for that userid. The informaiton assurance mapping goes I've never asserted that it doesn't work. I have asserted that in situation where the login process has its own registery and mapping; that directly registering an entity's public key bound to a userid .... can be equivalent to a entity registering their public key with a CA, the CA signing a certificate that equates a name in a certificate with that public key, and then the login process registering a name in a certificate bound to a userid. The issue isn't that the levels of PKI information indirection (between public key and userid) don't work, the point was purely that they may be superfluous and redundant. This is somewhat equivalent to the IETF pk-init draft for Kerberos which provides for both certificate (aka PKI) based registration as well as certificateless based registration .... aka directly registering the entity's public key. The business process of registering a name from a certificate as equivalent to a userid .... can be shown to be the same as directly registering a public key as equivalent to a userid. The issue then is whether all the additional business processes in support of the various registering process providing information indirection between the name in the certificate and the entity's public key provides real value or is purely redundant and superfluous (given that there has to be a complex infrastructure for not only creating the certificates .... but once created these certificates now also have to be managed). Now the intersection with certifications and smartcards (actually hardwoare token) .... was whether there was a unique token/certificate pair for every environment or whether there was one (or a very small number of) token(s) could be used across a multitude of environments. If the environment supported a registration process, then the above assertion that public key can be directly registered would support that the public key of a single token could be registered in multiple environments. The counter-argument is some future environment that has migrated to hardware token authentication potentially requiring a unique token per environment and an entity possibly having to manage hundreds of such tokens. So an additional assertion is an ideal place for certificates is where there isn't an additional registration process and the certificate is sufficent for establishing both authentication as well as permissions (aka all/any generic employee certificate gets an entity through the door). A corresponding scenario would be a system login that has no userid directory/registration and when presented with a login message with an attached certificate .... it is possible for the login process to establish the complete user environment from just the contents of the certificate (not requiring a userid directory/registration at all). The problem is that tends to require a unqiue certificate for each environment ... which may or may not imply a corresponding unique hardware token. If it requires a unique hardware token, then the future possibility is that people walk around with hundreds of hardware tokens. Moving it out of the digital signature domain but still in the area of authentication might be biometrics. There is the possibility that a login process directly registers a person's fingerprint in the userid directory. The person then types in their userid and applies their finger to a fingerprint sensor. I assert that the direct registration of a person's fingerprint in a userid directory is equivalent to the direct registration of a public key in the userid directory. However, the downside is that a person's fingerprint is, in effect, a shared-secret ... anybody copying the fingerprint representation and being able to regenerate it can impersonate that entity. The upside of public key registration is that it isn't a shared-secret, knowledge of the public key isn't sufficient to impersonate. So sort of a summary .... 1) understanding that the binding/registration process is indenpendent of certificates that represent that process can result in better designs dealing with the two sepaate issues and 2) when there are additional registries (like userid directories) it is possible to view certificates as a type of information indirection and that such levels of indirection may be redundant and superfluous (not that they can't work just that they are redundant and superfluous). some kerberos related threads: http://www.garlic.com/~lynn/subpubkey.html#kerberos and somewhat topic drift ... redundant and superfluous may represent additional complexity and cost that are hard to justify. From recent discussion about DNS, KISS, theory, and practice: http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm tjones@windows.microsoft.com on 2/12/2003 8:21 pm wrote: For better, or worse, the current sc logon to o/s's uses a cert in the sc. It could be argued that the sc really only needs to cache the user's name in an insecure manner, but the point is that a PKI is used to authenticate the user w/ the sc. It seems to work. It's hard to imagine how it could be improved by some structure other than a PKI. There is no biz rule associated w/ the authentication. I doubt that u can argue that it does not work. I am sure that a better sol'n is possible, that is always true. So, let's just use sc w/ cert for logon authN. Ok? ..tom To remove yourself from this list send a message Unsubscribe to epay-request@ca0.net (See attached file: winmail.dat) --0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384 Content-type: application/octet-stream; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-transfer-encoding: base64 eJ8+IikQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAEAAAAFJFOiBBIGNoYWxsZW5nZQD1 BAEFgAMADgAAANMHAgAOAAgAHwAnAAUAPQEBIIADAA4AAADTBwIADgAIAB8AJwAFAD0BAQmAAQAh AAAAQjgwMDZCQjA3RjYxQzY0QzhGNzE2QjYyOTQzMTIyODQA/wYBA5AGADAoAAA5AAAAAwA2AAAA AABAADkAQkjbjEbUwgEeAD0AAQAAAAUAAABSRTogAAAAAAIBRwABAAAAOgAAAGM9VVM7YT13aW5k b3dzO3A9TWljcm9zb2Z0O2w9V0lOLU1TRy0xMC0wMzAyMTQxNjMxMzlaLTM3MQAAAB4ASQABAAAA EAAAAFJFOiBBIGNoYWxsZW5nZQBAAE4AALwvvnzTwgEeAFoAAQAAABsAAABseW5uLndoZWVsZXJA Zmlyc3RkYXRhLmNvbQAAAgFbAAEAAABTAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAAbHlubi53 aGVlbGVyQGZpcnN0ZGF0YS5jb20AU01UUABseW5uLndoZWVsZXJAZmlyc3RkYXRhLmNvbQAAAgFc AAEAAAAgAAAAU01UUDpMWU5OLldIRUVMRVJARklSU1REQVRBLkNPTQAeAF0AAQAAABsAAABseW5u LndoZWVsZXJAZmlyc3RkYXRhLmNvbQAAAgFeAAEAAABTAAAAAAAAAIErH6S+oxAZnW4A3QEPVAIA AAAAbHlubi53aGVlbGVyQGZpcnN0ZGF0YS5jb20AU01UUABseW5uLndoZWVsZXJAZmlyc3RkYXRh LmNvbQAAAgFfAAEAAAAgAAAAU01UUDpMWU5OLldIRUVMRVJARklSU1REQVRBLkNPTQAeAGYAAQAA AAUAAABTTVRQAAAAAB4AZwABAAAAGwAAAGx5bm4ud2hlZWxlckBmaXJzdGRhdGEuY29tAAAeAGgA AQAAAAUAAABTTVRQAAAAAB4AaQABAAAAGwAAAGx5bm4ud2hlZWxlckBmaXJzdGRhdGEuY29tAAAe AHAAAQAAAAwAAABBIGNoYWxsZW5nZQACAXEAAQAAABsAAAABwtP01jXujznxLdRP4ZyImUnwN2F4 ABRB2RgAHgBzAAEAAAA2AAAAQW5kZXJzIFJ1bmRncmVuOyBpZXRmLXBraXhAaW1jLm9yZzsgVG9y c3RlbiBIZW50c2NoZWwAAAAeAHQAAQAAABEAAABUb20gSm9uZXMgKC5ORVQpAAAAAB4AGgwBAAAA EQAAAFRvbSBKb25lcyAoLk5FVCkAAAAAHgAdDgEAAAAMAAAAQSBjaGFsbGVuZ2UAAgEJEAEAAAAc IQAAGCEAAKVyAABMWkZ1/qTVxQMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jB CsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2VkS72Y0EG8RezUDxlR8 YWgDcQKAEeMI7wn3O3scHw4wNR0/HRER4QxgY2cAUAsJAWQzNhFgC6U0siAQAipcDrIBkGcU8BcK oxHjImg0FPA8IUQAT0NUWVBFIEgAVE1MIFBVQkwASUMgIi0vL1dEM0MmAERURCUUM4QuMiYARU4i PiNt8yMPKEExOCRwJSInjyifjSsQMyIAKfBFQUQqTS8O8StvLe8pdDYO8DxNKEVUQQewQTDgPSKm RwnwBJBhdAWwIhcQaE9OVCdQVDFwBeFFongY4W5nZQZSdhMxBzPBAJACICA2LjUuwDY4NTEuMCd+ L08JKYM3NyRwVElUTIpFKk40DvBSRToRcHIgGOFsbAnwM2Ao7jX9JHAvN881/yrFORE7UCzPCysf PyQ1EWA8Qk9Ejlk+nSFxP79nOTYkcIBESVYgaWQ9RBAgT1dBUmULUHlUSGV4dDdwOTAU8GToaXI9 P0ByPpA/AwAhPiAAAEXBCrFGshjgXHH/AyFGJRFgQX9Cj0OWRY9Gn3NHqj7ZNjRLikffKXQ0JSnR RjJRIGYA0GU9RwcTOZAboj0jMFKTIHUAkHpRoDJLexgwAzBjbxPwA7IB0Ee5aQVABAAgYmsLgGQt b0wAGPFkeiAx8CAzYAVAPTxJRXnxCGEgcG8LgAVAA1JW0EZoVeFY8HN0Lij8Nf1DoS9RIkt5S4dN ywHAS4fvCqJcaAqAKPwwLJEmYEPg/1u/T79JL0o/S09MX1yfTn8/Yb9Qn1GmUw9UFFTNTm/+dDNw WaAx4FmRM3BY9FZhvRuwZzRRVeFuowRgYgMQjzNwV19jQgWgbXB1bnBdGRAgMbAJgFbSdwWwa9Fv gWYtbAuAZVo/W0//XF9db15/X49gn2lPYr9jz/9k32XvZv9oD2kfai9rP2xPrVS+U1bwAHB5b7Vw A2B/UZAJgAhwM3BzAnAxiIFj/3JhBHAx4HD/fURz1oiQBCD8d2U50I0CAiB0D3Ufe0//dz94T3lf em97f3yPfZ9+r/9/v4DPgd+C74P/hQ+GH4cvvZ2SQQQgWKFvJnKgLDmQvwSQBUCNQInBAQAAkGcx sP9WwAuAiJGLL4w8BPAJ8ArACzRAjjw4IgAmbmJzxnACgJlnXCdhAUCdR+kGUWVtijNmVbFu8wNg 3wJgqoBy8A3gjVB5jj+PT/+QX5Fvkn+Tj5SfnU+Wv5fP/5jfme+a/5wPnR+eL58/oE+9VL5Jt/CN QLbgAiAnBUDfGPAzwL4AAMCjkWMLEY0h/VWwaKNjBCCkoaUPtWJu8X5to1DAoXMGcpFu46NzKKdw wFYwC4BnKaSSZTPBd4jAcKUBAHasAW6Uc4B1+mxWwHUZIMMfxCVuwQuA/wIQrF+tb65/r4+wn7Gv sr//u2+037Xvtv+4D7kfui+7P2+8T71fvm9UvlTIeI0Qc751B4BumMeMyV/UQneNEfcEYInBGSBj ibJuoQOgbvL9wYgvo3NyYQbgo1AAcFbA/xjwVsDjc+PhHqBZIeHv1EL/yv/MD80fzi/PP9BP0V/S b//Tf9SP1Z/Wr9e/2M/Z39rvb9v/3Q/eH/DhTYjARPBwpwZxCfDIMXcvx3xzo1B9C4BjCkDGkud/ chSNUnD/GuAxsP8ROeDmgONRboFW8P5ijVAIkMFRbqKnf6iPqZp/MbDCURMxVmFu8ckv6GZz/wOP BJ+pmvQAHQDpH+ov6z//7E/tX+5v73/4L/Gf8q/zv//0z/Xf9u/3//kP+h/7L6Fe/wwfDS8TXwlP Cl8ZLw+fEK//Eb8hvxPfFO8V/xcPGB8lfz8aPyqfHF8dbx5/MfguLv1W4G0gLyE/Dj8mPydPKF// KW8yHz0vPj8q7yv/LQ8uHxMvL0HfMTFUkDxCUj81GUMCQhBG/0KPQ5xIUjFW0GFiSVYw/WA9LSox NRwxL5BjL5BqXMXfwWI2AH4gX0+iT2H/RlCOATuTSc9K3jB/MY8yn3kzqVRhAZDk0DSvNbI1vzYP Iv5IoDUbT1FY90argOxtOkvcSIEvWpo5iQHw4Hlubi53bwCNUHLAlkCq8HLQdIrhYS7lwbsHb0uD W+TQcNCKUDpfL/1gN11HnThRSLyN8lDPWd//Wu+IM+dBXH9dj6nX31CioCAyLzEzL1iwMDNgIDg6 Mjdgz0uDQf5NZF9lb2Z/Z49on971YoBval9rb2x3YKFKAaLGQC7wTkVUKW+fcK9xv3LPc3Pfe7RD Y3Vvdn+p10GjTVFgECBSdU1QZ+cxFjtuH+iEZTtwLXBrgGl4QGltYy7mwJ5ngoB1QGARpwAgSOdB +6bgq0BseR96L3s/fE99X/FppXViauPQaj9/76nI+FJFOqJAgp8A5ANQAVD9pwBniGGGX4dviH83 vzjP/5Pvkf+TDzoPOx88Lz//lg//UY9Ln0Q1NRuer0gfSS+i3/ef/1M1nXBQpG+leKHvov+vM3dX LzXB3nxt/UBw5zDbyBDfsHNioMVwb2AgwuL/yGAIwMhR5zDmgeM3wODkdPvEkORQdOGgwtAG4Y9v APT9m0BpX/DlIIVgCNyX75j/HYkvPI9ApwOwwWY9IoEkcHRwOi8vd7pQPC5npTAC4ISw5cEvfqli oi9hAiFtbVAuJHF6IzNgIjUcAvDf0LMSZgff0MLwYCB7SFlQRcBSTElOSyC537rvPbv4fVLBvfFg EABwXGP/TpHfwFjZvy/AP7wGnf+qCvuej4zKQTUQsu9vJOWwkMbveKDmgOFwTVBheQ+2D7cf98zv zf/PCnLfcAai5DfmsP+wAecwNCDnUa/iz8/Q387v77g/uU/EH8UvNbyPvZ++r//aP9tPwd/C798/ 4E/cEceP/8df12/Jf8qPkL/VT9Zf6CT7YvD+4GiwIAJATSCvgLAQ/Dc47MFgkNRQNBCwELvQxaUw dLSwcmQusaGxkfsG8+8xcwvgAkCwg2BQ6d/npxPv0zSAc2/r7+z/1uznrzHjcP1AbXXvEUSwjDDn tMLTc6cQY2sAkP+islC9sQBmsXBgsDQBApByDAz3I88FbrFQaYJAYFCvcLHA2/L/pyJhsSD4IGZc QfTf//Xv1uzv22Jw+fH4IPGV8CV/65DyEOPARMBjIfIQ8BJ2/9RB/lHvUfSh/o+z9LJQAH+/AY/W 7GJwprDrgASRcIVx/HVw+R/6K/H1+vwJ3wrv/8+/EF8Rba8BB4+0De9g8hBntFKxsbEhbicEIfKy ef+vgOtAslAYcfKwBqDrQLRf9xK/E8/SR2WvMbIgsmENstsVf6cTYrAw3dFnu5DyEPxvYzRw/kOv QA2Q1KD+JfevMCCQBaEsrvIXmxqvG7//Cy3ystOCHp+0DjcBNxCxEHcZ8BdxjDB1DDPyoylCav+v kPLQVwAdp/40ssAjjySfvxF8Hn8fjyCfIarMIWyxsD8NwAXg04AvYazgTWAgbv8MEPHg8qOwMCx/ LY8unf5/d6cEsbARUiDMcK9gXEBu/m3UQtOCr5DxcyhrsTErT/+yz6b104E1bzZ/EXww7zH/nTMF d6+ATzAAIWVx8jD31FAMUa9AZIIRslE9//+Uv01QP49AnxF88iAMkHLdsP51r4EqozShNOVGoEUT GGLxRRByaykPT0lPEW9OH/tPL1A6Ta8ShJClMK/CsDDPhdApdEbPpyIxKUx3siD/sjDyhfSwOsCy cDrA8oU/Xz9R31LvO8yxgf3w1KBha/+FcfpBJs8wX0MJ0xBDylk//1pPQa2vkFABBkEy9ilCsTH/ DICv4UYwBDIq9V5fpyI87/9Y/2KPY59Cf0OPZL9nX6ci/iixcP4AsDAqFKUw68CFYN/6I2n/aw8c zm2wcIPwVNN+aARQRRR4cAag2SEZomLHV3CxwLAwdm9sBqCxAP+wMQRycB9fbRpCYY9zz3Tf/24/ b0pWwCky+w/8H/0r+gL+MlbFeT+nIlgY8iDvEbIm73uvfL9bXbGwZmTBsbEI0fnwEW1w5EEXUiH1 8kEz4/9DwfEBBDKEj6ci7uRdAsxB/x3RZNENwGnPiC+JP2z/bg//bx+Nf0fk7tWPHJA/kU9QHP8q 89ODslAnwLIw1ELxkx4x//KFaKeEL3nvk6qZL5o/fc/7lK9lKCgFoAyQk/EMQnjD/7GhOgOfT3Ei Olru4Mxwoc//ot9QHBmRHjKyIHERF1JorP8GUdNRd+BGGfoCqD+Fk0tUf0vBTd+rf0//sv+0D7Ub SP5vKYB3USJgZuN34BpQO1L/WBOdopyh+CCvz7DfselLs3xkbwWgGGG177b/FH1l/9NTTKQZNE2S st+/v7T/w1/7xG/FelTx1niyuki8P3Ei+8UwXZAgM5ANkSkk70FLQf9mUwxRukjrYGYQd+LGP8dP /6PvQ/EpkWaT63G48Mw1yq8PcSLMpMHi8eBQS0kvXxbaGlCeoCJgHcJ18LBi/wxR7uAXUM7/0A+s rs6U0er/zPJYIdOPcRNxsPpC/jQ09P/Oke+Q+hF4wtWSGdrX/9kP/cVcKHHAOsAiYBexpwF3IO/X QHfguUFYQGOAc9yv3bX/j0Iz8P5RImANAsxEMvbOcmeQD+HP4t9wdddw7wAgv12QRgJD6T3RDVAW 0HDqIP/XcNyfKA7+UrnwNABxcYcQ/YZBKJ7zCN/qb+t/uyE7Uf1mk3bS0DRgF1PuT+9fKJjHjTHn /7LAIEknd7Dyb8fzf8VcdzRjbGFYYWaR/58CvkVNg+WPcNf64irk/ov/RXlM0d8Q+y/8P+utZmA0 UPv3Eo0xc3ag0xCGxjpARaD+afYRnSAW0ABfejRYQCmA/12h+a8ELwU/0R/ta9xj9hH/yaEZAJ1D ZzAW27wPPugLj/8Mnw2vDr/tmDsS7Il6sHXh/QOROxUPFh/FXxq/G8/Ijf/f8hKvaGRD72UjOnA0 cDyi/HR5skA9wt4K11BmQJj//x5vH3+gohoS8NIhD3EjWBLH17LMMMwCRE5TI5p14P3S0C1YUiWG d9EK8yYPJx97rK1mYHTj8jyhEn/dlnA+LZiFgHSqMlUxOxJDQV8Z4dugLyDkoJVgZ5zQdP51jyKM IdYA+VIujy+fHKzfE/IIyj3fE4neCijL82cw/7JBoTC+gGYQ4/KnsF3wugH9VDBkgHDfQzdfOG8o LhF//5fAZz9xBOyIgM+B34LsyTL/6DwT8XjQznJEgJ6gnUJAP/9BTxcv0iY1YeyFRK9xIuzxfnP6 wdVH3FDV4JzQVDBv/+ff6OFyUSQRS89M3xysNhL7coGGMXOc4Z7kznJQH5dk/0RwZkCdICyQl8A1 n0Q0Wnj/VJ9Vr4lt+Lg0oEmfWQ9xE//ggHqg6TNOv+ynl6FdP15P/xys9hZjtNXp1uDCUUqzYi// cSK6AWO07InVNeA/Zj9nT9851/X5UxJXnDSgQZ8vPHb/3xHNUHqQwjPXCUsEI6Iub/9vrxyOCMoK 2p0hjIDNsVrB/8pvPFpYBpei3GM/73hPeV//KOLeKG2fzCA91uPy+rHJMv98/8uz6EuK4kqyf++A /6yv/8mxNwHTAJRXZYCe8yWRzpL/CvQxxN4g32WGD/hvZa+Jn/+Krz9kpgDU45eibFWfEdKh/5jA 9vLfEJgh9gTMNd4hjx//PIWfET9kYOORf5KPgg/eMr/xcPDiyYGlIAlCLZZnvlH/mm+bfxyvn7+g z6HZAbP+JP+YH1ojNsP+1sJR/1r6wYuk96eNyeHxcHXeY6KPo5+hrP80yKY/hx/OY4wM+LBlgyWG /xp8R39Ij/Hjry8q0hn2q4//rJ9N72RDzjLB0XwEPrHsif/fRNKiP1XMk7N/tI9Iy4gy/7a/CpS4 j7mfea8I9JYDRIDffAW7ilMRKTDsenfxcJbS/zVgUvTCTyrSNWDDv8TPVr/+brwDQ3vx4wjBkPQ+ 1EM//8nztm9FbcxfzW+hrGVh5DD/MiJKs1Mfu3zRn9BU068Kk/9/r9Yv1z++CmDkBAB2QOIi7/+S ldTZQv4xbIwhO2BSMn89GtyfM3MpGN4/30+hrCh/CtZk/D9X/1D/lsqEdYR3/0sRyUApQAOh5T+Z J9kxuH9f6D+hnZ2wvZFykXU+UWb/ENDd8DIETzHeAQhhvwzw///yD6J/9j8fn3VRdVErJ+5PhyrS xrzZMklFVEYUgNxrLSkAqGIPwGYDAZfhfks24C4QdzAjgDTAbmBo//g/+U8GTSO2l9Ld4MoR/E/z kD09wGFrRIBSMT/BSxDvV9EiW0sRCwBsW4BLEAEP/wIfX1/QJnrgI3EH1AUvIh//lPQHURn2yB4J rwq/xd28j/9GgIW/3Vi+YPdBI3SH4ztR69pfYSBmdzBtVH8TLwuv/0OaI4DGvhbPbBW+lsHz82L/ MYCMUZYh82Fyc9tCCY8b3//3PhC/z5TJSR/fp0Qez+GP/4hvJI8ln51BAJJUQDTRH6D/CVHZMjPh ndCDYVtxKO8X3//aEdFRqsLzoHWA0BA7Qtky/3rAUsG+YCzPLd+6r7u3Yab/BAR8v+YIgwrmp3s7 2zU1v/82z+Bdg+3YpRUoOp/UuGVT/wQHuCBbcXrB4nGX4ftQPp+/P68DLe3k9Jd+9POpKBlw/3dR Q5/vS1wRsVIitBrcv+/VwP9jf1BweuB4Rz9IT3ecj55gjMF1uEBcApfSbusE4LHAbnaRY0Yx5vDI tP9Mr5AvlOQYEFcSexFXg10ff1O/QJ8skL5wbfq84Fbwd/8wYX9Ai6QitFhfy/KdsIVQ/3Nw7AD1 L1zP909jP2RPZVr+TmAB2TJ1obJwvnA9BMnzd8/45wH0NHOdsNAQwgBy/5TBYT/L8gcwVlEwcXai bFC/7JDL8BIvZx/gT+swbgew/5Tz7ZIv9k5U7ZK+Qc+AepD3YR995XIiL8/6WVDJEZfSv6Xi8B9w HxRPBDAEEG6OUP8fUZfhcx9XIYSxl+Efv8vUx3fSa9IJUW51bQBR4/HjB7ByEyhzKXgfeS8dDf3d 8GyXUPNhvmGXUG3wAHHtdBJthBBDMXUEUOPyfc/7/VN7KHOpUTTkexmA/4IP/859NGSEoggssNXK g9kUhj//p0Pd4Km3PGLQs8lIiY+Kn/8dDSH0Js8IAeyQhBI0VtNfv0157RFFCOQBfaAYMWcfMP+S f5OPcT/qkYP3lnnbgYVjv1KBmE+HPxZkg/Fpoi3L8P5nf9AfQkcfnD+Lj/vB/9D/WtBWcnsa0LOx UqCvYkPPYL8IkQgB/kFug27hnjVhWtD/LJHcAGskpE+lXwMtBOBDEv9uM7ggHuEZxXRfdW53IDBB 33sa9FK8R+0h4lBp1RCSb/+uP2UtYIHIox+QYoRucN4B/0qh4+OyL8vy4mAA4HIEiDC/tj+3T2U/ vU++X79pUx+R/wjhMQiQ6PtRIfEEQUZRUoD/bfBWlLsPWW8vxG7/wQ+dT/9zo+Kkw0yNT9oSQpbG LwY+56Qvyb+mT3Vm3CEfQneD/xmQkIC/ECJQuWIE06xcCPn/zy9EpH8gqqC10WtiBzLRb/fSf788 MHEvw0DrUGLAvzDLIVAWEGVScW956oBBy59iwIggtQmowAQQdWcFD/+ZSOww7KBi/9tPvx/jH+Qv 9eU7QVJBcpYAUJA8cDpDvnPUsTVSlxVPIvugeRmR/xqw3oAZcJFlTrJW8OEPINmf5g/nHyXvlhE8 EHkvCDz/9GEv8Y3yXuFpoZcBanJ9oP/rtPvQLDC6Ampj7N+QQ60v+++P3G5099AA4AgBBnoQI/// UchBtbVWlD3i67QYpisR//XPobPVVvc/+E/K71JFBwH3ISJ7CxqDaiEgTjNSQfPRf4gRNMb+X8c9 AD8BT+UsKP9W8rD7ITTxj9b1mD+QJdeg/+LvCe/lDxDPEd8S6yviGKH//IEasMhBTgQsoGxhKxGw 9PPrAkrQcWlGsfrKxe+hd//6YRO/FM96P3tHcpPVwLxx339wmnGQUCCCVvJpUnFXYP99oOkssb8H matmHC8dP51v/yygiEP70RiFdBmrbI6Jp5X3I09Es7XDaRKwQ1AlHyYvN1TtF4VLoG+gYnLQbGv/ fZDgsfMCanK6SqtnLA9117+8/y7/Er82Lzc/OEtNRcH/uXH70aMgWuEGlJXg8kA5sPtGYPxgZ+ow VmPioH9wn+H/WsLyYC2wRmDr4zQ/kCVGMf+agTkfOi/cfdZ8qqFQ4GDy/y2gp1HycJIQoqTL8z+z LVn/qLR9r5Ak67NBz0Lfr139tf+V73QS2VFgUMxAMRD7ELlw/38g/aBpkT+GDQVJD5BCDXe/Ng9L rxXPmcFPg46VedlQ/8ghP6N3UQ0FtNOXoDgQyBH/WCRQBP4fkAdTn1SvODxQCvvzsadAcohBkNUX lT0zlgL/zVyak1q/2RVPo1wfXS9eP99QOgzv3bDIQbECdsPwqIP/wyBhOWMPkELyKmTfZe84PF+a k5npUMxS/wdkOFuAJhRuYulwO28ZJ2Ew8Th4IEhv14B30Y6Da6//UqR2QDXgxSEXZ1wPbs+vTu9P j6PzjoCf4WXUgJYRjoD3msGrYasALQ0QhOBGgB/Ta3cP9tR5kJBk3bAF8HD+eblj80B5f3qPZv9Q N5YA//OF8pjq8LFT/IIYU93T+0L/f/+QQvvRlXIhcVbjCM+DX/+Eb6jDtUSitJeQeJOakZnp//Ir F3aI/4oFzCWLb4x/pm2rfuoq4GsMAHcDsGS6Ef8GhXEazDPUZFlwaqSSH4oD/4rIU4+VDzgvnS+e P8JdYAFzPNN+sXVtudBpwfuDMf4pIsHFMFbwoKDppGDnmv//ECItoOmj8hugD6EfTM/90//IQaeh s6DZUKySPNPHe+wT/4Y3pj/iFTFS/bWKcajfqe//nyzpUeqwUKPq8PpABCHFML894k4BxUG5YjKz UPJ06pD/X8FbsNEE1GApQa9P9tTO0P4ypLDzMrGfsq8CXxjSGNL7zM9ZciifAJCAci5ZcaSw//vU uG8tGIfjum+7f58sPDD8ZXetfOxxYuBXkjOC/XD/1QGkAJFE6aFOQvK2kc8P1+/UYCBRA7B2cGxk z8Rvb9//yQsg8urxfwEzEd/wSMFZAePUYNlRZmx1PLDZ8QwCf2Dm3bDKbwgD3/CZ4eqQcv5rzG/N f58sBWXS1ipS0M//0dYQn9Y/nw/bP9xPljxGYffTT1uzv5By6vD9sDEQTkDebK4ByfJBYTNgOt4v 3z8z3U9zezxBB9Tj4WY9AiLlwHRwOi8vd1npoC5nECCQQS4DcS+ifiGgbm4vmhBicRHVkIEu5cIj 4sYi5ZnkcHv7EMwwZORy0fAigfJgewBIWVBFUkxJTjxLIOkv6j/rT+xQfX0P7SHtcFbwB4BcY2Yx /ly0wOYw5sfvD/Af8S/lt0/lp94A90/d/jky5VAv/kHlkORf5W/mf/tP/F9EGv9ZAeF/y3NGYSAg F8IxoHFR/zMwCIAfxNl/0dcg8oY3/h9//y9D7b4YAV/UY/VAMbF4/0hSWPKBwNhmKlIqAogC2EL7 GdCPAUYfYBdQTkEGfweP8wifTiBzY1EwwuCG8oFwRz8BCl+5ckROUyrgS/xJUxSxUPFpsX6RWQGG UPsb8EUhZeRPED/9L+d/6I+P9H/1g7egM2BtMTLrgvwjOexv7X/ujxwPHR7yT//zXyD/Ig8d4PiP +F8ZP/p4qxM/W7NDU2BwmsFGo0C5o+AgUoZxuXDL0UcyUf5wpEIWnxevhJ2B8C7PL98fGL8Zzxrf JY/1kjIwMOYz9RDrkzI0Hg8fHyAv/zdvOH4jTyRfPF89bzlAKO/vKL80nyrfUg1OtUDVArdj92JF UTC2YmgMoTH/Mw80HKh3L220wWkL0SA0EP9IVGhR0dEWIMdQSg9LHzQfzzUvNj9A70H9NTY5bzp/ /zuPVE9VXj6vP79ZP1pPViDfRE9EH1F/Rj93bUXHgMCxQ7DBwsZQQVNWahB4/3xxirAPD0+/UM9R 31LvXZ/7Xq9WEDdWT1dfWG9sj22e/1uPXJ9xf3KPbmBhL2D/ab//Yx9kL2U/Zk9nX2hveg9/z3OA 34HlLS2CX4NvgXxJ305CTbEDIL8QxmBhFSA4kPO2wdSwdjpqD2sfdc/1VvfR4JphhzBm64Juj2+f cK+/jJ+NrXPPdN+Rf5KPbXlv/3k/gf/6f4Xvhv+aH5x/nY9vnp+fr6C/AyBqqLDHUECDtqAMYG93 cy5tdoB74xGtUHR2onv/uWMSsTIGLx2AOIMgODoyMft9wA6wd+MQt8AWj6LfoO//qc+q36vvrP+u D68XLUG1JT8VILKx1QEGYBUjxqB1ch/AUAShElCmn7ljbG9n6xKxLRFv9cAnx5C/wceS/8ayyQEV Mq+vsL/gTXaQii5AJm5ic3A7uakn/GEwrwiIYBMgDJBNMAEw89CR1GBndeOj0tS0v9Qm7ePxbEHg z1BuwfGuwOOg/8eQLRHUoMvQ2VC4L7k/uk/9tzFytwEKEOFBt/HUsMkBvwZgtEHZUNBQPZCzImIT Ef+0AsBv1GJ90E4xz4DCsQzz735QFODK4rcxZMOfxK+j/f0tIGETEBVQTkB2gOOBs/P/xpJM8b/l u3+8j72fyU8CY/3CgG3Cs03i0W/Sf9OOtwH/DXXMT81frsx/ANsgrrFJsZ53x6C+iX8AFgBvduOh 3mIF8OEvAhiJAHUWMMgC/6lgFVCLgAzhEsHLgi6/2389rr1U4hHHMcbhLSBiad56DsBNML8RffBv jeDQAf8BMNDV4A8LYs95EqHi/+QPv66/6t/r74e7EiAuUGIMxf51wvESwb9CDNTeMaVwt1H/5pDU cNZ/7n/vj/CSxxDob58CVMgCyyWy5N+hbCfHkZ8FsH3WFSLyYrdhbHcF4PvLAS1gZfOf9K/sz/wP /R/5/ipTbxUgC+DZwg3y9u/fC1O3McAi0NG3o2aysbZEHc9yTta/18/TjE9rP98GHwcvvasuoC0Q bf7v/////g8Mrw2/Ds8P3xDvEf8TD/8UHxUvFj8XT+XhLSAC38F0sm3fMSB5LlCzsWwaQP5mpfCp IMNgyvF2cH2hSLC/pWC3cd/QffAZIMAQVcfA//DwwDB+8L8BLREbr7YCSMG0eS2LsHG/YJBAQM/w /DAuTbEYfxmPF58jiVYg4ZtxRk9OVCSZmJ8lEL+14ih4JZi10yWftUY3m2IKUJu+MIsBL0RJVnsn zyvvZ5khtfMwTzFfNcI4m3FCT0RZm72bYAsyjzURN5txSFRNTAUkkH03QB4ANRABAAAAWwAAADxG N0I5NzgyNjkxMkJDNDQxOUQ1RERGNTNCMjE2OTQ1MzM5OUQ5M0BXSU4tTVNHLTEwLndpbmdyb3Vw LndpbmRlcGxveS5udGRldi5taWNyb3NvZnQuY29tPgAAHgBHEAEAAAAPAAAAbWVzc2FnZS9yZmM4 MjIAAAsA8hABAAAAHwDzEAEAAAAsAAAAUgBFACUAMwBBACAAQQAgAGMAaABhAGwAbABlAG4AZwBl AC4ARQBNAEwAAAALAPQQAAAAAAsA9RAAAAAACwD2EAAAAABAAAcw736a3UXUwgFAAAgw/6jwjEbU wgEDAN4/r28AAAMA8T8JBAAAHgD4PwEAAAARAAAAVG9tIEpvbmVzICguTkVUKQAAAAACAfk/AQAA AF8AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPUZJUlNUIEFE TUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049VEpPTkVTAAAeAPo/AQAAABUAAABT eXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfs/AQAAAB4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEA AAAAAAAALgAAAAMA/T/kBAAAAwAZQAAAAAADABpAAAAAAAMAHUAAAAAAAwAeQAAAAAAeADBAAQAA AAcAAABUSk9ORVMAAB4AMUABAAAABwAAAFRKT05FUwAAHgAyQAEAAAAbAAAAbHlubi53aGVlbGVy QGZpcnN0ZGF0YS5jb20AAB4AM0ABAAAAGwAAAGx5bm4ud2hlZWxlckBmaXJzdGRhdGEuY29tAAAe ADhAAQAAAAcAAABUSk9ORVMAAB4AOUABAAAAAgAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGED4/ eT8DAAcQ7yAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABJVElTS0lORC1PRkhBUkRUT0dF VFlPVVJQT0lOVEZST01USElTUE9TVE5PVEVUSEFUVEhFUE9JTlRPRkxPR09OSVNUSEFUTU9CSUxF Q09NUFVURVJTTkVFRFRPV09SS09GRi1MAAAAAAIBfwABAAAAWwAAADxGN0I5NzgyNjkxMkJDNDQx OUQ1RERGNTNCMjE2OTQ1MzM5OUQ5M0BXSU4tTVNHLTEwLndpbmdyb3VwLndpbmRlcGxveS5udGRl di5taWNyb3NvZnQuY29tPgAA+ag= --0__=87256CCD006053848f9e8a93df938690918c87256CCD00605384-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EH1eY07877 for ietf-pkix-bks; Fri, 14 Feb 2003 09:01:40 -0800 (PST) Received: from smtpout.mac.com (A17-250-248-86.apple.com [17.250.248.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EH1dd07873 for ; Fri, 14 Feb 2003 09:01:39 -0800 (PST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h1EH1f51025823 for ; Fri, 14 Feb 2003 09:01:41 -0800 (PST) Received: from [10.10.110.50] ([65.200.9.2]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id HAB5YT00.K70 for ; Fri, 14 Feb 2003 09:01:41 -0800 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 14 Feb 2003 09:01:38 -0800 Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP From: Aram Perez To: PKIX Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Phill, While I generally agree with what you write, this time I have do have some questions, see below. Regards, Aram Perez Hallam-Baker, Phillip wrote: [snip] > >> May be in different environments different such technologies might be >> usefull. What I am missing in this discussion is a clear list of >> requirements for certificate retrieval. > > Alice wants to send email to Bob > Alice does not know Bob's Certificate > Alice does know Bob's email address. > Bob's name is not unique But Bob's email is unique. Why can't Alice look up Bob's certificate by his unique email address? > Bob's company will not provide any form of search capabilities beyond > exact match. > The Trust topology is complex as in a multiple bridge CA Web of trust. > > > XKMS and the planned ASN.1 cert discovery protocols meet these > requirements > > X.500/LDAP are designed to meet different requirements. They cannot > address the Web of Trust cert path discovery requirement. Can you please restate exactly what this "Web of Trust cert path discovery requirement" is? [snip] >> e.g. privacy >> issues, organisations not willing to publish information about their >> employess, etc. also hold true for the other technologies. > > This is empirically wrong. Most VeriSign customers are prepared > to publish their certificats in the public directory for retrieval > on the basis of exact match of email address. Not exactly related, but why won't VeriSign "publish" or make available their public keys so I can do my own manual verification of VeriSign's certificates in my browser? [snip] > > I don't count large numbers of enterprise directory sales as > evidence for success. Try a thought experiment, what happens if > the directory goes down, how much work does that event stop > getting done? Come on Phill, what happens if any critical component goes down? Look at what the Slammer virus did to the whole, worldwide Internet when it attacked SQL servers (not LDAP servers). Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EGVi806007 for ietf-pkix-bks; Fri, 14 Feb 2003 08:31:44 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EGVgd06002 for ; Fri, 14 Feb 2003 08:31:42 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 14 Feb 2003 08:31:38 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Feb 2003 08:31:38 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Feb 2003 08:31:38 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 14 Feb 2003 08:31:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Fri, 14 Feb 2003 08:31:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: A challenge Date: Fri, 14 Feb 2003 08:31:39 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A challenge Thread-Index: AcLT9NY17o858S3UT+GciJlJ8DdheAAUQdkY From: "Tom Jones \(.NET\)" To: Cc: "Anders Rundgren" , , "Torsten Hentschel" X-OriginalArrivalTime: 14 Feb 2003 16:31:37.0385 (UTC) FILETIME=[8B8CB990:01C2D446] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1EGVhd06003 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: it is kind-of hard to get your point from this post. Note that the point of logon is that mobile computers need to work off-line. So any logon proceedure needs to accomodate off-line as well as on-line. As you point out, cert were designed in an off-line scenario. Seems to fit the problem nicely. If we don't have smart cards with certs in them, we need to put the cert (binding) in every mobile device that would use that info. That would assume that the mobile device was more secure than the smart card/cert combo, and had more current info. My experience w/ mobile devices, including cell phones, leads me to believe that neither of these is true. ..tom ________________________________ From: lynn.wheeler@firstdata.com [mailto:lynn.wheeler@firstdata.com] Sent: Thu 2/13/2003 8:27 AM To: Tom Jones (.NET) Cc: Anders Rundgren; ietf-pkix@imc.org; Torsten Hentschel Subject: RE: A challenge my previously post in this thread was more on the semantics of certificates http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) rather than the most recent post http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge which is about 7816 contact smartcard. one of the issues is that 7816 also pretty much dictates the packaging and form factor. migration away from 7816 contact to any of the contactless/wireless conventions also can totally open up the packaging and form factor issues. my certificate assertion wasn't that you can't have certificates representing a binding/association registration process, my assertion was that the certificates .... were actually that ... just a representation of a binding/association registration process (along with a side note that in an online environment the use of certificates as a representation of the binding/association registration process would frequently redundant and superfluous ... not that it wouldn't work). My primary points were 1) that it seems that sometimes that the certificates are mistaken for the binding/associationr registration business process ... as opposed to just a representation of the binding/association registration business process (originally targeted for recipients who would never have been involved in any binding/assication registration business process) .... and 2) that sometimes such semantic confusion can complicate processes with regard to which are addressing the binding/association registration business process and which are addressing just the management of things that represent that binding/association registration business process (especially in an online environment when having separate representations can be redundant and superflous). However, just because something may be redundant and superfluous doesn't mean that it can't work. The issue in something like login .... is supposedly something has been registered to allow login .... in the PKI/certificate case, presumably what has been registered is some information that is bound in a PKI certificate (name, serial number, etc) ... in addition, the login process has the public key registration of acceptable certification authorities (that can be used to validate acceptable certificates to the login process). I've never claimed that doesn't work ... I've just claimed that frequently it is possible to show semantic equivalence between the login process registration of some value out of a certificate and the login process registration of the public key directly; The PKI registration process provides a type of information mapping indirection (somewhat like DNS provides a real-time mapping between hostnames and ip-address) .... where the CA digital signature asserts to the equivalence of the information (like a person's name or userid) bound in a certificate and a public key. The login process then has a set of registered CA public keys. In the PKI scenario, the login process gets a signed message that has an appended digital signature and an appended certificate. The login process finds the registered CA public key and validates the certificate, it then uses the public key in the certificate to validate the signed message. At this point it presumably has a proven equivalence between the entity sending the message and some bound information in the certificate (like a name). The login process can then have its own registry that maps between names found in certificates and userids .... and uses that to establish a valid login for that userid. The informaiton assurance mapping goes I've never asserted that it doesn't work. I have asserted that in situation where the login process has its own registery and mapping; that directly registering an entity's public key bound to a userid .... can be equivalent to a entity registering their public key with a CA, the CA signing a certificate that equates a name in a certificate with that public key, and then the login process registering a name in a certificate bound to a userid. The issue isn't that the levels of PKI information indirection (between public key and userid) don't work, the point was purely that they may be superfluous and redundant. This is somewhat equivalent to the IETF pk-init draft for Kerberos which provides for both certificate (aka PKI) based registration as well as certificateless based registration .... aka directly registering the entity's public key. The business process of registering a name from a certificate as equivalent to a userid .... can be shown to be the same as directly registering a public key as equivalent to a userid. The issue then is whether all the additional business processes in support of the various registering process providing information indirection between the name in the certificate and the entity's public key provides real value or is purely redundant and superfluous (given that there has to be a complex infrastructure for not only creating the certificates .... but once created these certificates now also have to be managed). Now the intersection with certifications and smartcards (actually hardwoare token) .... was whether there was a unique token/certificate pair for every environment or whether there was one (or a very small number of) token(s) could be used across a multitude of environments. If the environment supported a registration process, then the above assertion that public key can be directly registered would support that the public key of a single token could be registered in multiple environments. The counter-argument is some future environment that has migrated to hardware token authentication potentially requiring a unique token per environment and an entity possibly having to manage hundreds of such tokens. So an additional assertion is an ideal place for certificates is where there isn't an additional registration process and the certificate is sufficent for establishing both authentication as well as permissions (aka all/any generic employee certificate gets an entity through the door). A corresponding scenario would be a system login that has no userid directory/registration and when presented with a login message with an attached certificate .... it is possible for the login process to establish the complete user environment from just the contents of the certificate (not requiring a userid directory/registration at all). The problem is that tends to require a unqiue certificate for each environment ... which may or may not imply a corresponding unique hardware token. If it requires a unique hardware token, then the future possibility is that people walk around with hundreds of hardware tokens. Moving it out of the digital signature domain but still in the area of authentication might be biometrics. There is the possibility that a login process directly registers a person's fingerprint in the userid directory. The person then types in their userid and applies their finger to a fingerprint sensor. I assert that the direct registration of a person's fingerprint in a userid directory is equivalent to the direct registration of a public key in the userid directory. However, the downside is that a person's fingerprint is, in effect, a shared-secret ... anybody copying the fingerprint representation and being able to regenerate it can impersonate that entity. The upside of public key registration is that it isn't a shared-secret, knowledge of the public key isn't sufficient to impersonate. So sort of a summary .... 1) understanding that the binding/registration process is indenpendent of certificates that represent that process can result in better designs dealing with the two sepaate issues and 2) when there are additional registries (like userid directories) it is possible to view certificates as a type of information indirection and that such levels of indirection may be redundant and superfluous (not that they can't work just that they are redundant and superfluous). some kerberos related threads: http://www.garlic.com/~lynn/subpubkey.html#kerberos and somewhat topic drift ... redundant and superfluous may represent additional complexity and cost that are hard to justify. From recent discussion about DNS, KISS, theory, and practice: http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm tjones@windows.microsoft.com on 2/12/2003 8:21 pm wrote: For better, or worse, the current sc logon to o/s's uses a cert in the sc. It could be argued that the sc really only needs to cache the user's name in an insecure manner, but the point is that a PKI is used to authenticate the user w/ the sc. It seems to work. It's hard to imagine how it could be improved by some structure other than a PKI. There is no biz rule associated w/ the authentication. I doubt that u can argue that it does not work. I am sure that a better sol'n is possible, that is always true. So, let's just use sc w/ cert for logon authN. Ok? ..tom To remove yourself from this list send a message Unsubscribe to epay-request@ca0.net Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EGECm05565 for ietf-pkix-bks; Fri, 14 Feb 2003 08:14:12 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EGEAd05561 for ; Fri, 14 Feb 2003 08:14:11 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA20808; Fri, 14 Feb 2003 17:16:12 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA19574; Fri, 14 Feb 2003 16:07:53 +0100 Message-ID: <3E4D1505.6010509@bull.net> Date: Fri, 14 Feb 2003 17:10:45 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: "Jeffrey I. Schiller" CC: Nick Pope , John Ross , IETF PKIX WG List , "Steven M. Bellovin" Subject: Re: Issues with draft-ietf-pkix-pr-tsa-02.txt References: <3E303A7F.2090609@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1EGECd05562 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff, > The IESG discussed this document on today's telechat. Two issues were > raised. > 1. There needs to be a Security Considerations section! Nick Pope and myself have prepared such a section. Here it is: 8. Security Considerations When verifying time-stamp tokens it is necessary for the verifier to ensure that the TSU certificate is trusted and not revoked. This means that the security is dependent upon the security of the CA that has issued the TSU certificate for both issuing the certificate and providing accurate revocation status information for that certificate. When a time-stamp is verified as valid at a given point of time, this does not mean that it will necessarily remain valid later on. Every time, a time–stamp token is verified during the validity period of the TSU certificate, it must be verified again against the current revocation status information, since in case of compromise of a TSU private key, all the time-stamp tokens generated by that TSU become invalid. Annex C provides guidance about the long term verification of time-stamp tokens. In applying time-stamping to applications, consideration also needs to be given to the security of the application. In particular, when applying time-stamps it is necessary to ensure that the integrity of data is maintained before the time-stamp is applied. The requester ought to really make sure that the hash value included in the time-stamp token matches with the hash of the data. > 2. Is this document identical to its ETSI equivalent? Do we have > permission from ETSI to publish this as an IETF document? Do we > need permission? We do have permission from ETSI for the publication. RFC 3126 has been published with the following advertisement. The contents of this Informational RFC is technically equivalent to ETSI TS 101 733 V.1.2.2 Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org The writing for this new document is nearly the same: The contents of this Informational RFC is technically equivalent to ETSI TS 102 023 V1.2.1 (2002-06) [TS 102023]. The ETSI TS is under the ETSI Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org If this is a problem, we can make it exactly the same: The contents of this Informational RFC is technically equivalent to ETSI TS 102 023 V 1.2.1 (2002-06) [TS 102023] Copyright (C). Individual copies of this ETSI deliverable can be downloaded from http://www.etsi.org Would you tell me whether I can now place the version with the additional security considerations section with the current text about the copyright or with the new proposed text ? (or whether it does not matter which one ?) Regards, Denis > > -Jeff Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EExsS03203 for ietf-pkix-bks; Fri, 14 Feb 2003 06:59:54 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EExqd03198 for ; Fri, 14 Feb 2003 06:59:52 -0800 (PST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1EExECq027431; Fri, 14 Feb 2003 06:59:14 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <15SFCZ3H>; Fri, 14 Feb 2003 06:59:53 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Peter Gietz'" , "Hallam-Baker, Phillip" Cc: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= , ietf-pkix@imc.org, Peter Gutmann , David Chadwick Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 14 Feb 2003 06:59:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_010F_01C2D40F.D0643020"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_010F_01C2D40F.D0643020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > To summarize this thread it seems that following technologies > have been > proposed to publish X.509 certificates: > LDAP/X.500, DNS, HTTP (CertStore) and XML (XKMS). A new draft on Web > Services seems to be on its way. No, XKMS is a Web Service. It is OSCPII and its competitors that are on their way. > May be in different environments different such technologies might be > usefull. What I am missing in this discussion is a clear list of > requirements for certificate retrieval. Alice wants to send email to Bob Alice does not know Bob's Certificate Alice does know Bob's email address. Bob's name is not unique Bob's company will not provide any form of search capabilities beyond exact match. The Trust topology is complex as in a multiple bridge CA Web of trust. XKMS and the planned ASN.1 cert discovery protocols meet these requirements X.500/LDAP are designed to meet different requirements. They cannot address the Web of Trust cert path discovery requirement. > > As to LDAP/X.500: > > Michael has shown that most arguments against LDAP/X.500, He showed no such thing. His arguments were flat and unconvincing except if you are already sold on LDAP/X.500. My empiriacal observation is that companies that try to deploy a Directory based PKI fail far more frequently than those who do not make the directory a critical path component, or make the directory deployment completely subordinate to the PKI. The problem is that Directories offer companies infinite scope for arguing over the structure of DITs etc. The fact that these arguments are important demonstrate the basic immaturity of directory technology. > e.g. privacy > issues, organisations not willing to publish information about their > employess, etc. also hold true for the other technologies. This is empirically wrong. Most VeriSign customers are prepared to publish their certificats in the public directory for retrieval on the basis of exact match of email address. > I vote for LDAP, since it provides an established network > protocol and The customers vote for no-LDAP and have done for the past ten years. > Our proposal for storing certs in LDAP > (draft-klasen-ldap-x509certificate-schema) provides the > possibility to > create a distributed certificate repository, where every CA > can publish > their certs in a DIT structure to their liking ( That is the problem, to their liking means no interoperability. > With the help of an indexing system and the LDAP referral > mechanism a > service can be established that can refer an LDAP client to the LDAP > server on which the certificate searched for is stored. The > alternative > using DNS SRV for locating servers has been mentioned in this thread > already. I originally proposed the SRV mechanism. It can locate a certificate server but it cannot locate a certification path. > Peter Gu.: if you don't know whether to laugh or cry about > our proposal, > please consider that > > ldap:///?caCertificate?sub? > (&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6 > %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43% > 5C83%5C78%5C25%5C70%5C52%5CE0%5C19)) > > is a bit more powerfull that the key/value pair you propose, I don't care how 'powerfull' a mechanism is. The point is that power does not equal utility. Less powerful frequently means more useful. C is a subset of the CPL language and is better for it. Directories are the ADA of network computing. > X.500 bashing on this list is no new phenomenon, look at the pkix > archives and you will find similiar, e.g. quote: > > From chandras@xxx.xxx Tue Mar 11 16:00:16 1997 [sic]: > > "Part of the recent success of X.509 in the internet space, > given it lay on the internet doldrums for years, was its abandonment > of X.500 as mandatory for theory or practice. One can, always > add X.500 back in whenever one wants, of course; as much > or as little as one wants." If X.500 gets bashed it is probably because it deserves to. The above comment is correct. PKI has succeeded in spite of directory nonsense, not as a result. Now that we have alternatives that actually meet our needs it is time to give the unwellcome house guest their marching orders. > In spite of X.500 bashings a consensus seemed to have > established from time to time in this group that LDAP > is a good technology for certificate repositories. The only consensus I can see concerning certificate discovery is that there is a need for a new protocol which duplicates most of the functionality of XKMS in ASN.1 and then adds in some extra twiddles. I don't agree that angle brackets are indigestible but it is better for the group to persue the right architecture than to continue to persue an architecture that has been an abject failure. I don't count large numbers of enterprise directory sales as evidence for success. Try a thought experiment, what happens if the directory goes down, how much work does that event stop getting done? Phill ------=_NextPart_000_010F_01C2D40F.D0643020 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxNDE0 NTk1MFowIwYJKoZIhvcNAQkEMRYEFI8tCf5TMwwcTEl0xyHUfnYip4UWMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAC4kIfeSDFwsaxBE6XgjH5WvkHEKX87LSL5ljq9mkak6W7pNx Wp3FXxZ4cOh3oNdMjLt+YF4W4uIumNpeOWq8afFwzVA3q4jLzjPjjn1uQ/8cY5ABAMxlyQNxWNTM BKtHW3XnQj7PwFfZi00wnAULmiuo7uVLIQ05pVeSZSwTbFcAAAAAAAA= ------=_NextPart_000_010F_01C2D40F.D0643020-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1EEXJS29511 for ietf-pkix-bks; Fri, 14 Feb 2003 06:33:19 -0800 (PST) Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1EEXBd29483 for ; Fri, 14 Feb 2003 06:33:14 -0800 (PST) Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h1EEWtE03550; Fri, 14 Feb 2003 15:32:56 +0100 Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h1EEWt703546; Fri, 14 Feb 2003 15:32:55 +0100 Message-ID: <3E4CFE16.4090701@daasi.de> Date: Fri, 14 Feb 2003 15:32:54 +0100 From: Peter Gietz Organization: DAASI International GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: =?ISO-8859-1?Q?=27Michael_Str=F6der=27?= , ietf-pkix@imc.org, Peter Gutmann , David Chadwick Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1EEXEd29497 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, Sorry to join this thread so late. To summarize this thread it seems that following technologies have been proposed to publish X.509 certificates: LDAP/X.500, DNS, HTTP (CertStore) and XML (XKMS). A new draft on Web Services seems to be on its way. May be in different environments different such technologies might be usefull. What I am missing in this discussion is a clear list of requirements for certificate retrieval. That might be of help to evaluate the different proposals. May be we should write an I-D on this. If others also volunteer I would be willing to put effort into such an activity. Peter Gutman's document on "A Reliable, Scalable General-purpose Certificate Store" would definitely provide some usefull input for such a document. As to LDAP/X.500: Michael has shown that most arguments against LDAP/X.500, e.g. privacy issues, organisations not willing to publish information about their employess, etc. also hold true for the other technologies. I vote for LDAP, since it provides an established network protocol and data modell that is flexible and comes along with important features like authentication, replication and especially distribution of the database. LDAP BTW does not need PKI as killerapp, it is being used as corporate directory since a long time with a lot of different usages. Our proposal for storing certs in LDAP (draft-klasen-ldap-x509certificate-schema) provides the possibility to create a distributed certificate repository, where every CA can publish their certs in a DIT structure to their liking (inside an organisational structure together with white pages and yelow pages information or in a cert only repository). It also solves the problem of multiple certs of a user. With the help of an indexing system and the LDAP referral mechanism a service can be established that can refer an LDAP client to the LDAP server on which the certificate searched for is stored. The alternative using DNS SRV for locating servers has been mentioned in this thread already. David Chadwick's work on an LDAP server that sort of translates between the classical LDAP certificate storage in attributes like userCertificate and our model makes no changes necessary for current clients. But even without such an intermediate server, client modifications would be rather simple (changing the search filters). Peter Gu.: if you don't know whether to laugh or cry about our proposal, please consider that ldap:///?caCertificate?sub? (&(objectClass=x509certificate)(x509subjectKeyIdentifier=%5CE6 %5C7A%5CD9%5C16%5C95%5C4A%5CE1%5C12%5C9F%5C22%5C09%5C6A%5C43% 5C83%5C78%5C25%5C70%5C52%5CE0%5C19)) is a bit more powerfull that the key/value pair you propose, e.g. you could also want to get back the cert's subject, its issuer, its valdity, etc. instead of the cert. BTW in that example it would be fairly safe to do without the "objectClass=x509certificate" bit. Anyway I don't see enough difference between the ldap URL and your http URL to get so high emotions. In combination with David's new draft on CRLs, an OCSP server can be implemented on top of an LDAP server very easily (to come back to the original thread). Your Certstore via an LDAP2Web gateway? again no problem. This is not like your "putting a pea on a fork example" it is more about management efficiancy (one data store and multiple usages for it). One last comment: X.500 bashing on this list is no new phenomenon, look at the pkix archives and you will find similiar, e.g. quote: From chandras@xxx.xxx Tue Mar 11 16:00:16 1997 [sic]: "Part of the recent success of X.509 in the internet space, given it lay on the internet doldrums for years, was its abandonment of X.500 as mandatory for theory or practice. One can, always add X.500 back in whenever one wants, of course; as much or as little as one wants." In spite of X.500 bashings a consensus seemed to have established from time to time in this group that LDAP is a good technology for certificate repositories. X.509 people rediscovered the X.500 model from which X.509 once originated. And I am quite confident that threads like this one will not change this. Cheers, Peter Gi. Hallam-Baker, Phillip wrote: >>Anders Rundgren wrote: >> >>>But the _real_ problem with the X.500 model is that it builds >>>on the assumption that organizations want to publish information >>>for others to search. >> >>Again: This is not a specific problem with the X.500 model. >>It's a general >>problem with certificate retrieval across organizational boundaries. > > > I don't see this as an objection to the X.500/LDAP architecture. > However it is a severe restriction on deployment. > > Since the argument for reuse of LDAP is that it is deployed and > the excuse for reuse of X.500 is that it is going to be deployed > the fact that enterprises will not allow public access to anything > that looks like a directory is very relevant. > > Not making your directory world readable is probably more important > as an enterprise security measure than firewall deployment. > > > >> >>Using a 'web service' (whatever we might agree in the future >>if ever on what >>that really is) will just migrate the very same problems to >>another service. > > > First off, there is considerable agreement on the definition > of Web services. They are machine/machine protocols that are > encapsulated in SOAP messaging. > > Note that there is no requirement to run over HTTP. I think that > in the long run we will move to DIME or something similar. > > > >>That's what folks should understand *before* trying to solve >>problems by >>defining yet another standard with yet another buzz-word. > > > Take a look at the XKMS specs. The problem is really well > understood at this point. > > > >>And I also agree with David that web services just >>circumvents firewalls by simple HTTP tunneling. > > > That is a misconception, although several folk like Bruce > the sage of Minnessota have been plugging away at it. > > First off Web Services need not be layered on HTTP. In > fact DIME is a much cleaner interface. But HTTP has some > near term advantages. > > Secondly a large part of the Web Services architecture is > all about how to route messages through firewalls, the > visibility that messages must have, etc. etc. > > There is an assumption that the firewall does somewhat more > than simply block certain ports. > > >>PKI acceptance is yet another issue independent of X.500 directories. > > > No, the X.500 linkage is the single biggest barrier. It has > led to more failed PKI deployments in my experience than any > other. > > The customers have wanted to deploy a PKI, they are captured by > a directory vendor. They spend three years arguing over theri DIT > instead and erroneously conclude that PKI is hard to deply. > > For PKI deployment to succeed you have to take X.500 and LDAP > deployment out of the critical path. > > >>If someone's to blame for lack of PKI acceptance it's this WG for not >>reaching consensus on very basic issues > > > No, that is not a factor in PKI deployment. This list is no longer > a factor in the development of the PKI world. > > The basic certificate standards are already deployed in Windows > 2000, Java and the rest. The job of this group is to document the > reality that has been created. This group cannot influence changes > in the PKI infrastructure, that has already happened. > > This by the way is the IETF way. HTTP was only standardized some > six years after the protocol was ubiquitous. > > > >>(feel free to check the mailing list >>archive *excluding* the dumb X.500 bashing of last three months) and > > > Was there a previous X.500 bashing thread? I don't think so. > > We have only been on this thread since the new year. > > > >>And no, the problems will not automagically be solved by XML, >>XKMS, >favourite buzz-words here...>. > > > The XML syntax is neither here nor there. I used it simply because > if I ask an engineer to learn ASN.1 they start preparing their resume, > engineers ask me if they can learn XML. > > Whether or not XML is actually superior it has won by any empirical > standard. Choosing to use ASN.1 at this point is like choosing to > use EBSDIC instead of ASCII. > > > I hope that we put rather more into the design of XKMS than simply > rehashing PKIX in XML. In fact that was the one thing that the > original charter did not allow us to do. > > Phill -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 2970336 Wilhelmstr. 106 Fax: +49 7071 295114 D-72074 Tübingen email: peter.gietz@daasi.de Germany Web: www.daasi.de Directory Applications for Advanced Security and Information Management _______________________________________________________________________ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DLiGB27617 for ietf-pkix-bks; Thu, 13 Feb 2003 13:44:16 -0800 (PST) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DLi4d27610 for ; Thu, 13 Feb 2003 13:44:10 -0800 (PST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h1DLcHpp012694 for ; Thu, 13 Feb 2003 16:38:17 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Thu, 13 Feb 2003 16:26:28 -0500 To: ietf-pkix@imc.org From: Stephen Kent Subject: Re: A challenge Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hans, The message clarifying what seems to be the major focus of the German CA law is quite illuminating. I can understand the motivation behind the law in this form, but it is also very much different from what many have said, where the focus was on CA key compromise, vs. cessation of operation of a CA. The requirement stated here could be met in many ways through procedural means of "shutting down" a CA, without revoking its cert. For example, one might mandate that a TTP CA be required to use a separate key for CRL and/or OCSP response signing, and that this key be escrowed. Then one could destroy the cert signing key as a means of shutting down the CA, but still retain the ability to sign revocation status data structures for the lifetime of any certs issued by the CA. That would provide the separation that seems to be the crux of the law, completely within the scope of current PKIX standards, right? Steve Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHTUW16928 for ietf-pkix-bks; Thu, 13 Feb 2003 09:29:30 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DHTRd16918 for ; Thu, 13 Feb 2003 09:29:27 -0800 (PST) Subject: Re: A challenge To: Al Arsenault Cc: Anders Rundgren , epay@ca0.net, ietf-pkix@imc.org, Torsten Hentschel X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Thu, 13 Feb 2003 10:22:53 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/13/2003 12:30:57 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: the article from the cellphone manufactors .... that it was less expensive to provide a mechanism to save the current personality and load it into a new phone than it was to manufactor the slot for the smartcard reader interface ... with a overall infrastructure cost savings. the corresponding assertion was that the current smartcard & smartcard interface was as inexpensive as it was because of the significant investment that was made for generic, unbiquitous smartcard use .... not solely restricted to cellphone personabilities. and finally people could use the personality save/restore to address issue where the smartcard is lost/stolen/damaged. My other assertion was that the existing operation may linger for some time .... since the original smartcard investment has appeared to be written off .... and smartcard use can essentially be had for a few cents on the dollar. The transition to save/restore requires new investment in the save/restore infrastructure .... which means that the cost savings in eliminating the smartcard reader in cellphones would have to cover the save/restore infrastructure investment (and/or people find the additional benefit of having lost/stolen/damaged coverage). Note that the cost savings of using a common smartcard infrastructure is so great that the cellphones and the simms share the same manufactoring components .... down to simms being manufactored as smartcards ... and then the simms punched out of the plastic smartcard form factor. If the other uses of smartcards migrate to various contactless/wireless paradigms for various reasons .... that could mean that cellphone market segment would carry more of the smartcard infrastructure costs (even at a few more cents on the dollar) making it easier to justify the funding of a save/restore infrastructure transition. I didn't say smartcards were wrong. I said that they had a design point based on the technology from the '80s ... and that changed by the early '90s .... effectively making the technology assumptions and requirements from the '80s no longer valid. I wasn't making them (OSI comments) very load in 1983 ... I was doing some other things, although there were jokes about OSI being from pre-1970s, telco, point-to-point copper, high error rate, low bandwidth design point "people" ... aka by the time OSI standard was passed it was also obsolete. While i was doing a little tcp/ip stuff in the 1983 era .... it wasn't a primary focus and I didn't get involved into any OSI issues into slightly later. I was starting to get more vocal about OSI by possible 1985 .... I was starting to become more vocal about it. By interop '88 I was pretty vocal .... there were all these things in there with OSI, x.400, complex monitoring. One of the things at interop '88 ... i would guess that there was even some significant percentage of the IETF community was supporting various of the alternate candidates to SNMP. I had a couple workstations in booth kiddy-corner from the booth where case was "officially" located ... and was able to get Case to install SNMP on the workstations to demo .... even tho large portions of the rest of the booths had various SNMP alternatives. I was also on the XTP technical advisory board and working on HSP. The majority of the people in X3S3.3 were giving us really bad time because X3S3.3 had responsibility for standards related to OSI levels 3&4 ... and the official charter is that you can't have standards that violate OSI levels 3&4. My response was 1) ISO & ANSI are already totally schizophrenic because ethernet standard thru IEEE and recognized as standard at ISO combined levels 1, 2, and part of 3 ... i.e. the MAC interface includes a portion of routing from level 3. HSP was going to go directly from transpart/level4 to LAN interface in the middle of level3. Core X3S3.3 basically said that you couldn't have protocol standard work in X3S3.3 that specified an interface to MAC/LAN .... because that violated OSI. I've had more than a few choice words about gosip also. slightly related .... my wife and I were operating a backbone at the time of NSFNET1/T1 bid ... and weren't allowed to bid ... but a NSF audit of our backbone claimed it was at least five years ahead of all the NSFNET1/T1 bids to build something new. We were also doing some interesting/non-traditional things with crypto at the time ... but that is another story. However we did come up also with 3-layer architecture .... somewhat grew out of a response that my wife wrote and presented to a certain TLA gov agency RFI for enterprise distributed computing environment. That got us into trouble from various factions that were trying to put the client/server genie back into the bottle: http://www.garlic.com/~lynn/subtopic.html#3tier OSI was possibly a bad choice to choose as an example. However, something that I was really agitated about in the early 1980s time-frame was that the traditional mainframe computing environment was starting to commoditize .... first with mid-range computers and then with PCs and workstations. Maybe another example is this thing called electronic commerce. lots of threads related to OSI "blech": http://www.garlic.com/~lynn/subnetwork.html#xtphsp some recent discussions about interop '88 http://www.garlic.com/~lynn/subnetwork.html#interop past threads about high speed networking in the '80s http://www.garlic.com/~lynn/subnetwork.html#hsdt http://www.garlic.com/~lynn/subnetwork.html#internet http://www.garlic.com/~lynn/subnetwork.html#bitnet random past specific mentions regarding gosip: http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model? http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model? http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files? http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom. http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet... http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet? http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private http://www.garlic.com/~lynn/2001e.html#17 Pre ARPAnet email? http://www.garlic.com/~lynn/2001e.html#32 Blame it all on Microsoft http://www.garlic.com/~lynn/2001i.html#5 YKYGOW... http://www.garlic.com/~lynn/2001i.html#6 YKYGOW... http://www.garlic.com/~lynn/2002g.html#21 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/2002g.html#30 Why did OSI fail compared with TCP-IP? http://www.garlic.com/~lynn/2002i.html#15 Al Gore and the Internet http://www.garlic.com/~lynn/2002m.html#59 The next big things that weren't http://www.garlic.com/~lynn/2002n.html#42 Help! Good protocol for national ID card? -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Al Arsenault on 2/13/2003 5:43 am wrote: Lynn, Interesting message from you, as always. Fascinating predictions on the future. Only a few issues need to be raised, IMHO. :-) One of those issues relates to the whole "secure backup and restore" or "secure download" of credentials. That's currently an unsolved problem. Fortunately, IETF has a working group - SACRED - addressing that issue. While SACRED started out a couple of years ago with a lot of interest and enthusiasm, interest seems to have waned. There are only a few people actively participating, and the group is about to wrap up with its solution. While I am others hope that the proposed solution will succeed and solve parts of the problem, it's not a complete solution (e.g., it addresses only device - credential server interactions; it doesn't support device - device operation). So consider this message a plea for others interested in this area to get involved in this work. Until SACRED or some similar solution becomes widely implemented, smartcards - e.g., SIMs or WIMs in phones - aren't going away. The business model in many parts of the world relies on a large number of customers replacing their handsets frequently. In many areas I'm familiar with, it's common for a large set of people to replace their handsets every few months, so that they always have the latest, smallest, most colorful, "coolest" device. The whole notion of a smart card supports this model, by allowing the user to get a new handset and dispose of the old one while maintaining the same service WITHOUT INTERACTING with the mobile operator, because those interactions with the carbon-based life forms who staff the operator outlets represent one of the highest costs in the system. With a SIM/Smart card that can be moved from one handset to another, there's no need to involve any other carbon-based life form. Since there's now no way to securely move the credentials electronically that's widely interoperable (lots of us have our own, somewhat proprietary schemes), for most mobile operators/service providers the smart card remains the method of choice. An automated - read as "efficient and low cost" way to securely register new devices into the system is also a requirement, and it's also currently an unsolved problem. Oh, there are other standards groups working on it, but I'm not sure they're going to have good solutions any time soon. So it's nice to sit here and make statements that "this technology was just wrong, and 20 years from now everyone will acknowledge that it's obvious", but tell me Lynn, how many statements about ISO vs. TCP/IP did you make in 1983? Al Arsenault Diversinet Corp. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHTRF16919 for ietf-pkix-bks; Thu, 13 Feb 2003 09:29:27 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DHTPd16910 for ; Thu, 13 Feb 2003 09:29:25 -0800 (PST) Subject: RE: A challenge To: epay@ca0.net Cc: "Anders Rundgren" , ietf-pkix@imc.org, "Torsten Hentschel" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Thu, 13 Feb 2003 09:27:04 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/13/2003 12:30:55 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: my previously post in this thread was more on the semantics of certificates http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) rather than the most recent post http://www.garlic.com/~lynn/aadsm13.htm#15 A challenge which is about 7816 contact smartcard. one of the issues is that 7816 also pretty much dictates the packaging and form factor. migration away from 7816 contact to any of the contactless/wireless conventions also can totally open up the packaging and form factor issues. my certificate assertion wasn't that you can't have certificates representing a binding/association registration process, my assertion was that the certificates .... were actually that ... just a representation of a binding/association registration process (along with a side note that in an online environment the use of certificates as a representation of the binding/association registration process would frequently redundant and superfluous ... not that it wouldn't work). My primary points were 1) that it seems that sometimes that the certificates are mistaken for the binding/associationr registration business process ... as opposed to just a representation of the binding/association registration business process (originally targeted for recipients who would never have been involved in any binding/assication registration business process) .... and 2) that sometimes such semantic confusion can complicate processes with regard to which are addressing the binding/association registration business process and which are addressing just the management of things that represent that binding/association registration business process (especially in an online environment when having separate representations can be redundant and superflous). However, just because something may be redundant and superfluous doesn't mean that it can't work. The issue in something like login .... is supposedly something has been registered to allow login .... in the PKI/certificate case, presumably what has been registered is some information that is bound in a PKI certificate (name, serial number, etc) ... in addition, the login process has the public key registration of acceptable certification authorities (that can be used to validate acceptable certificates to the login process). I've never claimed that doesn't work ... I've just claimed that frequently it is possible to show semantic equivalence between the login process registration of some value out of a certificate and the login process registration of the public key directly; The PKI registration process provides a type of information mapping indirection (somewhat like DNS provides a real-time mapping between hostnames and ip-address) .... where the CA digital signature asserts to the equivalence of the information (like a person's name or userid) bound in a certificate and a public key. The login process then has a set of registered CA public keys. In the PKI scenario, the login process gets a signed message that has an appended digital signature and an appended certificate. The login process finds the registered CA public key and validates the certificate, it then uses the public key in the certificate to validate the signed message. At this point it presumably has a proven equivalence between the entity sending the message and some bound information in the certificate (like a name). The login process can then have its own registry that maps between names found in certificates and userids .... and uses that to establish a valid login for that userid. The informaiton assurance mapping goes I've never asserted that it doesn't work. I have asserted that in situation where the login process has its own registery and mapping; that directly registering an entity's public key bound to a userid .... can be equivalent to a entity registering their public key with a CA, the CA signing a certificate that equates a name in a certificate with that public key, and then the login process registering a name in a certificate bound to a userid. The issue isn't that the levels of PKI information indirection (between public key and userid) don't work, the point was purely that they may be superfluous and redundant. This is somewhat equivalent to the IETF pk-init draft for Kerberos which provides for both certificate (aka PKI) based registration as well as certificateless based registration .... aka directly registering the entity's public key. The business process of registering a name from a certificate as equivalent to a userid .... can be shown to be the same as directly registering a public key as equivalent to a userid. The issue then is whether all the additional business processes in support of the various registering process providing information indirection between the name in the certificate and the entity's public key provides real value or is purely redundant and superfluous (given that there has to be a complex infrastructure for not only creating the certificates .... but once created these certificates now also have to be managed). Now the intersection with certifications and smartcards (actually hardwoare token) .... was whether there was a unique token/certificate pair for every environment or whether there was one (or a very small number of) token(s) could be used across a multitude of environments. If the environment supported a registration process, then the above assertion that public key can be directly registered would support that the public key of a single token could be registered in multiple environments. The counter-argument is some future environment that has migrated to hardware token authentication potentially requiring a unique token per environment and an entity possibly having to manage hundreds of such tokens. So an additional assertion is an ideal place for certificates is where there isn't an additional registration process and the certificate is sufficent for establishing both authentication as well as permissions (aka all/any generic employee certificate gets an entity through the door). A corresponding scenario would be a system login that has no userid directory/registration and when presented with a login message with an attached certificate .... it is possible for the login process to establish the complete user environment from just the contents of the certificate (not requiring a userid directory/registration at all). The problem is that tends to require a unqiue certificate for each environment ... which may or may not imply a corresponding unique hardware token. If it requires a unique hardware token, then the future possibility is that people walk around with hundreds of hardware tokens. Moving it out of the digital signature domain but still in the area of authentication might be biometrics. There is the possibility that a login process directly registers a person's fingerprint in the userid directory. The person then types in their userid and applies their finger to a fingerprint sensor. I assert that the direct registration of a person's fingerprint in a userid directory is equivalent to the direct registration of a public key in the userid directory. However, the downside is that a person's fingerprint is, in effect, a shared-secret ... anybody copying the fingerprint representation and being able to regenerate it can impersonate that entity. The upside of public key registration is that it isn't a shared-secret, knowledge of the public key isn't sufficient to impersonate. So sort of a summary .... 1) understanding that the binding/registration process is indenpendent of certificates that represent that process can result in better designs dealing with the two sepaate issues and 2) when there are additional registries (like userid directories) it is possible to view certificates as a type of information indirection and that such levels of indirection may be redundant and superfluous (not that they can't work just that they are redundant and superfluous). some kerberos related threads: http://www.garlic.com/~lynn/subpubkey.html#kerberos and somewhat topic drift ... redundant and superfluous may represent additional complexity and cost that are hard to justify. From recent discussion about DNS, KISS, theory, and practice: http://www.garlic.com/~lynn/aadsm12.htm#9 Crypto Forum Research Group ... fyi http://www.garlic.com/~lynn/2003c.html#24 Network separation using host w/multiple network interfaces http://www.garlic.com/~lynn/2003c.html#56 Easiest possible PASV experiment http://www.garlic.com/~lynn/2003c.html#57 Easiest possible PASV experiment -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm tjones@windows.microsoft.com on 2/12/2003 8:21 pm wrote: For better, or worse, the current sc logon to o/s's uses a cert in the sc. It could be argued that the sc really only needs to cache the user's name in an insecure manner, but the point is that a PKI is used to authenticate the user w/ the sc. It seems to work. It's hard to imagine how it could be improved by some structure other than a PKI. There is no biz rule associated w/ the authentication. I doubt that u can argue that it does not work. I am sure that a better sol'n is possible, that is always true. So, let's just use sc w/ cert for logon authN. Ok? ..tom Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DHKbn15727 for ietf-pkix-bks; Thu, 13 Feb 2003 09:20:37 -0800 (PST) Received: from amatabogados.com ([213.229.156.25]) by above.proper.com (8.11.6/8.11.3) with SMTP id h1DHKZd15718 for ; Thu, 13 Feb 2003 09:20:36 -0800 (PST) Received: from host [80.26.116.141] by amatabogados.com (SMTPD32-4.07) id A47AA62028C; Thu, 13 Feb 2003 18:23:06 +0100 Message-ID: <002701c2d37f$a8accf00$0200a8c0@host> From: "Pere Fiol" To: "ietf" Subject: RFC3161(TSP): doubts about tcp protocol Date: Thu, 13 Feb 2003 17:47:55 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01C2D388.09DBADC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C2D388.09DBADC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've developed a TSA but I have a doubt in TCP protocol: if a client = sends a request to TSA with invalid TCP message (for example with a flag = different of '00'H, with wrong number of bytes in length,...) What must = do a TSA in this situations?? RFC3161 mustn't talk something about it?? Thanks and Best Regards, Pere Fiol ------=_NextPart_000_0024_01C2D388.09DBADC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I've developed a TSA but I have a = doubt in TCP=20 protocol: if a client sends a = request to TSA=20 with invalid TCP message (for example with a flag different of = '00'H, with=20 wrong number of bytes in length,...) What must do a TSA in this situations?? RFC3161 = mustn't talk=20 something about it??
 
Thanks and Best Regards,
Pere Fiol
 
------=_NextPart_000_0024_01C2D388.09DBADC0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1DCiiZ00733 for ietf-pkix-bks; Thu, 13 Feb 2003 04:44:44 -0800 (PST) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1DCihd00729 for ; Thu, 13 Feb 2003 04:44:44 -0800 (PST) Received: from SJOSEPH (pcp239416pcs.elictc01.md.comcast.net [68.55.244.2]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.09 (built Jan 7 2003)) with SMTP id <0HA80059IZEFDI@mtaout03.icomcast.net> for ietf-pkix@imc.org; Thu, 13 Feb 2003 07:44:39 -0500 (EST) Date: Thu, 13 Feb 2003 07:43:48 -0500 From: Al Arsenault Subject: Re: A challenge To: lynn.wheeler@firstdata.com, Torsten Hentschel Cc: Anders Rundgren , ietf-pkix@imc.org, epay@ca0.net Message-id: <008a01c2d35d$8e4d6010$6501a8c0@SJOSEPH> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lynn, Interesting message from you, as always. Fascinating predictions on the future. Only a few issues need to be raised, IMHO. :-) One of those issues relates to the whole "secure backup and restore" or "secure download" of credentials. That's currently an unsolved problem. Fortunately, IETF has a working group - SACRED - addressing that issue. While SACRED started out a couple of years ago with a lot of interest and enthusiasm, interest seems to have waned. There are only a few people actively participating, and the group is about to wrap up with its solution. While I am others hope that the proposed solution will succeed and solve parts of the problem, it's not a complete solution (e.g., it addresses only device - credential server interactions; it doesn't support device - device operation). So consider this message a plea for others interested in this area to get involved in this work. Until SACRED or some similar solution becomes widely implemented, smartcards - e.g., SIMs or WIMs in phones - aren't going away. The business model in many parts of the world relies on a large number of customers replacing their handsets frequently. In many areas I'm familiar with, it's common for a large set of people to replace their handsets every few months, so that they always have the latest, smallest, most colorful, "coolest" device. The whole notion of a smart card supports this model, by allowing the user to get a new handset and dispose of the old one while maintaining the same service WITHOUT INTERACTING with the mobile operator, because those interactions with the carbon-based life forms who staff the operator outlets represent one of the highest costs in the system. With a SIM/Smart card that can be moved from one handset to another, there's no need to involve any other carbon-based life form. Since there's now no way to securely move the credentials electronically that's widely interoperable (lots of us have our own, somewhat proprietary schemes), for most mobile operators/service providers the smart card remains the method of choice. An automated - read as "efficient and low cost" way to securely register new devices into the system is also a requirement, and it's also currently an unsolved problem. Oh, there are other standards groups working on it, but I'm not sure they're going to have good solutions any time soon. So it's nice to sit here and make statements that "this technology was just wrong, and 20 years from now everyone will acknowledge that it's obvious", but tell me Lynn, how many statements about ISO vs. TCP/IP did you make in 1983? Al Arsenault Diversinet Corp. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CKjXL06038 for ietf-pkix-bks; Wed, 12 Feb 2003 12:45:33 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CKjTd06033 for ; Wed, 12 Feb 2003 12:45:29 -0800 (PST) Subject: Re: A challenge To: Torsten Hentschel Cc: Anders Rundgren , ietf-pkix@imc.org, epay@ca0.net X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 12 Feb 2003 13:47:08 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/12/2003 03:47:01 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I assert that the traditional smartcards are somewhat like dinosours ... the signal just hasn't reached the brain yet. I assert that the basic smartcard design point was during the '80s for a portable computing device .... that predated the availability of portable input/output capability. Basically you carried all the computing around in the 7816 smartcard form factor and used it at generic input/output stations. However, that market niche had disappeared sometime in the early 90s with the advent of portable input/output capability in the form of cellphones and PDAs. I would guess that up to that point there had been tens of billions of dollars in the technology that all had to be written off. To some extent the smartcard continues on with a little bit life of its own .... in part the investment has totally been written off .... and with zero-sum budgetting .... even if you only could leverage the earlier investment at a few cents on the dollar ... the technology continues to linger around. So one of the places to leverage essentially the 7816 investment was supporting transferrable personality for cellphones. However, in the past year or two there have been articles on the incremental cost that providing such a reader represents in cellphone manufactor. Furthermore, this transferrable personality implementation still has several gaps .... the phone can be lost/stolen, there can be physical/electronic failure in the smartcard, and even the contact interface represents additional points of failure for the cellphone. The story line went something like an online backup/restore of the personality subsumes all the function of the smartcard as well as addresses all the additional shortcomings .... while negating the need for having the additional cost of the smartcard interface (as well as eliminating a point of failure in the cellphone). The issue is that even with only needing a few cents on the dollar (compared to the original 7816 investment) .... the smartcard in the cellphone still can't address all the requirements .... and the online back/restore which does address all the requirements then, obsoletes the necessity for the smartcard. And, as per the cellphone business discussions, cellphone manufactors can save some additional pennies on the cellphone manufactor as well as eliminating a point-of-failure (the contact infrastructure for sliding the card in/out). There is a requirement to possibly uniquely identify the use of the cellphone. In the digital signature world ... that somewhat maps to a hardware token with an on-chip generated key-pair .... and the private key never leaves the device. This can be built into the cellphone .... either as ROM in an existing chip .... or as a separate chip somewhat like the TCPA strategy. So a scenario is that as part of online restore into a new cellphone .... either a previous key-pair is backed-up and restored .... or that the device unique key is then re-registered in all the places that the previous cell phone had been registered. And as per my previous post in the thread ... the registration/binding business process is actually independent of whether or not a certificate is issued ... aka the original certificate design point (from somewhat the same '80s era as original smartcard) was a way of representing the registration/binding business process for an offline environment (which had no direct access to the authoritative registry). http://www.garlic.com/~lynn/aadsm13.htm#14 A challenge (addenda) One problem is that even if the smartcard was purely restricted to the protection and digital signature use of a private key .... there still is the whole unresolved issue of lost/stolen devices ... and any moving parts (even just slipping card in/out past contacts) are more prone to failure than purely electronic operation. Note this is also given as one of the reasons for the migration to ISO 14443 and away from ISO 7816 is because of the mechanical failure issues ... especially in high-traffic areas. This brings up the whole issue of possible competing contactless technologies coming to bear .... 14443, 802.11, bluetooth, cellphone, etc. some tcpa related discussions http://www.garlic.com/~lynn/2002i.html#71 TCPA http://www.garlic.com/~lynn/2002j.html#55 AADS, ECDSA, and even some TCPA http://www.garlic.com/~lynn/2002n.html#18 Help! Good protocol for national ID card? also http://www.garlic.com/~lynn/index.html#aads has URL to a talk on assurance that i gave at the TCPA track at past intel developer's conference. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Torsten Hentschel on 2/12/2003 1:31 am wrote Hi Anders, ... snip ... > ============================================ > But frankly I see no future in smart cards of the type Germany > is investing in. A mobile phone is such a tremendously > more powerful "container" that allows users to do things > that smart card owners cannot even _dream_ about. Since > mobile phones are on-line by definition, static key and > certificate schemes then become rather irrelevant. > ============================================ Well, mobile phones contain smart cards, don't they? I do absolutely not see the dead end here. Kind regards, Torsten -- Torsten Hentschel [The positions of mine as outlined above are not neccessarily Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1CEt3Z19930 for ietf-pkix-bks; Wed, 12 Feb 2003 06:55:03 -0800 (PST) Received: from ratatosk.pdc.kth.se (ratatosk.pdc.kth.se [193.10.159.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1CEt0d19925 for ; Wed, 12 Feb 2003 06:55:00 -0800 (PST) X-Rcpt-To: unknown X-Mail-From: mulmo@pdc.kth.se X-Client: pb-d-128-141-47-136.cern.ch (128.141.47.136) Received: from fiololle.pdc.kth.se (pb-d-128-141-47-136.cern.ch [128.141.47.136]) (authenticated bits=0) by ratatosk.pdc.kth.se (8.12.6/8.12.6) with ESMTP id h1CEstuh214897; Wed, 12 Feb 2003 15:54:56 +0100 (CET) Reply-To: From: "Olle Mulmo" To: "Simon Tardell" , "'Anders Rundgren'" , Cc: , "'Torsten Hentschel'" Subject: RE: A challenge Date: Wed, 12 Feb 2003 15:54:49 +0100 Message-ID: <002d01c2d2a6$b0adf5f0$882f8d80@pdc.kth.se> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <03ea01c2d1ef$199613d0$0a01a8c0@stl> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: What whitelist protocol did the police use? RTCS? :-) /Olle -----Original Message----- From: Simon Tardell Sent: den 11 februari 2003 18:01 [snip] Interestingly enough, in the physical world things are moving the other way. I renewed my passport recently and nowadays you don't have to bring a "personbevis" (a paper stating that there exists a person with my name and number). The police is online, they already know! Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C8WD617168 for ietf-pkix-bks; Wed, 12 Feb 2003 00:32:13 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C8WBd17158 for ; Wed, 12 Feb 2003 00:32:11 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id CAA10593; Mon, 17 Feb 2003 02:12:54 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h1C8Vv902293; Wed, 12 Feb 2003 09:31:57 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E4A067C.9070905@authentidate.de> Date: Wed, 12 Feb 2003 09:31:56 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org Subject: Re: A challenge References: <032f01c2d119$fbf12e30$0a01a8c0@stl> <2750407.1044980962718.JavaMail.root@email.authentidate.de> In-Reply-To: <2750407.1044980962718.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Anders, as of my knowledge some of your assumptions about "German way" / "German law" are wrong. > I also wonder if competing CAs actually "like" the idea to share > EE-keys, be it an irrational consideration or not. Perhaps you did not mean to refer to Germany with the statement above. But I answer it as if: EE-keys may not be shared. By law they are enforced to exist exactly once: in the control of its holder; nobody else may have enough information to reconstruct this key. As a consequence in practice the key resides on a mobile secure device: the smart card. Even if you wanted to talk about EE-certs (instead of EE-Keys): There is no requirement for CA Andrew to distribute the EE-certs issued by CA Berta within the directory of Andrew as well, unless the regulation authority explicitly tells to do so (this may only happen if Berta is closed due to misbehaviour or insolvency). > ============================================ > But frankly I see no future in smart cards of the type Germany > is investing in. A mobile phone is such a tremendously > more powerful "container" that allows users to do things > that smart card owners cannot even _dream_ about. Since > mobile phones are on-line by definition, static key and > certificate schemes then become rather irrelevant. > ============================================ Well, mobile phones contain smart cards, don't they? I do absolutely not see the dead end here. Kind regards, Torsten -- Torsten Hentschel [The positions of mine as outlined above are not neccessarily Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1C6V2r29654 for ietf-pkix-bks; Tue, 11 Feb 2003 22:31:02 -0800 (PST) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1C6V1d29647 for ; Tue, 11 Feb 2003 22:31:01 -0800 (PST) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA12567 for ; Wed, 12 Feb 2003 17:30:54 +1100 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpd0htqm2; Wed Feb 12 17:30:29 2003 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id RAA28203 for ; Wed, 12 Feb 2003 17:30:27 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0Q_lO_; Wed Feb 12 17:30:06 2003 Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id RAA22408 for ; Wed, 12 Feb 2003 17:30:05 +1100 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt - binding key to 1 alg Date: Wed, 12 Feb 2003 16:29:36 +1000 Message-ID: <73388857A695D31197EF00508B08F29806EE175B@ntmsg0131.corpmail.telstra.com.au> Thread-Topic: I-D ACTION:draft-ietf-pkix-rsa-pkalgs-00.txt Thread-Index: AcK2YFPkqMGhILE6QFiPOQyHziK1EgbvYExg From: "Manger, James H" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1C6V2d29651 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Constraining the algorithms with which a key is used is good security practice so there is sense in including a constraint to this effect in a certificate. However, I am not sure that: a) the subjectPublicKeyInfo field should hold this constraint and b) the syntax for the constraint should be an Alg.Id. Jim Schaad's comments #8 and #13 (confusion about how to compare the parameters of a signature or encryption with the parameters from subjectPublicKeyInfo) are due to the constraint being specified with an Alg.Id, which is not quite appropriate (e.g. by including a saltLength field that is irrelevant). Consider other possible (& reasonable?) constraints that you may wish to express: 1* Use this key for RSASSA-PSS signatures with SHA-1 or MD5 as the hash algorithm. [Cannot be expressed as RSASSA-PSS-params only has a single hashAlgorithm field] 2* Use this key for RSASSA-PSS signatures or RSAES-OAEP encryption, but not with any other algorithms. [Cannot be expressed as subjectPublicKeyInfo only has a single Alg.Id] 3* Only use id-sha1-with-dss-signature for signing. [Cannot be expressed as this signature OID has NULL parameters, but {p, q, g} need to be specified.] 4* Tell your signing software only to use RSASSA-PSS with this key, but don't prevent some legacy apps from accepting your signature. [Cannot be expressed as legacy apps reject the cert as they don't accept id-RSASSA-PSS in subjectPublicKeyInfo. To work, the constraint needs to be in a non-critical extension.] A better solution would be to define a new extension to hold the constraint. Mark it critical to guarantee enforcement of the constraint, or non-critical to supply the info but maintain some backward compatibility. algorithmConstraints EXTENSION ::= { SYNTAX AlgConstraintsSyntax IDENTIFIED By id-ce-algorithmConstraints } AlgConstraintsSyntax ::= ...???????... this is the hard bit A simple syntax would be: SEQUENCE OF OBJECT IDENTIFIER -- An Alg.Id is acceptable iff its OID is in the sequence. Or the same simple syntax with more complex semantics: SEQUENCE OF OBJECT IDENTIFIER -- An Alg.Id is acceptable iff its OID -- and all the OIDs of any other Alg.Ids -- in its parameters field (inc. defaults if absent) -- are all in the sequence Or something really generic: Filter -- see X.511 -- applied to a "virtual entry" containing just the Alg.Id in question Or... ---------- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Saturday, 8 February 2003 4:59 AM Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt ... ---------- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, 8 January 2003 12:30 AM Title : Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Author(s) : R. Housley, B. Kaliski Filename : draft-ietf-pkix-rsa-pkalgs-00.txt Pages : 22 Date : 2003-1-6 This document supplements RFC 3279. It describes the conventions for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key transport algorithm, and additional one-way hash functions with the PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BH2FP02904 for ietf-pkix-bks; Tue, 11 Feb 2003 09:02:15 -0800 (PST) Received: from nalle.datum.nu ([217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BH2Dd02900 for ; Tue, 11 Feb 2003 09:02:13 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id C12C610F6DF; Tue, 11 Feb 2003 18:00:53 +0100 (CET) From: "Simon Tardell" To: "'Anders Rundgren'" , Cc: , "'Torsten Hentschel'" Subject: RE: A challenge Date: Tue, 11 Feb 2003 18:00:37 +0100 Message-ID: <03ea01c2d1ef$199613d0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00a401c2d1e9$5a3122f0$0500a8c0@arport> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders, > Simon, > Aaah. So the cards would contain "redundant" certificates using > the same keys. > > You also claim that one should not put certificates in signed > messages as it is only the key that matters. That of course > works from a cryptographic point of view. It works from an application point of view as well, I'd say. > But RPs must have a way to associate they key with > a name. A certificate does this function. "Something" must > (or is usually assumed to) be asserted in signatures to > notify where the issuer is to be found. Generally assumed to, yes. Must, no. The relying party only has to know what identity is claimed. That identity is used to look up certificates from whatever issuer the relying party trusts. It doesn't matter which issuer the client trusts, although it perhaps doesn't seem probable that there would be a certificate associated with the clients key that the client doesn't somehow trust the issuer of (but it is certainly possible). The clients' claimed identity can be encoded in a self-signed certificate, since not all signed formats have a separate field for "claimed identity". > Anyway, in Sweden this would *not* work as the 24h government > uses the TTP-issued certificates to vouch for citizenship and > citizen registration code. By doing that all authorities do > not necessarily need to have the citizen-register on-line as > the certificates themselves form sort of a "distributed > citizen database". That is of course utterly stupid. The authority pushes some of its processing complexity onto the client. On not onto the client machine, but the client human. Interestingly enough, in the physical world things are moving the other way. I renewed my passport recently and nowadays you don't have to bring a "personbevis" (a paper stating that there exists a person with my name and number). The police is online, they already know! > I also wonder if competing CAs actually "like" the idea to > share EE-keys, be it an irrational consideration or not. In the German case the idea was to force it on them by law. In a more general situation I can see that they would, issuing smart cards is a lot more expensive than issuing certs to a smart card issued by someone else. Simon. Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BGTRl01131 for ietf-pkix-bks; Tue, 11 Feb 2003 08:29:27 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BGTNd01119 for ; Tue, 11 Feb 2003 08:29:24 -0800 (PST) Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h1BGTBbF009494; Tue, 11 Feb 2003 17:29:11 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <00a401c2d1e9$5a3122f0$0500a8c0@arport> From: "Anders Rundgren" To: "Simon Tardell" , Cc: , "Torsten Hentschel" References: <032f01c2d119$fbf12e30$0a01a8c0@stl> Subject: Re: A challenge Date: Tue, 11 Feb 2003 17:19:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon, Aaah. So the cards would contain "redundant" certificates using the same keys. You also claim that one should not put certificates in signed messages as it is only the key that matters. That of course works from a cryptographic point of view. But RPs must have a way to associate they key with a name. A certificate does this function. "Something" must (or is usually assumed to) be asserted in signatures to notify where the issuer is to be found. Anyway, in Sweden this would *not* work as the 24h government uses the TTP-issued certificates to vouch for citizenship and citizen registration code. By doing that all authorities do not necessarily need to have the citizen-register on-line as the certificates themselves form sort of a "distributed citizen database". I also wonder if competing CAs actually "like" the idea to share EE-keys, be it an irrational consideration or not. ============================================ But frankly I see no future in smart cards of the type Germany is investing in. A mobile phone is such a tremendously more powerful "container" that allows users to do things that smart card owners cannot even _dream_ about. Since mobile phones are on-line by definition, static key and certificate schemes then become rather irrelevant. ============================================ Anders ----- Original Message ----- From: "Simon Tardell" To: "'Anders Rundgren'" ; "'Denis Pinkas'" ; Cc: ; "'Stephen Kent'" Sent: Monday, February 10, 2003 16:35 Subject: RE: A challenge Anders, > To have redundant certificates in case the CA goes haywire > seems like a very peculiar solution and will force users to > select the proper certificate. Which is? Not at all. A signature is made with a key, not a certificate. As long as the identity of the certificate is not signed into the message, any certificate that corresponds to the right key can be used to validate the signature. The certificate may be sent with the signed message or obtained from somewhere else. It is largely the headache of the verifier. The certificate that is used to verify the signature may even be issued after the signature is made. (And in fact, this would be a reasonable possible consequence of having CA redundancy -- after some time it could happen that both CAs that certify a certain key-identity-binding are replacement CAs deployed after the first signatures were made with the card) For some reason the common paradigm is to let users chose a certificate associated with a key to imply the key. This practice requires the certificate to be present at the client. Or rather, *a* certificate. The certificate could be e.g. a self-signed cert (issued by the smart card itself at production time just to supply a GUI handle to applications looking for, and to supply a subject name for the end entity to claim, if the application needs one). This would remove the need to ever update the smart card. Or, as Sun would say, the network is the computer. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BGMPw29922 for ietf-pkix-bks; Tue, 11 Feb 2003 08:22:25 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BGMLd29913 for ; Tue, 11 Feb 2003 08:22:21 -0800 (PST) Subject: RE: A challenge (addenda) To: "Simon Tardell" Cc: "'Anders Rundgren'" , "'Denis Pinkas'" , ietf-pkix@imc.org, "'Stephen Kent'" , Olaf.Schlueter@secartis.com, epay@ca0.net X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Tue, 11 Feb 2003 09:23:36 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/11/2003 11:23:53 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ref: http://www.garlic.com/~lynn/aadsm13.htm#13 in fact, i would assert that is one of the short comings of mistaken the certificate being the binding ... as opposed to representing the business process of having done the binding. in lots of businesses ... they will do their own binding business process .... based on their own business requirements. that is somewhat the appearance of the relying-party-only certificates as opposed to the earlier, one-size-fits-all, identity x509 certificates. the issue is that the relying-party-only certificates are very analogous to a bank issuing a payment card .... originally one for every account or type of account. this is in the old offline days .... the merchant (standing in for the bank) in an offline environment examined the card and checked it against a paper booklet negative list mailed out once a month or so. in the transition to the online environment, a magstripe was placed on the back of the certificate .... and online transactions were being performed directly with the bank. this representing somewhat of a schizophrenic identity for the piece of plastic .... since it now carried the characteristics of operating both in the offline environment (the plastic credential and the paper booklet) or in an online environment (the magstripe on the back). >From a consumer perspective ... the incomplete migration to totally online .... has had a down side .... potentially tens of plastic cards needing to be carried around. The magstripe is just on the verge of not having to be unique. It still is shared-secret based (account number and pins) which standard security requires unique shared-secret for different security domains. A migration to totally online and a migration to non-shared-secret (say digital signature public key) would eliminate the security requirement for 1) unique physical certificate/credential that is used in offline situations by stand-in parties/merchants responsible for examining the validity of the (plastic) certificate and 2) unique shared-secret. The assertion is then that a single hardware token performing digital signature authentication can be used as binding device in multiple different contexts (since there is not the uniqueness security requirement that exists for shared-secret paradigms) and that the token would only require a certificate representing each of those binding contexts if the token were to be used in offline operations (requiring validation by 3rd parties not having access to the responsible binding authority). As long as the token was used in online transactions involving the business process that was also the binding authority .... or in business processes with entities that had online access to the binding authority ... then certificates representing such binding business processes are redundant and superfluous. So the scenario is some future environment that is extensively digitally signature authentication oriented with some token. Continuing to emulate the old offline paradigm where a unique token/certificate exists for each context potentially means that individuals carry hundreds of such tokens. This is somewhat analogous to the evolving copy protection paradigm of the early 80s where each application required that a unique floppy disk had to be inserted. If this were to continue into today's environment an individual would have hundreds of copy protection floppy disks .... and constantly swapping floppy disks ... simarily one could imagine having hundreds of hardware tokens and having to constantly swap them. Now there is some possibility of just returning to the simple, one-size-fits-all, identity x509 certificate. However, there is still the idea of binding a person to a specific bank account. Just because a person has a x509 identity certificate doesn't mean that they can draw money from every account at every bank (or the existance of a x509 certificate doesn't equate to being permitted to perform all possible business operations). If there is a single certificate ... and it represents all possible binding operations ... then either the information about all such bindings has to be carried in the same certificate ... or the bindings have to be available at some online location. So doing the mapping of the offline certificate paradigm to an online binding environment .... would imply that some value from the certificate is registered in the online binding registry/account-record. However, if some value is to be registered .... it is possible to have an account number and the binding registry directly registers the public key This bypasses the levels of indirection involved in registering something about a certificate which is offline representation of the business process of binding/registering something about the public key. If I were going to register something about a certificate in an online binding registry (say is a specific entity entitled to withdraw money from this specific bank account) .... and a public key certificate is just an offline representation of some other online binding registry/authority (that just possibly isn't always online or directly accessable) ... I assert that it is possible to register the public key directly and dispense with the levels of indirection related to registering anything about the certificate. So lots & lots of certificates ... each uniquely carrying some collection of possible binding attributes (like permissions, authorizations, etc). Or a few certificates .... that only carry a very few binding attributes related to a public key. Then individual operations carry online account records with the actual permissions and a mapping to some value in a certificate. However, it is possible in such situations to eliminate the indirection of registering the certificate that maps to the public key ... and just register the public key. Normally, levels of indirection help when they allow change w/o affecting all the binding registries .... aka in the internet domain name system .... I can use the host name www.something ... and not need to worry about it may having dozens of different ip addresses that can change over time. However, if i'm dealing with a certificate indirection infrastracture that I know is a direct mapping to a single public key and the same certificate will never mask a remapping to a totally different public key then I can bypass the certificate indirection and just record the public key. One such situation would be a generic employee certificate .... there are lots and lots of them .... all mapping to different public keys. There is an environment that doesn't have (or need) direcl access to the online employee binding registry and only cares whether somebody has a valid employee binding (represented by their generic employee certificate) but doesn't actually care who the employee is (and the situation is low-value enough that it doesn't require real-time access to the real employing binding registry). However, this has the down-side attribute that it represents the lots & lots of certificate paradigm. a unique generic certificate is required for each unique (low-value) domain (work, home, ISP login, specific website, etc). As soon as something like ISP login requires specific authorization information .... it is either in the certificate ... or in an online account record. If it needs to register a unique value from a certificate that is unique for each authorized public key ... then it can go ahead and register the public key directly and dispense with any registering of anything related to a certificate (and some other agency's binding operation). An ISP family certificate would work if it listed a dozen different public keys ... and the certificate could change the listed public keys in a trusted and reliable way that the ISP need never be aware that it was happeing. However, in the internet domain name scenario this works because it is an online registry .... there aren't these offline credentials (representing the binding process) with long lifetimes floating around that can go bad and potentially need constant checking for revokation. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BECdf21821 for ietf-pkix-bks; Tue, 11 Feb 2003 06:12:39 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BECbd21815 for ; Tue, 11 Feb 2003 06:12:37 -0800 (PST) Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id h1BECWJ02049; Tue, 11 Feb 2003 15:12:32 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Tue Feb 11 15:12:32 2003 Subject: Antwort: Re: A challenge To: Stefan Santesson Cc: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Tue, 11 Feb 2003 14:31:49 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 11.02.2003 15:12:22 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, first, to avoid confusion: RTCS is Peter's idea and he invented it for a different purpose. Second, you are right, a white list check if applied every time is obsoleting the signature on the certificate. The signature in the certificate allows you to decide whether to rely on the certificate integrity and correct issuance. Normally. But if the CA's public key is no longer trustworthy you are in trouble, you have to reject all certificates of that CA then as you no longer can distinguish correct certificates from forged certificates. In that case a white list check (and that is how it is applied in some systems in Germany today) provides a second resort. The (German)OCSP response you get is protected by another still trustworthy key with independent security. A signed (German)OCSP response with status for a specific certificate is a "kind of" certificate on its own. Once you have obtained it you can reuse it later on for checking as long as the OCSP responder's signing key remains trustworthy (at least to check signatures that have been created before the point in time the OCSP response has been created), To check later signatures you can use a PKIX-compliant OCSP responder, as the fact that a certificate is on a white list will never change (but revocation state may do). As far as I understand RTCS in its current shape could be used the same way. I do not really favour introducing white list checking into PKI systems.The introduction of white list checking into PKIX would be an alteration of the PKIX model. It would cause confusion as with white list checking in PKIX you would have two different ways to verify a certificate: one way based on local trusted key repositories and CRLs, another way extended by a white list. This is probably the reason why most people on this list are rejecting the idea. I just want to illustrate that the idea of a white list is not as senseless and paradox as it looks on first sight. And unfortunately the real German system is not exactly behaving the way as described above. At the root-level the independent key security is not given, or more exactly, most law-aware applications do not treat the root directory key as an independent trusted key. They ask for a certificate of this key signed by the root key. Stefan Santesson t@spray.se> Kopie: ietf-pkix@imc.org, Stephen Kent Thema: Re: A challenge 08.02.2003 23:05 Olaf, The moment you introduce RTCS you have obsoleted the whole concept of using X.509 certificates. The function of a certificate is to provide proof over time, during which, status service is provided. OCSP can relay the information of a CRL and has therefore a place in this structure as a service that can be provided by someone other than the CA. It seams that RTCS must be provided by the CA. If the CA is compromised, you can't trust the RTCS either (unless complex key structure is used), so no benefits there. If the CA is not compromised, the certificate is actually made obsolete since you don't use the certificate for any trust decission you don't require on-line from the CA at time of verificatrion. The whole concept of using certificates can thus be replaced with an on-line request for the subject public key, attributes and parameters from the CA at time of validation. It would be interesting to know the wording of the German Law requiring RTCS. It seams that it requires som other technology than X.509 certificates and thus would not be a subject for PKIX. /Stefan At 15:59 2003-02-07 +0100, Olaf.Schlueter@secartis.com wrote: >Introductory note (hello, stephen, please read): I am not asking for >updates, changes to or extensions of existing specs and standards. I just >put those specs to a challenge and want to see how they respond > >And I changed the topic, as we are now far away enough from discussing >RTCS > >The german law does not really mandate a white list check. It mandates >maintaining the ability of end users to sign after a CA key compromise >Thomas has explained the law in detail. The intention of the law is to keep >the user unharmed by CA key compromise. It would be fine to have at least >a solution that satisfies the intention. And large-scale card issuers have >as well an interest in a scheme that does not force them to replace huge >volumes of smartcards in a very short period of time. And unlikely as it >may be one needs a persuading emergency plan for CA key compromise if >several million smartcards in the field are relying on this key security > >The "chain model" that is currently in use in Germany and has the >white-list mechanism in it is satisfying the requirements, but it is not >compliant with PKIX and has some other problems as well (the need for >online-transactions for signature validation is increased, not law-aware >applications produce deviating (wrong in the sense of the law) validity >statements). We are looking for alternate solutions to satisfy the >requirements > >The optimal solution would be the one > >- that will cause PKIX-compliant applications to produce the validity >statements on signatures as required by the law >- without requiring private or proprietary extended validation mechanisms >in the client applications >- and would not require end user certificate and token updates in the field >in case of emergency > >Simon Tardell is suggesting a scheme with redundant user certificates >issued by independently secured CA keys. We will have a closer look at >that > >I think PKIX is interested to provide specifications that solve problems >Here is one. Hopefully it is now clear enough explained. Can it be solved >within the framework of existing PKIX specifications ? > >Denis response indicates there is one solution. A pointer to it would be >fine. If it really requires just changing a few words in the law, well the >law has not been given by God. It would be helpful to know which words > > > > > > Denis > Pinkas > > Olaf.Schlueter@secartis.com > ll.net> Kopie: Stephen Kent > , ietf-pkix@imc.org > Thema: Re: Antwort: Re: > Antwort: Re: Real-time Certificate Status Facility for OCSP - > 06.02.2003 > 09:49 (RTCS) > > > > > > > > > > >See comments at the end > > > > We would love to see > > someone demonstrating to us that the legal obligations already explained > > maybe implemented one way or the other in compliance with PKIX > >As Steve already mentioned, "PKIX is not in the habit of setting standards >to accommodate national level laws that may be ill advised" > >There is indeed a real technical problem in case of a CA key compromise, >but the German Law mandates a solution whereas it should have stated >requirements only, instead of a technical solution. There exists a solution >to the problem, but of course it cannot fit with the current text from >the German Law: a few sentences from the German Law should be changed > >Denis Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1BBnh113818 for ietf-pkix-bks; Tue, 11 Feb 2003 03:49:43 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1BBnfd13814 for ; Tue, 11 Feb 2003 03:49:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28650; Tue, 11 Feb 2003 06:45:58 -0500 (EST) Message-Id: <200302111145.GAA28650@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-ldap-crl-schema-00.txt Date: Tue, 11 Feb 2003 06:45:58 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure LDAP Schema for X.509 CRLs Author(s) : D. Chadwick, M. Sahalayev Filename : draft-ietf-pkix-ldap-crl-schema-00.txt Pages : 0 Date : 2003-2-10 This document describes an LDAP schema for X.509 CRLs. Each CRL is broken down into a set of attribute types. These attributes can then be stored in a CRL entry. An object class is defined for this CRL entry. Each attribute type uses an existing LDAP syntax, so that new matching rules do not need to be defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-ldap-crl-schema-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-ldap-crl-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-10132959.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-ldap-crl-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-ldap-crl-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-10132959.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1B0G6A23740 for ietf-pkix-bks; Mon, 10 Feb 2003 16:16:06 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1B0G4d23736 for ; Mon, 10 Feb 2003 16:16:04 -0800 (PST) Subject: RE: A challenge To: "Simon Tardell" Cc: "'Anders Rundgren'" , "'Denis Pinkas'" , ietf-pkix@imc.org, "'Stephen Kent'" , Olaf.Schlueter@secartis.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Mon, 10 Feb 2003 17:18:09 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/10/2003 07:17:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: in fact ... any trusted source for the key can be used to validate the signature. a major point of the certificate is a business process that binds something else to the meaning of the signature (especially in an offline environment when there aren't recourse to online authoritative reference). in the asuretee scenario ... the same hardware token (key) can be registered (aka the registration authority business process) with multiple different authoritative agencies .... potentially providing different bindings for signatures based on the context that the signature is used in. in the encryption scenario (as opposed to the digital signature case), the sender already needs to have a table of public keys (which may or may not be in certificate form .... or stored already in un-encoded form for convinient usage) ... and must select the recipient's public key from the table. a similar process is also possible in the digital signature case for something like a x9.59 financial transaction .... the financial instituion can have pre-decoded the certificate and stored it in the account record at the time the consumer registers the account. It is then no longer necessary for the client to transmit the certificate as part of a digitally signed x9.59 financial transaction. discussion of previously registered certification .... as well as (digital signature) certificates that have been compressed to zero bytes http://www.garlic.com/~lynn/ansiepay.htm#aadsnwi2 Relying-Party Certification Business Practices -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm "Simon Tardell" on 2/10/2003 8:35 am wrote: Anders, > To have redundant certificates in case the CA goes haywire > seems like a very peculiar solution and will force users to > select the proper certificate. Which is? Not at all. A signature is made with a key, not a certificate. As long as the identity of the certificate is not signed into the message, any certificate that corresponds to the right key can be used to validate the signature. The certificate may be sent with the signed message or obtained from somewhere else. It is largely the headache of the verifier. The certificate that is used to verify the signature may even be issued after the signature is made. (And in fact, this would be a reasonable possible consequence of having CA redundancy -- after some time it could happen that both CAs that certify a certain key-identity-binding are replacement CAs deployed after the first signatures were made with the card) For some reason the common paradigm is to let users chose a certificate associated with a key to imply the key. This practice requires the certificate to be present at the client. Or rather, *a* certificate. The certificate could be e.g. a self-signed cert (issued by the smart card itself at production time just to supply a GUI handle to applications looking for, and to supply a subject name for the end entity to claim, if the application needs one). This would remove the need to ever update the smart card. Or, as Sun would say, the network is the computer. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AKwru18263 for ietf-pkix-bks; Mon, 10 Feb 2003 12:58:53 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AKwqd18258 for ; Mon, 10 Feb 2003 12:58:52 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25424; Mon, 10 Feb 2003 15:55:12 -0500 (EST) Message-Id: <200302102055.PAA25424@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 2003 15:55:11 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2511bis-05.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AKmup17978 for ietf-pkix-bks; Mon, 10 Feb 2003 12:48:56 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AKmtd17974 for ; Mon, 10 Feb 2003 12:48:55 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24887; Mon, 10 Feb 2003 15:45:14 -0500 (EST) Message-Id: <200302102045.PAA24887@ietf.org> To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: The IESG SUBJECT: Last Call: Internet X.509 Public Key Infrastructure Certificate Management Protocols to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 10 Feb 2003 15:45:14 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the Public-Key Infrastructure (X.509) Working Group to consider Internet X.509 Public Key Infrastructure Certificate Management Protocols as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-24. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-07.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AGRYC04415 for ietf-pkix-bks; Mon, 10 Feb 2003 08:27:34 -0800 (PST) Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AGRWd04411 for ; Mon, 10 Feb 2003 08:27:32 -0800 (PST) Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54] (may be forged)) by peacock.verisign.com (8.12.1/) with ESMTP id h1AGQuCq025326; Mon, 10 Feb 2003 08:26:56 -0800 (PST) Received: by mou1wnexc02.verisign.com with Internet Mail Service (5.5.2653.19) id <133CKR30>; Mon, 10 Feb 2003 08:27:34 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: =?iso-8859-1?Q?=27Michael_Str=F6der=27?= , ietf-pkix@imc.org Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Mon, 10 Feb 2003 08:27:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_0036_01C2D0F7.676C8560"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C2D0F7.676C8560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Anders Rundgren wrote: > > But the _real_ problem with the X.500 model is that it builds > > on the assumption that organizations want to publish information > > for others to search. > > Again: This is not a specific problem with the X.500 model. > It's a general > problem with certificate retrieval across organizational boundaries. I don't see this as an objection to the X.500/LDAP architecture. However it is a severe restriction on deployment. Since the argument for reuse of LDAP is that it is deployed and the excuse for reuse of X.500 is that it is going to be deployed the fact that enterprises will not allow public access to anything that looks like a directory is very relevant. Not making your directory world readable is probably more important as an enterprise security measure than firewall deployment. > > Using a 'web service' (whatever we might agree in the future > if ever on what > that really is) will just migrate the very same problems to > another service. First off, there is considerable agreement on the definition of Web services. They are machine/machine protocols that are encapsulated in SOAP messaging. Note that there is no requirement to run over HTTP. I think that in the long run we will move to DIME or something similar. > That's what folks should understand *before* trying to solve > problems by > defining yet another standard with yet another buzz-word. Take a look at the XKMS specs. The problem is really well understood at this point. > And I also agree with David that web services just > circumvents firewalls by simple HTTP tunneling. That is a misconception, although several folk like Bruce the sage of Minnessota have been plugging away at it. First off Web Services need not be layered on HTTP. In fact DIME is a much cleaner interface. But HTTP has some near term advantages. Secondly a large part of the Web Services architecture is all about how to route messages through firewalls, the visibility that messages must have, etc. etc. There is an assumption that the firewall does somewhat more than simply block certain ports. > PKI acceptance is yet another issue independent of X.500 directories. No, the X.500 linkage is the single biggest barrier. It has led to more failed PKI deployments in my experience than any other. The customers have wanted to deploy a PKI, they are captured by a directory vendor. They spend three years arguing over theri DIT instead and erroneously conclude that PKI is hard to deply. For PKI deployment to succeed you have to take X.500 and LDAP deployment out of the critical path. > If someone's to blame for lack of PKI acceptance it's this WG for not > reaching consensus on very basic issues No, that is not a factor in PKI deployment. This list is no longer a factor in the development of the PKI world. The basic certificate standards are already deployed in Windows 2000, Java and the rest. The job of this group is to document the reality that has been created. This group cannot influence changes in the PKI infrastructure, that has already happened. This by the way is the IETF way. HTTP was only standardized some six years after the protocol was ubiquitous. > (feel free to check the mailing list > archive *excluding* the dumb X.500 bashing of last three months) and Was there a previous X.500 bashing thread? I don't think so. We have only been on this thread since the new year. > And no, the problems will not automagically be solved by XML, > XKMS, favourite buzz-words here...>. The XML syntax is neither here nor there. I used it simply because if I ask an engineer to learn ASN.1 they start preparing their resume, engineers ask me if they can learn XML. Whether or not XML is actually superior it has won by any empirical standard. Choosing to use ASN.1 at this point is like choosing to use EBSDIC instead of ASCII. I hope that we put rather more into the design of XKMS than simply rehashing PKIX in XML. In fact that was the one thing that the original charter did not allow us to do. Phill ------=_NextPart_000_0036_01C2D0F7.676C8560 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIxMDE2 MjczM1owIwYJKoZIhvcNAQkEMRYEFHWKtB07tZqatJZNH+UpyoJ1jjkbMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAh2E5sTdGZwFr2oHChhMkPfUwaSSE7XCIXn/7fVY3zuDGeYZY KipPhZFXixfKUilboLZA47TheT7TPXWGxkmaFeMqLaJbmh3W4MgNM+uN/YAcIqjnjt5tWobeZEva g2aJ4b125FB9miuQTTzwdtEaJzAXs9YqkLW7tZLevCbCvR0AAAAAAAA= ------=_NextPart_000_0036_01C2D0F7.676C8560-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AFZQM02043 for ietf-pkix-bks; Mon, 10 Feb 2003 07:35:26 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AFZMd02037 for ; Mon, 10 Feb 2003 07:35:24 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id C25EC10F6DF; Mon, 10 Feb 2003 16:35:14 +0100 (CET) From: "Simon Tardell" To: "'Anders Rundgren'" , "'Denis Pinkas'" , Cc: , "'Stephen Kent'" Subject: RE: A challenge Date: Mon, 10 Feb 2003 16:35:04 +0100 Message-ID: <032f01c2d119$fbf12e30$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <00b901c2cec5$82aa6740$0500a8c0@arport> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders, > To have redundant certificates in case the CA goes haywire > seems like a very peculiar solution and will force users to > select the proper certificate. Which is? Not at all. A signature is made with a key, not a certificate. As long as the identity of the certificate is not signed into the message, any certificate that corresponds to the right key can be used to validate the signature. The certificate may be sent with the signed message or obtained from somewhere else. It is largely the headache of the verifier. The certificate that is used to verify the signature may even be issued after the signature is made. (And in fact, this would be a reasonable possible consequence of having CA redundancy -- after some time it could happen that both CAs that certify a certain key-identity-binding are replacement CAs deployed after the first signatures were made with the card) For some reason the common paradigm is to let users chose a certificate associated with a key to imply the key. This practice requires the certificate to be present at the client. Or rather, *a* certificate. The certificate could be e.g. a self-signed cert (issued by the smart card itself at production time just to supply a GUI handle to applications looking for, and to supply a subject name for the end entity to claim, if the application needs one). This would remove the need to ever update the smart card. Or, as Sun would say, the network is the computer. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1AAVOi16770 for ietf-pkix-bks; Mon, 10 Feb 2003 02:31:24 -0800 (PST) Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1AAVMd16755 for ; Mon, 10 Feb 2003 02:31:22 -0800 (PST) Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id h1AAeZD07100; Mon, 10 Feb 2003 11:40:35 +0100 (MET) Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAAAiaW2n; Mon, 10 Feb 03 11:40:01 +0100 Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h1AAUVw04044; Mon, 10 Feb 2003 11:30:32 +0100 (MET) Message-ID: <3E477F47.A5BF7909@trustcenter.de> Date: Mon, 10 Feb 2003 11:30:31 +0100 From: Juergen Brauckmann Organization: TC TrustCenter AG X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson CC: ietf-pkix@imc.org Subject: Re: A challenge References: <5.2.0.9.0.20030208225238.00bd3db0@pop.spray.se> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by venus.trustcenter.de id h1AAUVw04044 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h1AAVNd16764 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan Santesson wrote: > It would be interesting to know the wording of the German Law requiring > RTCS. It seams that it requires som other technology than X.509 > certificates and thus would not be a subject for PKIX. > > /Stefan I found an english translation here: http://www.kuner.com/data/sig/sig_august_16.html Interesting paragraph: §19(6) Here you can find an unofficial translation of the accompanying ordinance, which is also important: http://www.sng.it/acrobat/it%20security/Leggi/Signaturverordnung%20neu%20(English%20unofficial%20version).pdf §15(3) says: "The information according to sentence 1 must include whether the checked qualified certificates were present at the given time in the directory of qualified certificates, and not locked." (locked => revoked) Regards, Juergen Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A3tUJ05213 for ietf-pkix-bks; Sun, 9 Feb 2003 19:55:30 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A3tTd05209 for ; Sun, 9 Feb 2003 19:55:29 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1A3tRMI025454; Mon, 10 Feb 2003 16:55:27 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1A3tTK11181; Mon, 10 Feb 2003 16:55:29 +1300 Date: Mon, 10 Feb 2003 16:55:29 +1300 Message-Id: <200302100355.h1A3tTK11181@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jkazin@parsippany.sns.slb.com, steve.hanna@sun.com Subject: Re: Path validation decision based on notAfter Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve Hanna writes: >Also, I don't think Entrust or Microsoft can avoid issuing such a >"problematic" certificate. The CA that issues the end-entity certificate >(let's call it Andrew) may not know about all CA certificates that have >Andrew as the subject. Even if the CA somehow knew of all such CA >certificates at the time it issued the end-entity certificate, it couldn't >prevent another CA from later issuing a short-lived CA certificate with >Andrew as the subject. When I looked at this, it seemed like a coin-flip decision: There was no clear opinion on the list as to which was better. I asked a few users, and they couldn't identify any strong reason to do it one way or the other either. In the end I decided to do validity-period nesting because (again based on user feedback) it would cause less confusion and make cert management easier if the EE validity was constrained to that of the CA cert that issued it - you don't get users confused over why their cert has expired even though the validity period shows it hasn't, and you know that all the EE certs will automatically roll over once the CA cert rolls over. Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A36Xg04272 for ietf-pkix-bks; Sun, 9 Feb 2003 19:06:33 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A36Ud04268 for ; Sun, 9 Feb 2003 19:06:31 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1A36TMI024591; Mon, 10 Feb 2003 16:06:29 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1A36P917144; Mon, 10 Feb 2003 16:06:25 +1300 Date: Mon, 10 Feb 2003 16:06:25 +1300 Message-Id: <200302100306.h1A36P917144@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, michael@stroeder.com Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: =?ISO-8859-1?Q?Michael_Str=F6der?= writes: >Using a 'web service' (whatever we might agree in the future if ever on what >that really is) will just migrate the very same problems to another service. >That's what folks should understand *before* trying to solve problems by >defining yet another standard with yet another buzz-word. Good point. >And I also agree with David that web services just circumvents firewalls by >simple HTTP tunneling. That's not a solution, it's a real security risk >making content filtering and very complex proxying necessary in the long run. It depends what your definition of "web services" is. You're referring to something like SOAP (let's call it "active HTTP" here). Things like the HTTP certstore interface are just a straight HTTP GET ("passive/pure HTTP"), which fits the classic HTTP model, so you need to distinguish between these two types. As a security (rather than just PKI) person, I agree that active HTTP is going to be a severe problem, and I'd never allow it onto any of my networks or systems. >If someone's to blame for lack of PKI acceptance it's this WG for not >reaching consensus on very basic issues [...] and inventing new competing, >even more complex standards all the time. Let me offer another view. To paraphrase Steve Kent, "Let 10,000 RFCs bloom". We have > 1,400 pages of PKIX RFCs and drafts already, the majority of which are completely ignored outside the community that pushed for their adoption, so eventually by a process of natural selection we'll see what survives. Experience has shown that implementors will implement what they want to implement and disregard the rest, and the results are remarkably consistent - most implementations end up ignoring the same RFCs, and sections of RFCs, without any overt advance agreement to do so, and regardless of whether it's standards-track or nothing-track, MUST or MAY. Here's how this would work: Make all PKIX RFCs (no exception) "Experimental". After 18 months, try and find 3 independant implementations from competing vendors in different countries (to reduce false positives from things like 3 German vendors creating Sig*-compliant software). If less than 3 implementations are found, leave it as "Experimental" (raining fire and brimstone on the RFC authors is left as an optional extra). If >= 3 implementations that fit the bill are found, mark it "Informational". If >= 5 implementations are found, with at least one being open-source (to reduce false positives where "implementations" consist of press releases from members of a vendor consortium), mark it "Standards-track". That's at the macroscopic level. At the microscopic level, do the same thing with MAY, etc. This will cause no change in the implementation status quo, but ensures that the published RFCs at least contain some vague approximation to reality. Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1A33Rn04243 for ietf-pkix-bks; Sun, 9 Feb 2003 19:03:27 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1A33Qd04238 for ; Sun, 9 Feb 2003 19:03:26 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h1A33KMI024473; Mon, 10 Feb 2003 16:03:20 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h1A33KF15484; Mon, 10 Feb 2003 16:03:20 +1300 Date: Mon, 10 Feb 2003 16:03:20 +1300 Message-Id: <200302100303.h1A33KF15484@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Olaf.Schlueter@secartis.com, pgut001@cs.auckland.ac.nz Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: ietf-pkix@imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: [Apologies for the late reply, I've got a large pile of conference papers to work through] Olaf.Schlueter@secartis.com writes: >The main difference between RTCS and standard OCSP is that RTCS is answering >a different question and thus is providing different information. It is a >white list check and a black list check. It answers the question "Is this >certificate issued correctly AND not revoked ?" I want to emphasise yet again that it does this purely because that's all that an authenticated dictionary is capable of. This is not a Conspiracy to Undermine PKIX or a Communist Plot to Annoy Denis, it works that way because that's all the technology allows - if you're running queries straight from a live CA store (or more likely a snapshot thereof), all you can say is "present" or "not present". The converse holds from a CRL-based source. >The debate will probably continue on the topic "Do we really need a white >list check?". In the common PKIX (and X.509) paradigm "CA key security is >perfect" the answer probably is "no". A certificate carrying a signature of >a trusted CA is valid, no need to ask the CA again. I wasn't really that concerned with CA key compromise (if that happens in an X.509 PKI, you're pretty much screwed no matter what), but more with things like manufactured-cert and -CRL attacks. This is fairly simple with most widely-used PKI software: - Implicit universal cross-certification in MSIE/Netscape/CryptoAPI/etc means any CA can issue certs claiming to be from any other CA. Since the other CA never issued them (it doesn't even know that they exist), they can't be invalidated via a CRL. - In practice it's even easier than that. From the NANOG list: It's even worse, a fake certificate from a man in the middle causes a trustworthy warning! If a certificate is not co-signed by any of the Browser compiled-in authorities, the Browsers will just ask: "...do you want to trust ". The hacker is completely free to fill in when he creates his own certificate on the server side (using plain openssl). This will be the only popup as the fake certificate will match the faked URL. Did M$ expect people to say "no" to the fake question "Do you want to trust Citibank" when they are in fact trying to connect to the real Citibank site? The default behavior of a browser should be to reject unsigned certificates and not even ask the question. Currently, there is even no warning that was learned from an unsigned certificate. - Someone else (who probably doesn't want his name dragged into this) has pointed out that this can be extended, via section 4.2.1.14 of RFC 3280, into a manufactured-CRL attack in which you can revoke any arbitrary cert (including the other CA's root). These are attacks that RTCS will help with, not specifically CA key compromise (or sale to a third party, which is a far more common occurrence). >In Germany the german signature law [...] I ploughed through the exact text for this on the weekend. By coincidence the status values appear to be identical to the RTCS ones. I'd never read that text until a few days ago, so RTCS was no attempt to copy the German law requirements. Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h19LMNe27891 for ietf-pkix-bks; Sun, 9 Feb 2003 13:22:23 -0800 (PST) Received: from mail4.it-norr.com (mail4.it-norr.com [80.244.64.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h19LMLd27887 for ; Sun, 9 Feb 2003 13:22:21 -0800 (PST) Received: from HansPC ([217.211.59.24]) by mail4.it-norr.com (IT-NORR Mail Cluster v2003) with SMTP id FJE37084 for ; Sun, 09 Feb 2003 22:22:13 +0100 From: "Hans Nilsson" To: Subject: RE: A challenge Date: Sun, 9 Feb 2003 22:22:04 +0100 Message-ID: <000c01c2d081$4e260bb0$6400a8c0@HansPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, You are explaining the German chain model witht the example of handling CA key compromise. Although allowing signing after CA key comprise is a case "handled" by the German law, I think a more important, and certainly more likely case, is the case of the CA just loosing their status as licensed/accredited CA from RegTP. In this case RegTP will revoke the CA certificate, but the user certificate should remain valid. In this very likely scenario, the users should be able of continuing using their key/certificate/smart card. And thus the chain model was invented. Incidentally, I guess that all commercial CA hierarchies face the same problem, but most ignore that. Have we ever seen an intermediate CA in the Micrsoft tree or other browser-installed tree having its CA certificate revoked because they no longer fulfill the Root CAs requirements in some way or another? I do not think so, because you would get a lot of angry peopole out there, who signatures suddenly would start become invalid. Once a CA is in there, it stays there :-) But the Germans draw the right conclusion, saying that if you issue a license, you must also have a method of withdrawing it. I have always argued that the Germans correctly identified the problem, but took the wrong solution to the solving it. Instead of revoking the CA certificate and declaring the EE certificates to still be valid, they *should not revoke* the CA certificates. By using the CA certificate not only as a statement of the fact that a certain CA holds a certain key, but also as a "certificate of license" that can be revoked at any time, they have "made their bed" in this ugly fashion. It is really a question of what semantics a CA certificate carries. I think it should only state the binding of identity/key (just like an EE certificate), nothing more. The status of the CA (licensed/accredited/supervised...) should be distributed in some other fashion (which is the subject of a European project within ETSI). Hans Nilsson > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of > Olaf.Schlueter@secartis.com > Sent: Friday, February 07, 2003 3:59 PM > To: Denis Pinkas > Cc: ietf-pkix@imc.org; Stephen Kent > Subject: A challenge > > > > > > > > Introductory note (hello, stephen, please read): I am not > asking for updates, changes to or extensions of existing > specs and standards. I just put those specs to a challenge > and want to see how they respond. > > And I changed the topic, as we are now far away enough from > discussing RTCS. > > The german law does not really mandate a white list check. It > mandates maintaining the ability of end users to sign after a > CA key compromise. Thomas has explained the law in detail. > The intention of the law is to keep the user unharmed by CA > key compromise. It would be fine to have at least a solution > that satisfies the intention. And large-scale card issuers > have as well an interest in a scheme that does not force them > to replace huge volumes of smartcards in a very short period > of time. And unlikely as it may be one needs a persuading > emergency plan for CA key compromise if several million > smartcards in the field are relying on this key security. > > The "chain model" that is currently in use in Germany and has > the white-list mechanism in it is satisfying the > requirements, but it is not compliant with PKIX and has some > other problems as well (the need for online-transactions for > signature validation is increased, not law-aware applications > produce deviating (wrong in the sense of the law) validity > statements). We are looking for alternate solutions to > satisfy the requirements. > > The optimal solution would be the one > > - that will cause PKIX-compliant applications to produce the > validity statements on signatures as required by the law > - without requiring private or proprietary extended > validation mechanisms in the client applications > - and would not require end user certificate and token > updates in the field in case of emergency. > > Simon Tardell is suggesting a scheme with redundant user > certificates issued by independently secured CA keys. We will > have a closer look at that. > > I think PKIX is interested to provide specifications that > solve problems. Here is one. Hopefully it is now clear enough > explained. Can it be solved within the framework of existing > PKIX specifications ? > > Denis response indicates there is one solution. A pointer to > it would be fine. If it really requires just changing a few > words in the law, well the law has not been given by God. It > would be helpful to know which words. > > > > > > > Denis Pinkas > > > Olaf.Schlueter@secartis.com > > ll.net> Kopie: > Stephen Kent , ietf-pkix@imc.org > > Thema: Re: > Antwort: Re: Antwort: Re: Real-time Certificate Status > Facility for OCSP - > 06.02.2003 09:49 (RTCS) > > > > > > > > > > > > > > See comments at the end. > > > > We would love to see > > someone demonstrating to us that the legal obligations already > > explained maybe implemented one way or the other in compliance with > > PKIX. > > As Steve already mentioned, "PKIX is not in the habit of > setting standards to accommodate national level laws that may > be ill advised". > > There is indeed a real technical problem in case of a CA key > compromise, but the German Law mandates a solution whereas it > should have stated requirements only, instead of a technical > solution. There exists a solution to the problem, but of > course it cannot fit with the current text from the German > Law: a few sentences from the German Law should be changed. > > Denis > > > > > > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h18MAAt12705 for ietf-pkix-bks; Sat, 8 Feb 2003 14:10:10 -0800 (PST) Received: from trinity.spray.se (trinity.spray.se [212.78.193.150]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h18MA1d12698 for ; Sat, 8 Feb 2003 14:10:02 -0800 (PST) Received: from Laptop.spray.se (1Cust119.tnt4.stk3.swe.da.uu.net [213.116.231.119]) by trinity.spray.se (Postfix) with ESMTP id 412D182FA18; Sat, 8 Feb 2003 23:09:52 +0100 (MET) Message-Id: <5.2.0.9.0.20030208225238.00bd3db0@pop.spray.se> X-Sender: stefan.retrospekt@spray.se@pop.spray.se X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 08 Feb 2003 23:05:45 +0100 To: Olaf.Schlueter@secartis.com, Denis Pinkas From: Stefan Santesson Subject: Re: A challenge Cc: ietf-pkix@imc.org, Stephen Kent In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, The moment you introduce RTCS you have obsoleted the whole concept of using X.509 certificates. The function of a certificate is to provide proof over time, during which, status service is provided. OCSP can relay the information of a CRL and has therefore a place in this structure as a service that can be provided by someone other than the CA. It seams that RTCS must be provided by the CA. If the CA is compromised, you can't trust the RTCS either (unless complex key structure is used), so no benefits there. If the CA is not compromised, the certificate is actually made obsolete since you don't use the certificate for any trust decission you don't require on-line from the CA at time of verificatrion. The whole concept of using certificates can thus be replaced with an on-line request for the subject public key, attributes and parameters from the CA at time of validation. It would be interesting to know the wording of the German Law requiring RTCS. It seams that it requires som other technology than X.509 certificates and thus would not be a subject for PKIX. /Stefan At 15:59 2003-02-07 +0100, Olaf.Schlueter@secartis.com wrote: >Introductory note (hello, stephen, please read): I am not asking for >updates, changes to or extensions of existing specs and standards. I just >put those specs to a challenge and want to see how they respond > >And I changed the topic, as we are now far away enough from discussing >RTCS > >The german law does not really mandate a white list check. It mandates >maintaining the ability of end users to sign after a CA key compromise >Thomas has explained the law in detail. The intention of the law is to keep >the user unharmed by CA key compromise. It would be fine to have at least >a solution that satisfies the intention. And large-scale card issuers have >as well an interest in a scheme that does not force them to replace huge >volumes of smartcards in a very short period of time. And unlikely as it >may be one needs a persuading emergency plan for CA key compromise if >several million smartcards in the field are relying on this key security > >The "chain model" that is currently in use in Germany and has the >white-list mechanism in it is satisfying the requirements, but it is not >compliant with PKIX and has some other problems as well (the need for >online-transactions for signature validation is increased, not law-aware >applications produce deviating (wrong in the sense of the law) validity >statements). We are looking for alternate solutions to satisfy the >requirements > >The optimal solution would be the one > >- that will cause PKIX-compliant applications to produce the validity >statements on signatures as required by the law >- without requiring private or proprietary extended validation mechanisms >in the client applications >- and would not require end user certificate and token updates in the field >in case of emergency > >Simon Tardell is suggesting a scheme with redundant user certificates >issued by independently secured CA keys. We will have a closer look at >that > >I think PKIX is interested to provide specifications that solve problems >Here is one. Hopefully it is now clear enough explained. Can it be solved >within the framework of existing PKIX specifications ? > >Denis response indicates there is one solution. A pointer to it would be >fine. If it really requires just changing a few words in the law, well the >law has not been given by God. It would be helpful to know which words > > > > > > Denis > Pinkas > > Olaf.Schlueter@secartis.com > ll.net> Kopie: Stephen Kent > , ietf-pkix@imc.org > Thema: Re: Antwort: Re: > Antwort: Re: Real-time Certificate Status Facility for OCSP - > 06.02.2003 > 09:49 (RTCS) > > > > > > > > > > >See comments at the end > > > > We would love to see > > someone demonstrating to us that the legal obligations already explained > > maybe implemented one way or the other in compliance with PKIX > >As Steve already mentioned, "PKIX is not in the habit of setting standards >to accommodate national level laws that may be ill advised" > >There is indeed a real technical problem in case of a CA key compromise, >but the German Law mandates a solution whereas it should have stated >requirements only, instead of a technical solution. There exists a solution >to the problem, but of course it cannot fit with the current text from >the German Law: a few sentences from the German Law should be changed > >Denis Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h184wv808114 for ietf-pkix-bks; Fri, 7 Feb 2003 20:58:57 -0800 (PST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h184wud08110 for ; Fri, 7 Feb 2003 20:58:56 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id XAA28814; Fri, 7 Feb 2003 23:56:42 -0500 (EST) Message-ID: <3E448E09.90108@mit.edu> Date: Fri, 07 Feb 2003 23:56:41 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Myers , Carlisle Adams , Dave Solo , David Kemp CC: IETF PKIX WG List , "Steven M. Bellovin" Subject: AD Review of draft-ietf-pkix-rfc2511bis-05.txt X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5A817ED5C34D4B748462A1C" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5A817ED5C34D4B748462A1C Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have completed my review of this document and will request an IETF Wide Last Call. However as is the case with 2510bis, it needs to have its References section split into Normative and Non-Normative references. This can happen in parallel with the IETF Last Call, but I will expect a new Internet Draft with the references split. Thanks. -Jeff --------------enigD5A817ED5C34D4B748462A1C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+RI4J8CBzV/QUlSsRAkRrAKCk5eOpr9FrkHGFbh2PUIwev8El7gCgt4+J lNS5+6U6s/3tw4mZVf8WI40= =1x5b -----END PGP SIGNATURE----- --------------enigD5A817ED5C34D4B748462A1C-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h184QOd07468 for ietf-pkix-bks; Fri, 7 Feb 2003 20:26:24 -0800 (PST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h184QId07461 for ; Fri, 7 Feb 2003 20:26:18 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id XAA28650; Fri, 7 Feb 2003 23:26:18 -0500 (EST) Message-ID: <3E4486E3.4010500@mit.edu> Date: Fri, 07 Feb 2003 23:26:11 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Carlisle Adams , Stephen Farrell CC: ietf-pkix@imc.org, "Steven M. Bellovin" Subject: AD Review of draft-ietf-pkix-rfc2510bis-07.txt X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig27613703C0B88490DDAC97C5" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig27613703C0B88490DDAC97C5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I am in the process of reviewing draft-ietf-pkix-rfc2510bis-07.txt. This review isn't yet complete, but far enough along to give you two key pieces of feedback. I will also request a formal IETF Wide Last Call, so that it can happen in parallel while you work on edits. 1. You need to split the References section into two sections. One labeled "Normative References" and the other "Informational References." The IESG has been asked by the RFC Editor to require this on all submissions. Normative references are those which describe some portion of feature of the protocol such that a protocol developer must read the normative reference in order to implement the protocol. A normative references is also one which directly influences the protocols in the referencing document such that a change in the document references would have an impact on the protocol being defined. 2. Section 2.2.2 states "and EE equipment MUST support the second scheme listed below." Can you more clearly define this, as in a references to a section number. Note: Below is not a formal comment Today one of the common ways of issuing certificates is via a user's web browser. Both Netscape/Mozilla and Internet Explorer have a mechanism for submitting a form that contains a public key (in some form of self signed object, aka a PKCS10 object) to a server, presumably a CA, which can then download either immediately or at some other time, a user's certificate. Typically a secret value is also transmitted with form post that is used to authenticate the user. Presumably this secret pass phrase has been delivered in a secure fashion. If this transaction occurs via an SSL connection, doesn't this provide sufficient strength to initially authenticate the user. The transaction itself doesn't need to be enciphered via a shared secret key, SSL provides the necessary protection. So my question is: "How does this fit in with this document?" (or did I miss something because I haven't read the whole document in detail yet). Thanks. -Jeff --------------enig27613703C0B88490DDAC97C5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+RIbp8CBzV/QUlSsRArzSAJoD2Apnw3FSg6MW5hg0FEt2yDVnTQCeJM3S ND4923oj2CgEw5pejvOelWw= =7kv+ -----END PGP SIGNATURE----- --------------enig27613703C0B88490DDAC97C5-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17I19O15618 for ietf-pkix-bks; Fri, 7 Feb 2003 10:01:09 -0800 (PST) Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17I18d15614 for ; Fri, 7 Feb 2003 10:01:08 -0800 (PST) Received: from smtp2.pacifier.net (smtp2 [64.255.237.172]) by mx4.pacifier.net (Postfix) with ESMTP id 28B2B6A63E; Fri, 7 Feb 2003 10:01:10 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id D4A3A6A44C; Fri, 7 Feb 2003 10:01:08 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Russ Housley'" , "'Bert Kaliski'" Cc: Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt Date: Fri, 7 Feb 2003 09:59:13 -0800 Message-ID: <003301c2ce82$18efe340$0a0000c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Internet Mail Service (5.5.2653.19) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MS-Embedded-Report: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Gentlemen, 1. Can you make the title of the document another line longer? 2. Please consider adding the following textto section 1.2 p 3. "Note: It is not possible to restict the use of a key either RSASSA-PSS and anything else. The same is true of RSAES-OAEP." 3. In section 1.2 p 2 last sentence. I think it should be "signature and/or key transport". 4. In section 2.1, there is a par of paragraphs about the use of NULL or ABSENT in encoding the hash functions. There appears to be a conflict between the two paragraphs. The first says use ABSENT. The second says use NULL. One or the other should be omitted, I would perfer the second as the first is the "standard" way of doing things. The second would require changes in my encoder/decoder utility functions. 5. Section 3, para 1, last sentence: It appears to me that there should potentially be two different statements on conforming CAs. Some CAs will using RSASSA-PSS as the signing algorithm, while other will just encode a certificate with the RSASSA-PSS public key. Should these be seperated in conformant statements? 6. Section 3.1 maskGenAlgorithm. Please remove the statement "It MUST be an algorithm identifier". This is a tautology. 7. Section 3.2. I would like to see a different OID used for a signature value from that used to encode the public key. This makes it easier to process for encode/decode as there are not two structures with the same OID. 8. RSASSA-PSS-params and signature processing. I am confused about what should be done by a signature verifier/producer in checking the parameters of a signature againist the parameters of a signature. My first assumption was that all of the fields mattered and should be "equivalent". From reading the text I find that this is not the case and the saltLength is encoded in the certificate parameters but is wildcarded against the signature parameters. This type of behavior makes implementation difficult. My first assumption on this implemenation was a binary comparison. This would not work for a number of reasons the first being saltLength, the second being the requirements that I need to be able to match a defaulted parameter against an existing parameter (i.e. sha1Identifier present vs absent). 9. Section 3.1 maskGenAlgorithm. The text at the end of the paragraph is missing some cases that would seem to be logical. The following should be matched: ABSENT {id-mgf1} {id-mgf1, {id-sha1}} {id-mgf1, {id-sha1, NULL}} It would be MUCH simplier if the "stupid" cases could be removed, but I don't know if that would match your worldview. 10. Section 3.1 saltLength. There seems to be a mis-match between the default value in the ASN.1 structure and that in the text. The structure definition says 20. The description says the length of the hash output value. This implies that if I were to use md5 as in the hashAlgorithm field, the default value of the ASN.1 structure for saltLength would suddenly be 16 not 20. 11. Section 4.1, para 1 - missing id- from RSAES-OAEP in the first sentence. 12. Section 4.1, maskGenFunc - see comment 9. 13. Section 4.1, RSAES-OAEP-params comparison function. This comparison has some of the same problems as that of RSASSA-PSS. I don't know the proper way to compare pSourceFunc. I believe that the comparison here is dependent on the value of pSourceFunc.Algorithm. For a value of id-pSpecified, this field should be ignored. Are there other values (such as if nullOctetString is not of 0 length based on para 6 of the security considerations section). 14. Section 5. Please change "the parameters MUST be NULL" to "the parameters MUST be ABSENT". This matches SHA-1 convention. 15. ASN.1 Module: Organization: It helps if the parameters structure is in the same section as the OID that uses the structure. Looking from the top to the very bottom for the parameters is messy. 16. ASN.1 Module: All of the rSASSA-PSS-*-Identifier structures need to be changed to rSASSA-PSS-*-Identifier AlgorithmIdentifier ::= { id-RSASSA-PSS, rSASSA-PSS-*-params } rSASSA-PSS-*-params RSASSA-PSS-params ::= { *-hash, mgf1*Identifier, 20, 1} The second level of initialization cannot be done in 1988 because the structure is an ANY. 17. Section 7.1 [P1v2.1] Remove the first J. and the first comma. Jim Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17GZOb12088 for ietf-pkix-bks; Fri, 7 Feb 2003 08:35:24 -0800 (PST) Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17GZNd12082 for ; Fri, 7 Feb 2003 08:35:23 -0800 (PST) Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h17GYxOQ004968; Fri, 7 Feb 2003 17:34:59 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <00b901c2cec5$82aa6740$0500a8c0@arport> From: "Anders Rundgren" To: "Denis Pinkas" , Cc: , "Stephen Kent" References: Subject: Re: A challenge Date: Fri, 7 Feb 2003 17:25:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, To have redundant certificates in case the CA goes haywire seems like a very peculiar solution and will force users to select the proper certificate. Which is? There is really only one reasonable cure: To manage CA keys and compromises the way most other CAs would. If a CA has a key compromise it may not even be aware of it... BTW, I don't see that CA key protection can be that hard. Proper procedures (TONS of such have been written) and HW crypto should do the trick. Identity impersonation and its consequences is something that you should really bother about. And liabilities in case of such. Regarding cards: make them upgradable over the net. You must anyway be prepared for distributing certificates over net in order to address the "Mobile Internet". Anders ----- Original Message ----- From: To: "Denis Pinkas" Cc: ; "Stephen Kent" Sent: Friday, February 07, 2003 15:59 Subject: A challenge Introductory note (hello, stephen, please read): I am not asking for updates, changes to or extensions of existing specs and standards. I just put those specs to a challenge and want to see how they respond. And I changed the topic, as we are now far away enough from discussing RTCS. The german law does not really mandate a white list check. It mandates maintaining the ability of end users to sign after a CA key compromise. Thomas has explained the law in detail. The intention of the law is to keep the user unharmed by CA key compromise. It would be fine to have at least a solution that satisfies the intention. And large-scale card issuers have as well an interest in a scheme that does not force them to replace huge volumes of smartcards in a very short period of time. And unlikely as it may be one needs a persuading emergency plan for CA key compromise if several million smartcards in the field are relying on this key security. The "chain model" that is currently in use in Germany and has the white-list mechanism in it is satisfying the requirements, but it is not compliant with PKIX and has some other problems as well (the need for online-transactions for signature validation is increased, not law-aware applications produce deviating (wrong in the sense of the law) validity statements). We are looking for alternate solutions to satisfy the requirements. The optimal solution would be the one - that will cause PKIX-compliant applications to produce the validity statements on signatures as required by the law - without requiring private or proprietary extended validation mechanisms in the client applications - and would not require end user certificate and token updates in the field in case of emergency. Simon Tardell is suggesting a scheme with redundant user certificates issued by independently secured CA keys. We will have a closer look at that. I think PKIX is interested to provide specifications that solve problems. Here is one. Hopefully it is now clear enough explained. Can it be solved within the framework of existing PKIX specifications ? Denis response indicates there is one solution. A pointer to it would be fine. If it really requires just changing a few words in the law, well the law has not been given by God. It would be helpful to know which words. Denis Pinkas Kopie: Stephen Kent , ietf-pkix@imc.org Thema: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - 06.02.2003 09:49 (RTCS) See comments at the end. > We would love to see > someone demonstrating to us that the legal obligations already explained > maybe implemented one way or the other in compliance with PKIX. As Steve already mentioned, "PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised". There is indeed a real technical problem in case of a CA key compromise, but the German Law mandates a solution whereas it should have stated requirements only, instead of a technical solution. There exists a solution to the problem, but of course it cannot fit with the current text from the German Law: a few sentences from the German Law should be changed. Denis Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17F5YX04990 for ietf-pkix-bks; Fri, 7 Feb 2003 07:05:34 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17F5Wd04985 for ; Fri, 7 Feb 2003 07:05:32 -0800 (PST) Received: by fw1.gdm.de (8.11.6/8.11.6) id h17F59X11758; Fri, 7 Feb 2003 16:05:09 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Fri Feb 7 16:05:09 2003 Subject: Antwort: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Torsten Hentschel Cc: Denis Pinkas , ietf-pkix@imc.org, Stephen Kent X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Fri, 7 Feb 2003 11:34:37 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 07.02.2003 16:04:48 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The statement of Thomas is a very exact and detailled view on the problem. Thanks, Thomas. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17F5WT04983 for ietf-pkix-bks; Fri, 7 Feb 2003 07:05:32 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17F5Ud04976 for ; Fri, 7 Feb 2003 07:05:31 -0800 (PST) Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id h17F5Bq11782; Fri, 7 Feb 2003 16:05:11 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Fri Feb 7 16:05:10 2003 Subject: A challenge To: Denis Pinkas Cc: ietf-pkix@imc.org, Stephen Kent X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Fri, 7 Feb 2003 15:59:23 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 07.02.2003 16:04:55 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Introductory note (hello, stephen, please read): I am not asking for updates, changes to or extensions of existing specs and standards. I just put those specs to a challenge and want to see how they respond. And I changed the topic, as we are now far away enough from discussing RTCS. The german law does not really mandate a white list check. It mandates maintaining the ability of end users to sign after a CA key compromise. Thomas has explained the law in detail. The intention of the law is to keep the user unharmed by CA key compromise. It would be fine to have at least a solution that satisfies the intention. And large-scale card issuers have as well an interest in a scheme that does not force them to replace huge volumes of smartcards in a very short period of time. And unlikely as it may be one needs a persuading emergency plan for CA key compromise if several million smartcards in the field are relying on this key security. The "chain model" that is currently in use in Germany and has the white-list mechanism in it is satisfying the requirements, but it is not compliant with PKIX and has some other problems as well (the need for online-transactions for signature validation is increased, not law-aware applications produce deviating (wrong in the sense of the law) validity statements). We are looking for alternate solutions to satisfy the requirements. The optimal solution would be the one - that will cause PKIX-compliant applications to produce the validity statements on signatures as required by the law - without requiring private or proprietary extended validation mechanisms in the client applications - and would not require end user certificate and token updates in the field in case of emergency. Simon Tardell is suggesting a scheme with redundant user certificates issued by independently secured CA keys. We will have a closer look at that. I think PKIX is interested to provide specifications that solve problems. Here is one. Hopefully it is now clear enough explained. Can it be solved within the framework of existing PKIX specifications ? Denis response indicates there is one solution. A pointer to it would be fine. If it really requires just changing a few words in the law, well the law has not been given by God. It would be helpful to know which words. Denis Pinkas Kopie: Stephen Kent , ietf-pkix@imc.org Thema: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - 06.02.2003 09:49 (RTCS) See comments at the end. > We would love to see > someone demonstrating to us that the legal obligations already explained > maybe implemented one way or the other in compliance with PKIX. As Steve already mentioned, "PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised". There is indeed a real technical problem in case of a CA key compromise, but the German Law mandates a solution whereas it should have stated requirements only, instead of a technical solution. There exists a solution to the problem, but of course it cannot fit with the current text from the German Law: a few sentences from the German Law should be changed. Denis Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17Ee6c04263 for ietf-pkix-bks; Fri, 7 Feb 2003 06:40:06 -0800 (PST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Ee5d04259 for ; Fri, 7 Feb 2003 06:40:05 -0800 (PST) Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53] (may be forged)) by pigeon.verisign.com (8.12.1/) with ESMTP id h17EcDrT024485; Fri, 7 Feb 2003 06:38:14 -0800 (PST) Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <133B4AZN>; Fri, 7 Feb 2003 06:40:05 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: David Chadwick , "Hallam-Baker, Phillip" Cc: Tony Bartoletti , pgut001@cs.auckland.ac.nz, anders.rundgren@telia.com, lynn.wheeler@firstdata.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: RE: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Fri, 7 Feb 2003 06:39:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001A_01C2CE49.7FBB48F0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C2CE49.7FBB48F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Bit late to come in on this discussion. Ironically the reason why is > because we are currently very busy modifying OpenLDAP to > solve the very > sorts of problem identified by you below, and others (eg Peter G) in > later messages, namely, the ability to search in LDAP directories for > certificates that meet key,value pairs. There is no way you can modify the directory to do certificate path discovery in a bridge CA without doing severe violence to the directory model Furthermore future developments in the directory space are of no relevance to PKI. We have already deployed XKMS. Regardless of whether one believes the future has angle brackets or OIDs the certificate repository of choice will be XKMS or OCSP/SCPV/DPVD [henceforth OCSPVD] Been there, done that, moved on. If Steve Kent is upset that I appear to be reinventing PKIX with angle brackets he can at least have the consolation that as Oscar Wilde observed, to be reinvented with angle brackets is better than not being reinvented with angle brackets. Whatever else UDDI might do it is not going to be a certificate repository. > But actually your mail contains a lot of misguided comments > as well, and > in some cases just plain ignorance of the facts about LDAP > and X.500. It > also contains some quite comical bits e.g. I don't think your experience of the PKI field is sufficient to go arround patronising people. Even if you are an academic. I think that it is you who are plain ignorant of the capabilities that PKI applications require of repositories, the trust structures in use in commercial and government deployments and the role that directories play. To give an example, to discover your (somewhat sparse) publication record with its obsessive concentration on X.500 I did not consult a 'directory', I used a search engine called Google accessed by a somewhat more successful protocol called HTTP that I helped to write. If you had performed the same degree of rudimentary research yorself you would have found the following article in the early hits: http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2879127,00.h tml Phill ------=_NextPart_000_001A_01C2CE49.7FBB48F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIwNzA2 MzczOVowIwYJKoZIhvcNAQkEMRYEFAtPfhxXqtfn9Pe4BI8OVShMvR1NMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAU+yuaWuXnZcojxhBACNs1ZnnVhqcB3RrTVo4KFh1/ESrCUP8 /oLf56RnhPYQsS4WW4Odh+C1Ed2eHy8pOTSj2ZlZ7z7TDZ4AdxWHlVupNU6D/Vcnjr+os4WcqzVd zaa2dcGxLed0dWZCkj9U48Bz5IArWmIEzCfpc3ALNyZLNnQAAAAAAAA= ------=_NextPart_000_001A_01C2CE49.7FBB48F0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17EcTB04225 for ietf-pkix-bks; Fri, 7 Feb 2003 06:38:29 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17EcRd04215 for ; Fri, 7 Feb 2003 06:38:27 -0800 (PST) Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Torsten Hentschel Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, Simon Tardell X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Fri, 7 Feb 2003 07:40:13 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/07/2003 09:40:01 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: not only the key and the certificate independent .... but the certificate is actually just some representation of a process of RA and certification. in that sense ... anologous to other certificates &/or license ... aka say a driver's license .... representing the test you took to drive. if your driver's license goes thru the wash (and/or some other process and is destroyed) ... that doesn't mean that you need to retake the driver's test to get a new license. your ability to drive is independent of the certification process ... and the certification/license issue to represent the test of your ability to drive. typically if some license/certificate is lost/destroyed ... it is just re-issued. in the aads model ... it is even taken further. it isn't even necessary to have a certificate to sign something with a key. it allows for some online facility that can make a real-time representation to the RA and certification process. this is somewhat taken from financial transaction model .... where something is used for authentication .... but there is a real-time access to representation .... especially in a business model where the business process transaction contains the complete real-time representation that is something specific to the business process at hand with higher quality information (aka rather than providing the lower quality information that a certificate might represent about individual having a bank account .... the real-time transaction says that there is actual funds available for the transactions and the movement of money has actually occured). In that case, the key can be sufficient for the bank to know that it is one of their customers .... and the merchant doesn't care particularly any details about you ... they just care whether they get their money. http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/index.html#aads -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm the@authentidate.de on 12/7/2003 3:49 am wrote: Hi Simon, Simon Tardell wrote: .. snip .. Thanks for this aspect. I already catched it from your earlier postings and it made me think the direction you outline here. So you already made me aware of the fact, that key and certificate can be considered independent. I think it really is nice. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h17AnrX20980 for ietf-pkix-bks; Fri, 7 Feb 2003 02:49:53 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h17Anpd20974 for ; Fri, 7 Feb 2003 02:49:51 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id EAA01067; Wed, 12 Feb 2003 04:28:05 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h17Ann911549; Fri, 7 Feb 2003 11:49:49 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E438F4A.4030007@authentidate.de> Date: Fri, 07 Feb 2003 11:49:46 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Simon Tardell CC: ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <2962226.1044606665221.JavaMail.root@email.authentidate.de> In-Reply-To: <2962226.1044606665221.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h17Anqd20975 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Simon, Simon Tardell wrote: > Torsten, > > >>P.S.: As far as I understand it, §19 (5) SigG was written this way >> under the vision to ease the creation of non repudation style >> signatures for end entities by the cost of making life a little >> harder for CAs and validation software providers: When EEs use >> qualified certifiactes, they are asured, they have the control, >> at what time their certificate becomes invalid (either because >> they lost their smart card or because they revoke it). This way >> they can digitally sign contracts without the fear, that their >> signature becomes invalid by an accident they did not cause >> (key compromise of a CA). I suspect, this way the need should >> be eleminated, that with PKIX digitally signed >>contracts need to >> be archived by an entrusted third party, which guarantees to >> bring the non repudiateable proof at any point in the future, >> that the signature has been valid at a special point in time. > > > Sometimes I think people attribute too much to certificates. You sign > with the keys, not with the certificates. The binding between the key > and identity can in principal be established after the signature has > been made. Having the certs before the point of signature *verification* > does indeed the hassle for the verifier, but until then they don't > matter too much. Thanks for this aspect. I already catched it from your earlier postings and it made me think the direction you outline here. So you already made me aware of the fact, that key and certificate can be considered independent. I think it really is nice. When I read your earlier lines, it became aware, that SigG may have gone a step too far when it demands that certificates may not become invalid just by a CA cert revocation. For the intent the writers had in mind (as I suspect it), it would have been sufficient to demand the following things: a) The key may not become useless by a CA cert revocation. (Somebody has to issue and distribute new certs for these keys. A cert on a smart card can be replaced easily.) b) Signatures intended for long term non repudiation must have been completed with validation information (RFC 3116 style; "ES-X long" wraped by "ES-A") shortly after creation. Indeed, b) is demanded by SigG in a relaxed way already. A different point using current practice: When you create RFC 3116 style ES-X containers, then PKIX signatures can become the same weight as the signatures required by SigG. But it is obvious that long term non repudiation signatures become more expensive and complicated to create. The question is, what is more economic. Compatibilty with the rest of the world must be respected in the calculations of the German government for the answer as well. Perhaps there is the root of the problem. Kind regards, Torsten -- Torsten Hentschel [The poisitions described by me above are not neccessarily those of my employer.] Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h178XJw01854 for ietf-pkix-bks; Fri, 7 Feb 2003 00:33:19 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h178XGd01846 for ; Fri, 7 Feb 2003 00:33:17 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id DC08710F8F0; Fri, 7 Feb 2003 09:33:10 +0100 (CET) From: "Simon Tardell" To: "'Torsten Hentschel'" , "'Denis Pinkas'" , Cc: "'Stephen Kent'" , Subject: RE: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Fri, 7 Feb 2003 09:32:48 +0100 Message-ID: <01c101c2ce83$80c4e460$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3E425055.9020804@authentidate.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h178XHd01848 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Torsten, > P.S.: As far as I understand it, §19 (5) SigG was written this way > under the vision to ease the creation of non repudation style > signatures for end entities by the cost of making life a little > harder for CAs and validation software providers: When EEs use > qualified certifiactes, they are asured, they have the control, > at what time their certificate becomes invalid (either because > they lost their smart card or because they revoke it). This way > they can digitally sign contracts without the fear, that their > signature becomes invalid by an accident they did not cause > (key compromise of a CA). I suspect, this way the need should > be eleminated, that with PKIX digitally signed > contracts need to > be archived by an entrusted third party, which guarantees to > bring the non repudiateable proof at any point in the future, > that the signature has been valid at a special point in time. Sometimes I think people attribute too much to certificates. You sign with the keys, not with the certificates. The binding between the key and identity can in principal be established after the signature has been made. Having the certs before the point of signature *verification* does indeed the hassle for the verifier, but until then they don't matter too much. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h176WgJ14031 for ietf-pkix-bks; Thu, 6 Feb 2003 22:32:42 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h176Wed14027 for ; Thu, 6 Feb 2003 22:32:40 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Feb 2003 22:32:42 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Feb 2003 22:32:37 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Feb 2003 22:32:39 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 6 Feb 2003 22:32:41 -0800 Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3760.0); Thu, 6 Feb 2003 22:32:41 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Path validation decision based on notAfter Date: Thu, 6 Feb 2003 22:32:38 -0800 Message-ID: <4AEE3169443CDD4796CA8A00B02191CD063338D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Path validation decision based on notAfter Thread-Index: AcLN+dh5jJGn7V2YTR+UwWb1btbikAAdm7zA From: "Trevor Freeman" To: "Joel S. Kazin" , Cc: X-OriginalArrivalTime: 07 Feb 2003 06:32:41.0897 (UTC) FILETIME=[B7702990:01C2CE72] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h176Wfd14028 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Joel, The motivation why we chose not to issue such a certificate has nothing with path validation. As Steve rightly points out, a CA may have been certified several times resulting in multiple paths for any certificate it issues. Each path can have different validity ranges, but all that counts is each certificate valid at the time you validate the certificate. Our decision to limit the CA to issuing certificate within the lifetime of its own certificate is purely to simplify the certificate lifecycle management issue by ensuring that if a CAs certificate expires, them all certificate issued by that CA have also expired. Trevor -----Original Message----- From: Joel S. Kazin [mailto:jkazin@parsippany.sns.slb.com] Sent: Thursday, February 06, 2003 7:41 AM To: ietf-pkix@imc.org Cc: ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter The RFC may be ambiguous. If the CA certificate expires next week and the end entity certificate expires a year from now and I check the certificate today it will pass. However, if I check it in a month the certificate will fail. If the CA certificate is renewed tomorrow and I check the certificate a month from now it will pass. Note that if the CA re-keys its signing certificate the EE certificate will not pass if it is checked in a month. The reason that I and others would reject such a certificate is that the CA is making a statement about actions it may take in the future, re-certifying an existing key as opposed to a current or past action. Neither Entrust nor Microsoft will issue such a problematic certificate. At 02:20 PM 2/6/2003 +0100, Denis Pinkas wrote: >Luciano, > >>Is it legal for a certificate to have a longer validity period than its CA >>certificate? In other words: Should not a path validation algorithm >>(according to RFC 3280) reject an alleged CA certificate if its notAfter >>value is lower than the one in the certificate (supposedly) issued by it? >>The standard does not say a word about it, > >Extract from RFC 3280: > >6.1.3 Basic Certificate Processing > > The basic path processing actions to be performed for certificate i > (for all i in [1..n]) are listed below. > > (a) Verify the basic certificate information. The certificate > MUST satisfy each of the following: > > (snip) > > (2) The certificate validity period includes the current time. > >Denis > >>but I think it is quite >>reasonable to include this condition in the path validation algorithm. >>Unless I am missing something and there are cases (cross-certification >>maybe?) where it is necessary to allow such certification chains. >>Luciano Medina > > Senior Consultant Technical Consulting Practice, Northeast Region Schlumberger Network Solutions jkazin@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 914-769-8780 Mobile +1 914-645-5598 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16Mr1j04027 for ietf-pkix-bks; Thu, 6 Feb 2003 14:53:01 -0800 (PST) Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Mqxd04023 for ; Thu, 6 Feb 2003 14:52:59 -0800 (PST) Received: from localhost (212.247.5.91) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 6 Feb 2003 23:49:17 +0100 Date: Thu, 06 Feb 2003 23:45:31 +0100 (CET) Message-ID: <20030206.234531.130618309.levitte@lp.se> To: anders.rundgren@telia.com CC: d.w.chadwick@salford.ac.uk, pbaker@verisign.com, azb@llnl.gov, pgut001@cs.auckland.ac.nz, lynn.wheeler@firstdata.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP From: Richard Levitte - VMS Whacker In-Reply-To: <01c301c2ce1a$f2146690$0500a8c0@arport> References: <3E42937C.6752352E@salford.ac.uk> <01c301c2ce1a$f2146690$0500a8c0@arport> X-URL: http://www.lp.se/ X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.1 X-Mew: See http://www.mew.org/ X-Mailer: Mew version 3.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) MIME-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In message <01c301c2ce1a$f2146690$0500a8c0@arport> on Thu, 6 Feb 2003 21:04:22 +0100, "Anders Rundgren" said: anders.rundgren> But the _real_ problem with the X.500 model is that anders.rundgren> it builds on the assumption that organizations want anders.rundgren> to publish information for others to search. If you anders.rundgren> go to most major corporation (in contrast to anders.rundgren> academia) and check their home-pages for personal anders.rundgren> e-mail addresses, you will have to look very hard anders.rundgren> find anything, and _never_ a view allowing outsiders anders.rundgren> to search for employees. For those organizations, it would seem obvious that you'll get whatever certificate you may need when someone from said corporation gets in touch with you, not the other way around. anders.rundgren> How many encrypted messages did you receive lately? As I recall, that shouldn't be a problem in this context. Maybe you meant "signed" rather than "encrypted", and in that case (IIRC), you'll usually get the signators certificate in the same mail. As far as I'm concerned, there's a different type of data that's rather crucial to have more or less publically available: the CA certificates, and I'm sure most organizations wouldn't avoid having those publically available, or? It's pretty late, and I suffer a bit from lack of sleep, so if the above didn't make sense, I'll probably have to reiterate my comment tomorrow... -- Richard Levitte | http://richard.levitte.org/ | Spannv. 38, I Levitte Programming | http://www.lp.se/ | S-168 35 Bromma T: +46-708-26 53 44 | | SWEDEN "Price, performance, quality... choose the two you like" Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16MA7S03017 for ietf-pkix-bks; Thu, 6 Feb 2003 14:10:07 -0800 (PST) Received: from nb2.stroeder.com (cxxix.yapay.inka.de [193.197.185.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16MA3d03013 for ; Thu, 6 Feb 2003 14:10:04 -0800 (PST) Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id B04874E720 for ; Thu, 6 Feb 2003 23:07:39 +0100 (CET) Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id BBF01231AF for ; Thu, 6 Feb 2003 23:07:38 +0100 (CET) Message-ID: <3E42DCAA.1070106@stroeder.com> Date: Thu, 06 Feb 2003 23:07:38 +0100 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP References: <3E42937C.6752352E@salford.ac.uk> <01c301c2ce1a$f2146690$0500a8c0@arport> In-Reply-To: <01c301c2ce1a$f2146690$0500a8c0@arport> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Anders Rundgren wrote: > But the _real_ problem with the X.500 model is that it builds > on the assumption that organizations want to publish information > for others to search. Again: This is not a specific problem with the X.500 model. It's a general problem with certificate retrieval across organizational boundaries. Using a 'web service' (whatever we might agree in the future if ever on what that really is) will just migrate the very same problems to another service. That's what folks should understand *before* trying to solve problems by defining yet another standard with yet another buzz-word. And I also agree with David that web services just circumvents firewalls by simple HTTP tunneling. That's not a solution, it's a real security risk making content filtering and very complex proxying necessary in the long run. Web services' promoters simply keep quite about that and security people are still too busy repairing the rest of the brave new web world, the weird mess we already have. > If you go to most major corporation (in > contrast to academia) and check their home-pages for personal > e-mail addresses, you will have to look very hard find anything > and _never_ a view allowing outsiders to search for employees. Yes, this is the privacy problem. So what? It's completely independent of the X.500 model and LDAP. Is that news to you? This is a really hard issue to solve even *within* large companies no matter which technology you're using. There's no general solution and I doubt there will be one in a forseeable future. > How many encrypted messages did you receive lately? PKI acceptance is yet another issue independent of X.500 directories. If someone's to blame for lack of PKI acceptance it's this WG for not reaching consensus on very basic issues (feel free to check the mailing list archive *excluding* the dumb X.500 bashing of last three months) and inventing new competing, even more complex standards all the time. Implementors simply can't follow reading the relevant RFCs to determine what to implement and what to leave aside. Not to speak of ambigous wording leading to many broken implementations. And no, the problems will not automagically be solved by XML, XKMS, . Ciao, Michael. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16KEoS29387 for ietf-pkix-bks; Thu, 6 Feb 2003 12:14:50 -0800 (PST) Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16KEnd29382 for ; Thu, 6 Feb 2003 12:14:49 -0800 (PST) Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maild.telia.com (8.12.5/8.12.5) with SMTP id h16KE4ml027895; Thu, 6 Feb 2003 21:14:04 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <01c301c2ce1a$f2146690$0500a8c0@arport> From: "Anders Rundgren" To: "David Chadwick" , "Hallam-Baker, Phillip" Cc: "Tony Bartoletti" , , , , References: <3E42937C.6752352E@salford.ac.uk> Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP Date: Thu, 6 Feb 2003 21:04:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: But the _real_ problem with the X.500 model is that it builds on the assumption that organizations want to publish information for others to search. If you go to most major corporation (in contrast to academia) and check their home-pages for personal e-mail addresses, you will have to look very hard find anything, and _never_ a view allowing outsiders to search for employees. Authenticating to directories become ridiculous when organizations have hundreds of thousands of employees are "authorized". How many encrypted messages did you receive lately? Anders Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16HLGQ21464 for ietf-pkix-bks; Thu, 6 Feb 2003 09:21:16 -0800 (PST) Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16HLEd21456; Thu, 6 Feb 2003 09:21:14 -0800 (PST) Received: from [198.202.64.211] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24804; Thu, 6 Feb 2003 12:21:19 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 6 Feb 2003 12:21:01 -0500 To: Olaf.Schlueter@secartis.com From: Stephen Kent Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, pgut001@cs.auckland.ac.nz (Peter Gutmann) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 12:54 PM +0100 2/5/03, Olaf.Schlueter@secartis.com wrote: >Olaf, > >>> >>> >>>In Germany the german signature law is identifying a fourth case: >>> >>>4. the cert is in the repository, but not active yet (cert invalid, maybe >>>valid in the future) >>> >>>This case is required (by law) if a CA issues not only certificates but >>>private keys as well to the end user. Think of a bank producing and >>>delivering a smartcard with keys and certificates on it to you. As long >as >>>you did not confirm the receipt of the card to the CA the CA must protect >>>you by having the certificate "on hold" so during transport no valid >>>signatures can be created. This may be handled by an "onHold" status on a >>>CRL but is currently deployed in Germany using white list technology. > >>This seems an unnecessary complication. The CA could simply wait to >>post the cert to a directory until the user acknowledges receipt. >>I'm not in favor of adding complexity when there are other, simpler >>solutions to a problem. > >To withhold the certificate from the directory is exactly the solution that >is applied by existing service providers currently. But that means that RPs >are forced to check the existance of a given certificate in the directory >to examine validity of a signature, i.e. a white-list check. This is in >compliance with the law (great) but not with PKIX (uups). > >Currently OCSP (the german style) is used to perform that check. And I >agree that RFC OCSP has not been built for that. We (i.e. those people >that discussed which specifications to go for to implement law-compliant >PKIs) adopted OCSP as a solution to this problem while it was in draft. And >we totally missed the basic idea that OCSP should be a responder capable of >working on CRLs alone. We interpreted it as a white-list service from the >very beginning. When the draft was finished and promoted to an RFC we had >to realize that we created something different. Peters RTCS in its current >shape would deliver the needed functionality as well. > >I understand your suggestion as setting up an LDAP-directory that allows >queries for matches for a given certificate. That would be an alternative >and simple way to implement a white-list, but it would still be a >white-list. (Issues like obtaining trust into the response of the directory >and obtaining information on the point in time the certificate was inserted >into the directory have still to be resolved.) And white-list checks are >IMHO not in compliance with PKIX path validation. We would love to see >someone demonstrating to us that the legal obligations already explained >maybe implemented one way or the other in compliance with PKIX. My suggestion is not at all what you suggest. Two issues were cited as the rationale for using a white list for verifying cert validity: - dealing with activation for postal delivery of smart cards - dealing with CA key compromise, again with emphasis on smart cards, where the costs of cert reissuance are very significant I said was that using any white list scheme to validate a cert, e.g., directory presence, is just one approach to solving concerns re CA key compromise or smart card activation. As such it probably does not merit standardization, since other schemes for addressing this concern are invisible from a standards perspective. Steve Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16GsVm20851 for ietf-pkix-bks; Thu, 6 Feb 2003 08:54:31 -0800 (PST) Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16GsTd20846 for ; Thu, 6 Feb 2003 08:54:29 -0800 (PST) Received: from salford.ac.uk ([80.7.98.74]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030206165426.SIFM3191.mta07-svc.ntlworld.com@salford.ac.uk>; Thu, 6 Feb 2003 16:54:26 +0000 Message-ID: <3E42937C.6752352E@salford.ac.uk> Date: Thu, 06 Feb 2003 16:55:24 +0000 From: David Chadwick Organization: University of Salford X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hallam-Baker, Phillip" CC: Tony Bartoletti , pgut001@cs.auckland.ac.nz, anders.rundgren@telia.com, lynn.wheeler@firstdata.com, ambarish@malpani.biz, ietf-pkix@imc.org Subject: Re: X.500, LDAP Considered harmful Was: OCSP/LDAP References: Content-Type: multipart/mixed; boundary="------------6DFB3B83616C3D4B2A4844A8" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------6DFB3B83616C3D4B2A4844A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Phil Bit late to come in on this discussion. Ironically the reason why is because we are currently very busy modifying OpenLDAP to solve the very sorts of problem identified by you below, and others (eg Peter G) in later messages, namely, the ability to search in LDAP directories for certificates that meet key,value pairs. But actually your mail contains a lot of misguided comments as well, and in some cases just plain ignorance of the facts about LDAP and X.500. It also contains some quite comical bits e.g. > the client wants to ask is 'what is the email address of > lynn.wheeler@firstdata.com' what the directory wants to be asked Seems like the client already knows the answer!! So why ask for something you already know? I guess it must have been a typo on your part, but not quite sure what the mistake was. But seriously, the problem LDAP had/still has, is that matching rules for PKI certificates have never been defined/standardised, which means that LDAP users can not search for certificates. Full stop. LDAP has always been able to search for email addresses, indeed this was one of the main reasons why many companies purchased LDAP directories in the first place - to search for email addresses. Had matching rules for certificates been defined by LDAP early on (they were for X.500, but never mapped accross to LDAP) and implemented, then you would have been able to do queries such as "find me the cert with key usage equals NR, and subjectAltName email address is a.b@X.com"; indeed any key,value pair from any cert or CRL field would have been searchable. However, to implement such matching rules in LDAP is complex. I and Steven Legg have authored a couple of PKIX drafts which specified these matching rules (for PKI and PMI). We also started to implement them. Steven completed his in his X.500 based server, but we found it difficult in a pure LDAP server (such as openLDAP), the difference being that X.500 servers understood ASN.1 inherently, whereas LDAP tries to minimise its understanding of ASN.1 as much as possible. And since certs are completely ASN.1 based, they dont naturally fit with LDAP's way of doing things. Consequently we have now adopted the approach of Gietz and KLasen, and are splitting the PKI certs and CRLs up into LDAP attributes, storing the attributes in the conventional LDAP servers, and allowing the users to search on these. And since these attributes use existing LDAP matching rules and syntaxes, the conventional LDAP servers wont need modifying. Our modifications to OpenLDAP will allow the modified OpenLDAP server to sit in front of conventional corporate LDAP servers, parse and split up the PKI certs, store them in the conventional LDAP server as leaf entries, and then users will be able to search their conventional LDAP servers for PKI certs. Meanwhile the CA will talk to the modified OpenLDAP server as now, with no changes needed to it. There will be some limitations in the searching capability, but it should fulfil the vast majority of user requirements. One final footnote. Just to show that I am not an "LDAP is the answer to everything, now what is the question" type of person, I have a paper being published in Comms of the ACM in April this year entitled "Deficiencies in LDAP when used to support Public Key Infrastructures". Watch out for it, and read it. It should help to dispell some of your LDAP ignorance. Answers to specific points you make below David "Hallam-Baker, Phillip" wrote: > > > The hierachical organization of the directory does not help > the email application at all. Not true at a corporate level. The DIT structure is irrelevant to the email application since it typically searches the whole corporate directory. At the internet level, the question becomes, how do I find the right corporate directory to search. SRV records are solving this one. > The other practical problem with directories is that they will > never reach beyond the enterprise firewall. Whereas the web clearly has no problem at all with firewalls, since everything is tunnelled through port 80, thereby blowing the concept of a firewall entirely away. From a security perspective I would say that LDAP is not a problem for firewalls, but the web is. A plus point for LDAP from a security perspective, is that directories actually use a different port to the web, so administrators can control this traffic more easily. And if one uses an LDAP application proxy in the firewall as well, even better, you can have very tight control. (We built one such proxy years ago and presented the results at 1997 NDSS in San Diego) > >abstractions of sensitive > data on external IT services whose principal purpose is providing > indexing and searching functions. Two points here. Firstly you are now acknowledging that LDAP servers DO provide searching facilities, which you seemed to imply they did not do earlier. Secondly, what is sensitive about a PUBLIC key certificate? Perhaps the email address inside it? regards David -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 01484 532930 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Projects: http://sec.isi.salford.ac.uk Seminars: http://www.salford.ac.uk/its024/seminars.htm Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** --------------6DFB3B83616C3D4B2A4844A8 Content-Type: text/x-vcard; charset=us-ascii; name="d.w.chadwick.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for David Chadwick Content-Disposition: attachment; filename="d.w.chadwick.vcf" begin:vcard n:Chadwick;David tel;cell:+44 77 96 44 7184 tel;fax:+44 1484 532930 tel;home:+44 1484 352238 tel;work:+44 161 295 5351 x-mozilla-html:FALSE url:http://www.salford.ac.uk/its024/chadwick.htm org:University of Salford;IS Institute version:2.1 email;internet:d.w.chadwick@salford.ac.uk title:Professor of Information Security adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5 x-mozilla-cpt:;-4856 fn:David Chadwick end:vcard --------------6DFB3B83616C3D4B2A4844A8-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16Gjma20653 for ietf-pkix-bks; Thu, 6 Feb 2003 08:45:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Gjgd20641 for ; Thu, 6 Feb 2003 08:45:42 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16334; Thu, 6 Feb 2003 09:45:43 -0700 (MST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h16GjhM03182; Thu, 6 Feb 2003 11:45:43 -0500 (EST) Message-ID: <3E4290BE.D8127491@sun.com> Date: Thu, 06 Feb 2003 11:43:42 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Joel S. Kazin" CC: ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <5.1.1.1.2.20030206102834.00abf5f0@163.188.150.131> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I see no ambiguity in the RFC. Could you be more explicit in explaining what's ambiguous? Also, I don't think Entrust or Microsoft can avoid issuing such a "problematic" certificate. The CA that issues the end-entity certificate (let's call it Andrew) may not know about all CA certificates that have Andrew as the subject. Even if the CA somehow knew of all such CA certificates at the time it issued the end-entity certificate, it couldn't prevent another CA from later issuing a short-lived CA certificate with Andrew as the subject. So Andrew cannot prevent this situation from happening. And, as I described in my earlier email, the situation is perfectly fine. As long as all certs in the path are valid, there should be no need for each cert to have an earlier notAfter date than the preceding cert. If we add such a requirement, what's next? Will we require the subject names to be in alphabetical order? ;-) Steve "Joel S. Kazin" wrote: > > The RFC may be ambiguous. > > If the CA certificate expires next week and the end entity certificate > expires a year from now and I check the certificate today it will pass. > However, if I check it in a month the certificate will fail. > > If the CA certificate is renewed tomorrow and I check the certificate > a month from now it will pass. > > Note that if the CA re-keys its signing certificate the EE certificate will > not pass if it is checked in a month. > > The reason that I and others would reject such a certificate is that the > CA is making a statement about actions it may take in the future, > re-certifying an existing key as opposed to a current or past action. > > Neither Entrust nor Microsoft will issue such a problematic certificate. > > At 02:20 PM 2/6/2003 +0100, Denis Pinkas wrote: > > >Luciano, > > > >>Is it legal for a certificate to have a longer validity period than its CA > >>certificate? In other words: Should not a path validation algorithm > >>(according to RFC 3280) reject an alleged CA certificate if its notAfter > >>value is lower than the one in the certificate (supposedly) issued by it? > >>The standard does not say a word about it, > > > >Extract from RFC 3280: > > > >6.1.3 Basic Certificate Processing > > > > The basic path processing actions to be performed for certificate i > > (for all i in [1..n]) are listed below. > > > > (a) Verify the basic certificate information. The certificate > > MUST satisfy each of the following: > > > > (snip) > > > > (2) The certificate validity period includes the current time. > > > >Denis > > > >>but I think it is quite > >>reasonable to include this condition in the path validation algorithm. > >>Unless I am missing something and there are cases (cross-certification > >>maybe?) where it is necessary to allow such certification chains. > >>Luciano Medina > > > > > > Senior Consultant > Technical Consulting Practice, Northeast Region > Schlumberger Network Solutions > > jkazin@parsippany.sns.slb.com > www.slb.com/nws > > 35 Waterview Blvd. > Suite 210 > Parsippany, NJ 07054-1200 > USA > > Phone +1 914-769-8780 > Mobile +1 914-645-5598 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16FrMT15434 for ietf-pkix-bks; Thu, 6 Feb 2003 07:53:22 -0800 (PST) Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16FrLd15429 for ; Thu, 6 Feb 2003 07:53:21 -0800 (PST) Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <0H9W00G0198W4Y@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:49:34 +0000 (GMT) Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <0H9W00DJ59AFN0@nammta01.sugar-land.nam.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:49:27 +0000 (GMT) Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) id <0H9W00K018JZUP@namems01.sugar-land.oilfield.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:48:33 +0000 (GMT) Received: from SCHLUMBE-OITRVU.parsippany.sns.slb.com (vpnpool296.houston.sinet.slb.com [163.188.125.40]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov 1 2002)) with ESMTP id <0H9W007QS8XSF4@namems01.sugar-land.oilfield.slb.com> for ietf-pkix@imc.org; Thu, 06 Feb 2003 15:41:55 +0000 (GMT) Content-return: prohibited Date: Thu, 06 Feb 2003 10:41:11 -0500 From: "Joel S. Kazin" Subject: Re: Path validation decision based on notAfter In-reply-to: <3E42612D.9030104@bull.net> X-Sender: jkazin@163.188.150.131 To: ietf-pkix@imc.org Cc: ietf-pkix@imc.org Message-id: <5.1.1.1.2.20030206102834.00abf5f0@163.188.150.131> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The RFC may be ambiguous. If the CA certificate expires next week and the end entity certificate expires a year from now and I check the certificate today it will pass. However, if I check it in a month the certificate will fail. If the CA certificate is renewed tomorrow and I check the certificate a month from now it will pass. Note that if the CA re-keys its signing certificate the EE certificate will not pass if it is checked in a month. The reason that I and others would reject such a certificate is that the CA is making a statement about actions it may take in the future, re-certifying an existing key as opposed to a current or past action. Neither Entrust nor Microsoft will issue such a problematic certificate. At 02:20 PM 2/6/2003 +0100, Denis Pinkas wrote: >Luciano, > >>Is it legal for a certificate to have a longer validity period than its CA >>certificate? In other words: Should not a path validation algorithm >>(according to RFC 3280) reject an alleged CA certificate if its notAfter >>value is lower than the one in the certificate (supposedly) issued by it? >>The standard does not say a word about it, > >Extract from RFC 3280: > >6.1.3 Basic Certificate Processing > > The basic path processing actions to be performed for certificate i > (for all i in [1..n]) are listed below. > > (a) Verify the basic certificate information. The certificate > MUST satisfy each of the following: > > (snip) > > (2) The certificate validity period includes the current time. > >Denis > >>but I think it is quite >>reasonable to include this condition in the path validation algorithm. >>Unless I am missing something and there are cases (cross-certification >>maybe?) where it is necessary to allow such certification chains. >>Luciano Medina > > Senior Consultant Technical Consulting Practice, Northeast Region Schlumberger Network Solutions jkazin@parsippany.sns.slb.com www.slb.com/nws 35 Waterview Blvd. Suite 210 Parsippany, NJ 07054-1200 USA Phone +1 914-769-8780 Mobile +1 914-645-5598 Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16FpuC15361 for ietf-pkix-bks; Thu, 6 Feb 2003 07:51:56 -0800 (PST) Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Fpsd15353 for ; Thu, 6 Feb 2003 07:51:54 -0800 (PST) Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id H9W9FK01.FMB for ; Thu, 6 Feb 2003 16:52:32 +0100 Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15 gibson Mar 14 2002 21:29:48) with ESMTP id H9W9GE01.QEL; Thu, 6 Feb 2003 16:53:02 +0100 Subject: Re: Path validation decision based on notAfter To: Steve Hanna Cc: Denis Pinkas , ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: luciano.medina@safelayer.com Date: Fri, 7 Feb 2003 16:53:48 +0100 X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.9a |January 7, 2002) at 07/02/2003 16:53:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > I'll leave it to Luciano to explain what his question was. Yes, Steve, my question was what you understood. Your answer seems reasonable, and actually all the trouble arised when I started to play around with cross-certificates. Thanks to all who replied. Luciano Medina Steve Hanna com> cc: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter 06/02/2003 16:33 Denis Pinkas wrote: > > This does not address Luciano's question. Luciano is asking > > (I think) whether it's OK to have an end-entity certificate > > Luciano was not raising that question. He was not speaking > specifically of an end-entity certificate. I'll leave it to Luciano to explain what his question was. My answer applies equally well if the second certificate in the path is a CA certificate. It's just easier to describe if one is a CA certificate and the other is an end-entity certificate. > > whose notAfter date is January 1, 2005 if the preceding CA > > certificate has a notAfter date of June 30, 2004 (for example). > > Assume that the current date is February 6, 2003. > > > > The answer is that this is fine. The validation algorithm > > does not prohibit it and that's a good thing. > > Now, to answer your question, this is not fine if you assume that the > current date is November 30, 2004. So it is useless (but not prohibited) to > place such a date in an end-entity certificate. Certainly, that path would not be valid on November 30, 2004. But the path is valid on February 6, 2003 (and for more than a year after that). The CA in question may have several CA certificates issued for it (cross-certificates from various parties). Some of these CA certificates may only be valid for a few more months. But this should not prevent the CA from issuing an end-entity certificate with a validity period that extends far into the future. The cross-certificates may be reissued with a later notAfter date. But even if they aren't, relying parties that don't need the expired cross-certificates will still be able to validate the end-entity certificate for a long time. RPs that have the CA in question as their trust anchor, for instance. Or RPs that use other cross-certificates to reach that CA. So it is not useless for a CA to issue an end-entity cert whose validity period extends beyond the validity period of a CA certificate whose subject is that CA. Thanks, Steve Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16FZer13839 for ietf-pkix-bks; Thu, 6 Feb 2003 07:35:40 -0800 (PST) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16FZdd13833 for ; Thu, 6 Feb 2003 07:35:39 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07293; Thu, 6 Feb 2003 07:35:34 -0800 (PST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h16FZYM23943; Thu, 6 Feb 2003 10:35:34 -0500 (EST) Message-ID: <3E42804D.3216C765@sun.com> Date: Thu, 06 Feb 2003 10:33:33 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <3E42612D.9030104@bull.net> <3E427221.ACEBD514@sun.com> <3E42797A.2030908@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas wrote: > > This does not address Luciano's question. Luciano is asking > > (I think) whether it's OK to have an end-entity certificate > > Luciano was not raising that question. He was not speaking > specifically of an end-entity certificate. I'll leave it to Luciano to explain what his question was. My answer applies equally well if the second certificate in the path is a CA certificate. It's just easier to describe if one is a CA certificate and the other is an end-entity certificate. > > whose notAfter date is January 1, 2005 if the preceding CA > > certificate has a notAfter date of June 30, 2004 (for example). > > Assume that the current date is February 6, 2003. > > > > The answer is that this is fine. The validation algorithm > > does not prohibit it and that's a good thing. > > Now, to answer your question, this is not fine if you assume that the > current date is November 30, 2004. So it is useless (but not prohibited) to > place such a date in an end-entity certificate. Certainly, that path would not be valid on November 30, 2004. But the path is valid on February 6, 2003 (and for more than a year after that). The CA in question may have several CA certificates issued for it (cross-certificates from various parties). Some of these CA certificates may only be valid for a few more months. But this should not prevent the CA from issuing an end-entity certificate with a validity period that extends far into the future. The cross-certificates may be reissued with a later notAfter date. But even if they aren't, relying parties that don't need the expired cross-certificates will still be able to validate the end-entity certificate for a long time. RPs that have the CA in question as their trust anchor, for instance. Or RPs that use other cross-certificates to reach that CA. So it is not useless for a CA to issue an end-entity cert whose validity period extends beyond the validity period of a CA certificate whose subject is that CA. Thanks, Steve Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16F7ke12843 for ietf-pkix-bks; Thu, 6 Feb 2003 07:07:46 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16F7Yd12835 for ; Thu, 6 Feb 2003 07:07:34 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA15284; Thu, 6 Feb 2003 16:09:34 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA08158; Thu, 6 Feb 2003 15:01:03 +0100 Message-ID: <3E42797A.2030908@bull.net> Date: Thu, 06 Feb 2003 16:04:26 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Steve Hanna CC: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <3E42612D.9030104@bull.net> <3E427221.ACEBD514@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, > This does not address Luciano's question. Luciano is asking > (I think) whether it's OK to have an end-entity certificate Luciano was not raising that question. He was not speaking specifically of an end-entity certificate. > whose notAfter date is January 1, 2005 if the preceding CA > certificate has a notAfter date of June 30, 2004 (for example). > Assume that the current date is February 6, 2003. > > The answer is that this is fine. The validation algorithm > does not prohibit it and that's a good thing. Now, to answer your question, this is not fine if you assume that the current date is November 30, 2004. So it is useless (but not prohibited) to place such a date in an end-entity certificate. Denis > It's not > unusual for the CA that issues an end-entity certificate > to have several CA certificates, with varying validity periods. > Cross-certificates with that CA as the subject, for instance. > > As long as all of the certificates in a path have a validity > period that includes the current time, there's no problem. > > Steve Hanna > > Denis Pinkas wrote: > >>Luciano, >> >> >>>Is it legal for a certificate to have a longer validity period than its CA >>>certificate? In other words: Should not a path validation algorithm >>>(according to RFC 3280) reject an alleged CA certificate if its notAfter >>>value is lower than the one in the certificate (supposedly) issued by it? >>>The standard does not say a word about it, >> >>Extract from RFC 3280: >> >>6.1.3 Basic Certificate Processing >> >> The basic path processing actions to be performed for certificate i >> (for all i in [1..n]) are listed below. >> >> (a) Verify the basic certificate information. The certificate >> MUST satisfy each of the following: >> >> (snip) >> >> (2) The certificate validity period includes the current time. >> >>Denis >> >> >>>but I think it is quite >>>reasonable to include this condition in the path validation algorithm. >>>Unless I am missing something and there are cases (cross-certification >>>maybe?) where it is necessary to allow such certification chains. >>> >>>Luciano Medina >> > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16EZ8811933 for ietf-pkix-bks; Thu, 6 Feb 2003 06:35:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16EZ6d11925 for ; Thu, 6 Feb 2003 06:35:06 -0800 (PST) Received: from sydney.East.Sun.COM ([129.148.9.16]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08898; Thu, 6 Feb 2003 07:35:07 -0700 (MST) Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h16EZ6M16730; Thu, 6 Feb 2003 09:35:06 -0500 (EST) Message-ID: <3E427221.ACEBD514@sun.com> Date: Thu, 06 Feb 2003 09:33:05 -0500 From: Steve Hanna X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: luciano.medina@safelayer.com, ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: <3E42612D.9030104@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This does not address Luciano's question. Luciano is asking (I think) whether it's OK to have an end-entity certificate whose notAfter date is January 1, 2005 if the preceding CA certificate has a notAfter date of June 30, 2004 (for example). Assume that the current date is February 6, 2003. The answer is that this is fine. The validation algorithm does not prohibit it and that's a good thing. It's not unusual for the CA that issues an end-entity certificate to have several CA certificates, with varying validity periods. Cross-certificates with that CA as the subject, for instance. As long as all of the certificates in a path have a validity period that includes the current time, there's no problem. Steve Hanna Denis Pinkas wrote: > > Luciano, > > > Is it legal for a certificate to have a longer validity period than its CA > > certificate? In other words: Should not a path validation algorithm > > (according to RFC 3280) reject an alleged CA certificate if its notAfter > > value is lower than the one in the certificate (supposedly) issued by it? > > The standard does not say a word about it, > > Extract from RFC 3280: > > 6.1.3 Basic Certificate Processing > > The basic path processing actions to be performed for certificate i > (for all i in [1..n]) are listed below. > > (a) Verify the basic certificate information. The certificate > MUST satisfy each of the following: > > (snip) > > (2) The certificate validity period includes the current time. > > Denis > > > but I think it is quite > > reasonable to include this condition in the path validation algorithm. > > Unless I am missing something and there are cases (cross-certification > > maybe?) where it is necessary to allow such certification chains. > > > > Luciano Medina Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16EXej11867 for ietf-pkix-bks; Thu, 6 Feb 2003 06:33:40 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16EXdd11863 for ; Thu, 6 Feb 2003 06:33:39 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19072; Thu, 6 Feb 2003 09:30:01 -0500 (EST) Message-Id: <200302061430.JAA19072@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-certstore-http-04.txt Date: Thu, 06 Feb 2003 09:30:01 -0500 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP Author(s) : P. Gutmann Filename : draft-ietf-pkix-certstore-http-04.txt Pages : 0 Date : 2003-2-5 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 Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-certstore-http-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-certstore-http-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-2-5140302.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-certstore-http-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-certstore-http-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-2-5140302.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16ECZZ11261 for ietf-pkix-bks; Thu, 6 Feb 2003 06:12:35 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16ECXd11257 for ; Thu, 6 Feb 2003 06:12:33 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id HAA32283; Tue, 11 Feb 2003 07:50:20 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h16ECX931610; Thu, 6 Feb 2003 15:12:33 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E426D4D.1050707@authentidate.de> Date: Thu, 06 Feb 2003 15:12:29 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Denis Pinkas CC: Olaf.Schlueter@secartis.com, ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <6667697.1044528058081.JavaMail.root@email.authentidate.de> <3E425055.9020804@authentidate.de> <3910009.1044538746500.JavaMail.root@email.authentidate.de> In-Reply-To: <3910009.1044538746500.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Denis, >> Please do not take the following as an offence, I am really asking >> open minded and with the fact in mind, that I may not have read >> the German law thouroughly enough: > > > This is fine. > >> Where do you think the German law does mandate a technical solution? >> (Olaf seems to state this and Denis even shrinks it to a few sentences.) > > > I have already spent (too) much time on this issue. Wouldn't have expected that. 8-/ > This list is to > discuss PKIX issues, not to fix the German Law which is currently based > on a model which is incompatible both with PKIX and X.509. > Let us leave the bandwith of this list for other topics. Here I disagree. Again: it is not the law, it may be an implementation that is not in all points compatible. (Sometimes the implementation used by RegTP (Germany's root CA) is mixed with "requirements enforced by law".) As this is the PKIX list: Why shouldn't it be discussed here, how the current implementations in Germany do use and profile PKIX to be compatible to PKIX to the extent they can and where they are not. "Looking over the border" sometimes helps improving, doesn't it? Regards, Torsten -- Torsten Hentschel [Positions outlined by me above are not neccessarily those of my employer.] Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16DNl505675 for ietf-pkix-bks; Thu, 6 Feb 2003 05:23:47 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16DNid05670 for ; Thu, 6 Feb 2003 05:23:45 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA38192; Thu, 6 Feb 2003 14:25:27 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id NAA07678; Thu, 6 Feb 2003 13:17:21 +0100 Message-ID: <3E42612D.9030104@bull.net> Date: Thu, 06 Feb 2003 14:20:45 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: luciano.medina@safelayer.com CC: ietf-pkix@imc.org Subject: Re: Path validation decision based on notAfter References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Luciano, > Is it legal for a certificate to have a longer validity period than its CA > certificate? In other words: Should not a path validation algorithm > (according to RFC 3280) reject an alleged CA certificate if its notAfter > value is lower than the one in the certificate (supposedly) issued by it? > The standard does not say a word about it, Extract from RFC 3280: 6.1.3 Basic Certificate Processing The basic path processing actions to be performed for certificate i (for all i in [1..n]) are listed below. (a) Verify the basic certificate information. The certificate MUST satisfy each of the following: (snip) (2) The certificate validity period includes the current time. Denis > but I think it is quite > reasonable to include this condition in the path validation algorithm. > Unless I am missing something and there are cases (cross-certification > maybe?) where it is necessary to allow such certification chains. > > Luciano Medina Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16CMFl28210 for ietf-pkix-bks; Thu, 6 Feb 2003 04:22:15 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16CMDd28206 for ; Thu, 6 Feb 2003 04:22:13 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA09496; Thu, 6 Feb 2003 13:24:15 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA07291; Thu, 6 Feb 2003 12:15:43 +0100 Message-ID: <3E4252BB.1090202@bull.net> Date: Thu, 06 Feb 2003 13:19:07 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Torsten Hentschel CC: Olaf.Schlueter@secartis.com, Stephen Kent , ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <6667697.1044528058081.JavaMail.root@email.authentidate.de> <3E425055.9020804@authentidate.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h16CMEd28207 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Torsten, > Hi Denis, Olaf, et al., > >> As Steve already mentioned, "PKIX is not in the habit of setting >> standards >> to accommodate national level laws that may be ill advised". >> >> There is indeed a real technical problem in case of a CA key compromise, >> but the German Law mandates a solution whereas it should have stated >> requirements only, instead of a technical solution. There exists a >> solution >> to the problem, but of course it cannot fit with the current text from >> the German Law: a few sentences from the German Law should be changed. > > Please do not take the following as an offence, I am really asking > open minded and with the fact in mind, that I may not have read > the German law thouroughly enough: This is fine. > Where do you think the German law does mandate a technical solution? > (Olaf seems to state this and Denis even shrinks it to a few sentences.) I have already spent (too) much time on this issue. This list is to discuss PKIX issues, not to fix the German Law which is currently based on a model which is incompatible both with PKIX and X.509. Let us leave the bandwith of this list for other topics. Denis > From my point of view the most important difference between certificate > handling conformant to German Electronic Siganture Act (SigG in short) > and PKIX (even X.509) is the requirement that an EE cert may not be > affected by the revocation of a CA cert. This is not even > formulated literally within the law's text. It is a conclusion from > such a formulation. To make this clear, I would like to cite it > (§ 19, (5) SigG): "Die Gültigkeit der von einem > Zertifizierungsdiensteanbieter ausgestellten > qualifizierten Zertifikate bleibt von der Untersagung des Betriebes > und der Einstellung der Tätigkeit sowie der Rücknahme und dem Widerruf > einer Akkreditierung unberührt." I try my best to translate it > (without adding or dropping anything): "The validity of those > qualified certificates issued by a certificate authority > is not affected by the interdiction of the business of this > certificate authority nor by the closing of it nor by the > revocation of its accreditation." > This sentence resides within the context of §19, which > defines the power of the national root authority (RegTP) over > local certification authorities. This paragraph is intended > to give RegTP the power (among other empowerments mentioned > there) to close a CA if good reasons justify this. > It also describes the consequences from this. > > Is it this, what you are referencing (Denis?, Olaf?). > > From my point of view there is no technical requirement in there. > But yes, some can be concluded from this. For instance, > §19, (5) SigG indirectly means: the CA certs will be revoked > by the RegTP when (for instance) there exists strong evidence > that a CA did not perform their operations trustworthy enough, > but the EE certs will not be revoked. This obviously creates > the need for the ability to validate EE certificates > after CA certificates have been revoked. > > BUT: Neither SigG nor any ordinance related to it (as far > as I know them -- I am no lawyer!) mandate > any technical implementation how to achieve this. > > The currently deployed technical implementation is the validity > model called "chain model", which fulfills the above requirement > by demanding a white list check for certificates as well. > SigG requires the CA to archive a lot of documentation > securely whenever they issue a certificate. These can be used > to reconstruct the white list (and put it on line protected by > another CA key) when a CA key gets revoked. > > BUT: It could have been deployed differently (and perhaps it > will at some point in time). I am convinced that other models > like EE certs signed by two independent CAs could fit as well. > > Kind regards, > > Torsten > > P.S.: As far as I understand it, §19 (5) SigG was written this way > under the vision to ease the creation of non repudation style > signatures for end entities by the cost of making life a little > harder for CAs and validation software providers: When EEs use > qualified certifiactes, they are asured, they have the control, > at what time their certificate becomes invalid (either because > they lost their smart card or because they revoke it). This way > they can digitally sign contracts without the fear, that their > signature becomes invalid by an accident they did not cause > (key compromise of a CA). I suspect, this way the need should > be eleminated, that with PKIX digitally signed contracts need to > be archived by an entrusted third party, which guarantees to > bring the non repudiateable proof at any point in the future, > that the signature has been valid at a special point in time. > Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16C9Bp27584 for ietf-pkix-bks; Thu, 6 Feb 2003 04:09:11 -0800 (PST) Received: from xenox.inexnet.de (tach-auch.inexnet.de [217.113.32.61] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16C98d27580 for ; Thu, 6 Feb 2003 04:09:09 -0800 (PST) Received: from gate.wisnet.de (gate.wisnet.de [213.61.157.73]) by xenox.inexnet.de (8.9.0/8.9.0) with ESMTP id FAA24864; Tue, 11 Feb 2003 05:46:45 +0100 Received: from authentidate.de (goliath.authentidate.de [192.168.42.91]) by gate.wisnet.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h16C8u930317; Thu, 6 Feb 2003 13:08:56 +0100 X-Authentication-Warning: gate.wisnet.de: Host goliath.authentidate.de [192.168.42.91] claimed to be authentidate.de Message-ID: <3E425055.9020804@authentidate.de> Date: Thu, 06 Feb 2003 13:08:53 +0100 From: Torsten Hentschel Organization: AuthentiDate International AG User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: de, en MIME-Version: 1.0 To: Denis Pinkas , Olaf.Schlueter@secartis.com CC: Stephen Kent , ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: <6667697.1044528058081.JavaMail.root@email.authentidate.de> In-Reply-To: <6667697.1044528058081.JavaMail.root@email.authentidate.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h16C99d27581 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Denis, Olaf, et al., > As Steve already mentioned, "PKIX is not in the habit of setting standards > to accommodate national level laws that may be ill advised". > > There is indeed a real technical problem in case of a CA key compromise, > but the German Law mandates a solution whereas it should have stated > requirements only, instead of a technical solution. There exists a solution > to the problem, but of course it cannot fit with the current text from > the German Law: a few sentences from the German Law should be changed. Please do not take the following as an offence, I am really asking open minded and with the fact in mind, that I may not have read the German law thouroughly enough: Where do you think the German law does mandate a technical solution? (Olaf seems to state this and Denis even shrinks it to a few sentences.) From my point of view the most important difference between certificate handling conformant to German Electronic Siganture Act (SigG in short) and PKIX (even X.509) is the requirement that an EE cert may not be affected by the revocation of a CA cert. This is not even formulated literally within the law's text. It is a conclusion from such a formulation. To make this clear, I would like to cite it (§ 19, (5) SigG): "Die Gültigkeit der von einem Zertifizierungsdiensteanbieter ausgestellten qualifizierten Zertifikate bleibt von der Untersagung des Betriebes und der Einstellung der Tätigkeit sowie der Rücknahme und dem Widerruf einer Akkreditierung unberührt." I try my best to translate it (without adding or dropping anything): "The validity of those qualified certificates issued by a certificate authority is not affected by the interdiction of the business of this certificate authority nor by the closing of it nor by the revocation of its accreditation." This sentence resides within the context of §19, which defines the power of the national root authority (RegTP) over local certification authorities. This paragraph is intended to give RegTP the power (among other empowerments mentioned there) to close a CA if good reasons justify this. It also describes the consequences from this. Is it this, what you are referencing (Denis?, Olaf?). From my point of view there is no technical requirement in there. But yes, some can be concluded from this. For instance, §19, (5) SigG indirectly means: the CA certs will be revoked by the RegTP when (for instance) there exists strong evidence that a CA did not perform their operations trustworthy enough, but the EE certs will not be revoked. This obviously creates the need for the ability to validate EE certificates after CA certificates have been revoked. BUT: Neither SigG nor any ordinance related to it (as far as I know them -- I am no lawyer!) mandate any technical implementation how to achieve this. The currently deployed technical implementation is the validity model called "chain model", which fulfills the above requirement by demanding a white list check for certificates as well. SigG requires the CA to archive a lot of documentation securely whenever they issue a certificate. These can be used to reconstruct the white list (and put it on line protected by another CA key) when a CA key gets revoked. BUT: It could have been deployed differently (and perhaps it will at some point in time). I am convinced that other models like EE certs signed by two independent CAs could fit as well. Kind regards, Torsten P.S.: As far as I understand it, §19 (5) SigG was written this way under the vision to ease the creation of non repudation style signatures for end entities by the cost of making life a little harder for CAs and validation software providers: When EEs use qualified certifiactes, they are asured, they have the control, at what time their certificate becomes invalid (either because they lost their smart card or because they revoke it). This way they can digitally sign contracts without the fear, that their signature becomes invalid by an accident they did not cause (key compromise of a CA). I suspect, this way the need should be eleminated, that with PKIX digitally signed contracts need to be archived by an entrusted third party, which guarantees to bring the non repudiateable proof at any point in the future, that the signature has been valid at a special point in time. -- Torsten Hentschel [The positions described above are not neccessarily those of my employer.] Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16Bwba27229 for ietf-pkix-bks; Thu, 6 Feb 2003 03:58:37 -0800 (PST) Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16BwYd27225 for ; Thu, 6 Feb 2003 03:58:35 -0800 (PST) Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id H9VYML03.ALI for ; Thu, 6 Feb 2003 12:59:09 +0100 Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15 gibson Mar 14 2002 21:29:48) with ESMTP id H9VYNH00.Y8T for ; Thu, 6 Feb 2003 12:59:41 +0100 Subject: Path validation decision based on notAfter To: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.0.4 June 8, 2000 Message-ID: From: luciano.medina@safelayer.com Date: Fri, 7 Feb 2003 13:00:30 +0100 X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.9a |January 7, 2002) at 07/02/2003 13:00:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Is it legal for a certificate to have a longer validity period than its CA certificate? In other words: Should not a path validation algorithm (according to RFC 3280) reject an alleged CA certificate if its notAfter value is lower than the one in the certificate (supposedly) issued by it? The standard does not say a word about it, but I think it is quite reasonable to include this condition in the path validation algorithm. Unless I am missing something and there are cases (cross-certification maybe?) where it is necessary to allow such certification chains. Luciano Medina Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16BbvN26541 for ietf-pkix-bks; Thu, 6 Feb 2003 03:37:57 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16Bbtd26531 for ; Thu, 6 Feb 2003 03:37:55 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 0104610F8F0; Thu, 6 Feb 2003 12:37:49 +0100 (CET) From: "Simon Tardell" To: , "'Peter Gutmann'" Cc: Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Thu, 6 Feb 2003 12:37:24 +0100 Message-ID: <00a601c2cdd4$1e51bfb0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > 4. the cert is in the repository, but not active yet (cert > invalid, maybe valid in the future) My interpretation that the problem that you try to cover for here is if the card AND the PIN code envelope both gets lost en route from the issuer to the intended end issuer, the card should not be usable. Well, why not issue the certs after the card has been (in a trusted manner) been delivered to the intended recipient? Again, it obviates the need for a custom design protocol. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h16BUEN26371 for ietf-pkix-bks; Thu, 6 Feb 2003 03:30:14 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h16BUBd26366 for ; Thu, 6 Feb 2003 03:30:12 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 92AE910F8F0; Thu, 6 Feb 2003 12:30:03 +0100 (CET) From: "Simon Tardell" To: "'Hallam-Baker, Phillip'" , "'Stephen Kent'" , Cc: , Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Thu, 6 Feb 2003 12:29:41 +0100 Message-ID: <009e01c2cdd3$0a5d37b0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The CA compromise requirement is somewhat strange. If a CA key is > compromised the end entity certs signed under that key are > compromised. I don't think that OCSP is going to help since > the signing key of the OCSP responder would normally chain to > the same root - unless we are going to deploy a second set of > roots of trust. > > Furthermore which CA key are we talking about here? The root > of trust or the intermediate CA that signs the end entity certificate? The CA that signs the EE certs. > If the root of trust is compromised but not the intermediate > you simply sign yourself a new root of trust. If the > intermediate is compromised the end entity cert is > compromised regardless of what opinion German law might have > or appear to have on the matter. "German OCSP", that is OCSP as modified by the SigI (German industry interoperability specification for systems based on SigG/V) is not just a revocation responder answering on delegation for the CA. It is an independent notary. That is, it vouches for that the certificate existed at a certain point in time. It is also independent from the CA it answers for. It does indeed solve the problem, but at the cost of inventing mechanism and protocols that the rest of the world does not know about. I have my doubts of the actual robustness of the solution as well. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h168qgV09730 for ietf-pkix-bks; Thu, 6 Feb 2003 00:52:42 -0800 (PST) Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h168qed09715 for ; Thu, 6 Feb 2003 00:52:40 -0800 (PST) Received: from clbull.frcl.bull.fr (IDENT:root@clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA22458; Thu, 6 Feb 2003 09:54:39 +0100 Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id IAA05893; Thu, 6 Feb 2003 08:46:13 +0100 Message-ID: <3E4221A1.10705@bull.net> Date: Thu, 06 Feb 2003 09:49:37 +0100 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Olaf.Schlueter@secartis.com CC: Stephen Kent , ietf-pkix@imc.org Subject: Re: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: See comments at the end. > Olaf, >>> >>>In Germany the german signature law is identifying a fourth case: >>> >>>4. the cert is in the repository, but not active yet (cert invalid, maybe >>>valid in the future) >>> >>>This case is required (by law) if a CA issues not only certificates but >>>private keys as well to the end user. Think of a bank producing and >>>delivering a smartcard with keys and certificates on it to you. As long >> > as > >>>you did not confirm the receipt of the card to the CA the CA must protect >>>you by having the certificate "on hold" so during transport no valid >>>signatures can be created. This may be handled by an "onHold" status on a >>>CRL but is currently deployed in Germany using white list technology. >> > >>This seems an unnecessary complication. The CA could simply wait to >>post the cert to a directory until the user acknowledges receipt. >>I'm not in favor of adding complexity when there are other, simpler >>solutions to a problem. > > > To withhold the certificate from the directory is exactly the solution that > is applied by existing service providers currently. But that means that RPs > are forced to check the existance of a given certificate in the directory > to examine validity of a signature, i.e. a white-list check. This is in > compliance with the law (great) but not with PKIX (uups). > > Currently OCSP (the german style) is used to perform that check. And I > agree that RFC OCSP has not been built for that. We (i.e. those people > that discussed which specifications to go for to implement law-compliant > PKIs) adopted OCSP as a solution to this problem while it was in draft. And > we totally missed the basic idea that OCSP should be a responder capable of > working on CRLs alone. We interpreted it as a white-list service from the > very beginning. When the draft was finished and promoted to an RFC we had > to realize that we created something different. Peters RTCS in its current > shape would deliver the needed functionality as well. > > I understand your suggestion as setting up an LDAP-directory that allows > queries for matches for a given certificate. That would be an alternative > and simple way to implement a white-list, but it would still be a > white-list. (Issues like obtaining trust into the response of the directory > and obtaining information on the point in time the certificate was inserted > into the directory have still to be resolved.) And white-list checks are > IMHO not in compliance with PKIX path validation. This is correct. > We would love to see > someone demonstrating to us that the legal obligations already explained > maybe implemented one way or the other in compliance with PKIX. As Steve already mentioned, "PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised". There is indeed a real technical problem in case of a CA key compromise, but the German Law mandates a solution whereas it should have stated requirements only, instead of a technical solution. There exists a solution to the problem, but of course it cannot fit with the current text from the German Law: a few sentences from the German Law should be changed. Denis Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15FcfA14288 for ietf-pkix-bks; Wed, 5 Feb 2003 07:38:41 -0800 (PST) Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15Fcdd14284 for ; Wed, 5 Feb 2003 07:38:40 -0800 (PST) Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Stephen Kent Cc: ietf-pkix@imc.org, Olaf.Schlueter@secartis.com, pgut001@cs.auckland.ac.nz (Peter Gutmann) X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 5 Feb 2003 08:37:46 -0700 X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 02/05/2003 10:40:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: i would claim in order to activate a digital signature, that the user needs to perform the RA function ... sending a signed message ... nominally containing a copy of the public key and some other identification information ... and this needs to be done regardless of whether the private kye originates with the user or is pushed out to the user. in the pre-push case, just because a private key push agency .... also acting as a CA, happens to pre-push a copy of the certificate prior to the RA function is an anomoly of the process. in effect, what binds/activiates the digital signature process is the RA operation .... not the certificate .... the existance of a certificate is an implementation anomoly of the overall business process. my bias has always been that the digital signature binding process is represented by the binding in the RA process .... independent of any existance of a certificate used in scenarios for trusted key distribution for offline environments ... aka the RA binding for the digital signature proccess is independent of the existance of a certificate as one means of representing that the RA business process has occured. in my AADS claims, online metthods of indicating that valid RA process has been satisfied can be superior to generation of certificates as a representation of a valid RA business process. I would claim that the direct equating of certificates to valid digital signatures contributes to the confusion. the RA binding process is what is used for establishing the basis for valid digital signatures. certificates (should be) just one method of representing that such a RA binding business process has occured. The confusion isn't that an agency can generate a private key and a certificate and push both out to the end user .... the confusion is the automatic acceptance that because a certificate exists ... it is equivalent to a valid digital signature binding process; the certificate should be just considered one way of representing a RA-binding process having been performaned. of course, random refs: http://www.garlic.com/~lynn/index.html#aads as noted in other recent threads there is sometimes confusion of asymmetric cryptography with the business processes of information hiding/secrecy and the business process of digital signature authentication. frequently for digital signatures, the business process may require that the private key never be known by anybody (and can only exist in a unique hardware token) .... while at the same time information hiding/secrecy will require private keys be escrowed (access to valuable corporate assets only accessable via a specific private key will mandate escrow for business continuity purposes). the technology is the same in both business processes .... but there are different secrecy requirements with regard to the treatment of the private key. asymmetric crypto vis-a-vis public key business process ... hiding/secrecy and authentication/digital signature: http://www.garlic.com/~lynn/2001g.html#14 Public key newbie question http://www.garlic.com/~lynn/2001j.html#11 PKI (Public Key Infrastructure) http://www.garlic.com/~lynn/2002i.html#67 Does Diffie-Hellman schema belong to Public Key schema family? http://www.garlic.com/~lynn/2002i.html#78 Does Diffie-Hellman schema belong to Public Key schema family? http://www.garlic.com/~lynn/2002l.html#5 What good is RSA when using passwords ? http://www.garlic.com/~lynn/2002l.html#24 Two questions on HMACs and hashing http://www.garlic.com/~lynn/2002o.html#56 Certificate Authority: Industry vs. Government http://www.garlic.com/~lynn/2003.html#19 Message (authentication/integrity); was: Re: CRC-32 collision http://www.garlic.com/~lynn/2003b.html#30 Public key encryption http://www.garlic.com/~lynn/2003b.html#41 Public key encryption http://www.garlic.com/~lynn/2003b.html#64 Storing digital IDs on token for use with Outlook -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm kent@bbn.com on 2/4/2003 7:02 pm wrote: Olaf, > > >In Germany the german signature law is identifying a fourth case: > >4. the cert is in the repository, but not active yet (cert invalid, maybe >valid in the future) > >This case is required (by law) if a CA issues not only certificates but >private keys as well to the end user. Think of a bank producing and >delivering a smartcard with keys and certificates on it to you. As long as >you did not confirm the receipt of the card to the CA the CA must protect >you by having the certificate "on hold" so during transport no valid >signatures can be created. This may be handled by an "onHold" status on a >CRL but is currently deployed in Germany using white list technology. This seems an unnecessary complication. The CA could simply wait to post the cert to a directory until the user acknowledges receipt. I'm not in favor of adding complexity when there are other, simpler solutions to a problem. >The second reason why german electronic signature technology is requiring a >white list check is another obligation by law, namely that it is not >allowed to render correctly issued user certificates invalid due to a CA >key compromise (or any other kind of CA ceases operation). This is again >achieved with white list technology and status information signed by a key >with independent security. RTCS would fit well in here. My response to Simon addresses this issue, i.e., German law seems to have mandated a solution to a problem that is not technically justified, given the alternatives. PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised. Steve Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15DoZT06567 for ietf-pkix-bks; Wed, 5 Feb 2003 05:50:35 -0800 (PST) Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15DoYd06561 for ; Wed, 5 Feb 2003 05:50:34 -0800 (PST) Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id h15DmR3k008686; Wed, 5 Feb 2003 05:48:27 -0800 (PST) Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id ; Wed, 5 Feb 2003 05:50:19 -0800 Message-ID: From: "Hallam-Baker, Phillip" To: "'Stephen Kent'" , Olaf.Schlueter@secartis.com Cc: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Wed, 5 Feb 2003 05:50:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C2CCF3.9A89DA40" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C2CCF3.9A89DA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > My response to Simon addresses this issue, i.e., German law seems to > have mandated a solution to a problem that is not technically > justified, given the alternatives. PKIX is not in the habit of > setting standards to accommodate national level laws that may be ill > advised. It seems somewhat unusual to see a national law mandate a particular technology. Legislators are usually anxious to avoid specifying implementations. The statement 'we must do X' is preceeded by a requirement. So what is it that the law actually says, does it really say you must do X or does it actually specify the requirements? The OnHold requirement appears to me to be an authorization requirement, not an authentication requirement. It is in any case possible to address the requirement in other ways. The CA compromise requirement is somewhat strange. If a CA key is compromised the end entity certs signed under that key are compromised. I don't think that OCSP is going to help since the signing key of the OCSP responder would normally chain to the same root - unless we are going to deploy a second set of roots of trust. Furthermore which CA key are we talking about here? The root of trust or the intermediate CA that signs the end entity certificate? If the root of trust is compromised but not the intermediate you simply sign yourself a new root of trust. If the intermediate is compromised the end entity cert is compromised regardless of what opinion German law might have or appear to have on the matter. Phil ------=_NextPart_000_0000_01C2CCF3.9A89DA40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINbTCCAj0w ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu 9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1 YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1 3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4 MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEGTCCA4KgAwIBAgIQ da9pAn9XoMlLtvoUDq8LyTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDIwMjI3MDAwMDAwWhcNMDMw MjI3MjM1OTU5WjBtMREwDwYDVQQKEwhWRVJJU0lHTjELMAkGA1UECxMCSFExEzARBgNVBAMTClJl Y2lwaWVudHMxNjA0BgNVBAMTLXBiYWtlciAoSGFsbGFtLUJha2VyIFBoaWxsaXAsIFZlcmlTaWdu LCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtcA/okLsFi9brjmDsXQ6+g+R95B1 81Lq1EXkdzhY7XHxQ2QDq0sS2U4j9N1Ic6nHIiMq5dticztWpKdn6CrDx3Ovd5k+PACq/jSQo7NL tlMJi7fsUrP7pM4izKu4JjSak6wRJUA4x85TSC1PLfd1u8oq16iqNJRhpEJ8VJUMRyECAwEAAaOC AXgwggF0MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNybC52ZXJp c2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3JsMAsGA1Ud DwQEAwIFoDAeBgNVHREEFzAVgRNwYmFrZXJAdmVyaXNpZ24uY29tMIGsBgNVHSAEgaQwgaEwgZ4G C2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BT MGIGCCsGAQUFBwICMFYwFRYOVmVyaVNpZ24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5j b3JwLiBieSByZWZlcmVuY2UgbGlhYi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEE BAMCB4AwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBAUAA4GBACCK +gbdTcJB2wmWF5q8hbnP6slvVFehmjSX1Se+4Ff6a3Uiw8aOQLyNwnYUSOtHe12rTwAtWOhEgXHK D4XY3tF7cofo5hM8dk8xsj9vV3z3fYARDr4nR2bZblPJ3MGmAFAYKW4pgX4Y6NU4VhAG2Hiuj18/ H4Cc5g5oqJp5dArUMYIC+DCCAvQCAQEwgcEwgawxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8w HQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChjKTk5MSUwIwYDVQQD ExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQOrwvJMAkGBSsOAwIa BQCgggGMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDIwNTEz NTAxNlowIwYJKoZIhvcNAQkEMRYEFBYTB+9KzqZaISpIKw8eVPsDYOUBMFgGCSqGSIb3DQEJDzFL MEkwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcG BSsOAwIaMAoGCCqGSIb3DQIFMIHSBgkrBgEEAYI3EAQxgcQwgcEwgawxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkwRwYDVQQLE0BVc2Ug aXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyIChj KTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhB1r2kCf1egyUu2+hQO rwvJMA0GCSqGSIb3DQEBAQUABIGAoe7/bUiunJgS/taV6yiLU7Ldpdaat6nusHdg5iPQQ2ae0rfG Sj+31YATA/JSp5fqcJcqlXzV4+l/FLgU6kh4b2WS0VoVzW5ie7nh3Y1lCf/W3c6TpWQtuxLLO3nn ji57CJZxDxbct8zsqkVZzeHYn/FlCLQjFvevNfQsFehJ2SoAAAAAAAA= ------=_NextPart_000_0000_01C2CCF3.9A89DA40-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h15DBk803204 for ietf-pkix-bks; Wed, 5 Feb 2003 05:11:46 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h15DBid03200; Wed, 5 Feb 2003 05:11:44 -0800 (PST) Received: by fw1.gdm.de (8.11.6/8.11.6) id h15DBVS13616; Wed, 5 Feb 2003 14:11:31 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Wed Feb 5 14:11:31 2003 Subject: Antwort: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: Stephen Kent Cc: ietf-pkix@imc.org, owner-ietf-pkix@mail.imc.org, pgut001@cs.auckland.ac.nz (Peter Gutmann) X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Wed, 5 Feb 2003 12:54:41 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 05.02.2003 14:11:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, >> >> >>In Germany the german signature law is identifying a fourth case: >> >>4. the cert is in the repository, but not active yet (cert invalid, maybe >>valid in the future) >> >>This case is required (by law) if a CA issues not only certificates but >>private keys as well to the end user. Think of a bank producing and >>delivering a smartcard with keys and certificates on it to you. As long as >>you did not confirm the receipt of the card to the CA the CA must protect >>you by having the certificate "on hold" so during transport no valid >>signatures can be created. This may be handled by an "onHold" status on a >>CRL but is currently deployed in Germany using white list technology. >This seems an unnecessary complication. The CA could simply wait to >post the cert to a directory until the user acknowledges receipt. >I'm not in favor of adding complexity when there are other, simpler >solutions to a problem. To withhold the certificate from the directory is exactly the solution that is applied by existing service providers currently. But that means that RPs are forced to check the existance of a given certificate in the directory to examine validity of a signature, i.e. a white-list check. This is in compliance with the law (great) but not with PKIX (uups). Currently OCSP (the german style) is used to perform that check. And I agree that RFC OCSP has not been built for that. We (i.e. those people that discussed which specifications to go for to implement law-compliant PKIs) adopted OCSP as a solution to this problem while it was in draft. And we totally missed the basic idea that OCSP should be a responder capable of working on CRLs alone. We interpreted it as a white-list service from the very beginning. When the draft was finished and promoted to an RFC we had to realize that we created something different. Peters RTCS in its current shape would deliver the needed functionality as well. I understand your suggestion as setting up an LDAP-directory that allows queries for matches for a given certificate. That would be an alternative and simple way to implement a white-list, but it would still be a white-list. (Issues like obtaining trust into the response of the directory and obtaining information on the point in time the certificate was inserted into the directory have still to be resolved.) And white-list checks are IMHO not in compliance with PKIX path validation. We would love to see someone demonstrating to us that the legal obligations already explained maybe implemented one way or the other in compliance with PKIX. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h158Tr201415 for ietf-pkix-bks; Wed, 5 Feb 2003 00:29:53 -0800 (PST) Received: from mystic2.trustcenter.de (mystic2.trustcenter.de [193.194.157.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h158Tod01404 for ; Wed, 5 Feb 2003 00:29:51 -0800 (PST) Received: (from uucp@localhost) by mystic2.trustcenter.de (8.11.6+Sun/8.11.6) id h158d6805951; Wed, 5 Feb 2003 09:39:06 +0100 (MET) Received: from venus.trustcenter.de(192.168.202.4) by mystic2.trustcenter.de via csmap (V6.0) id srcAAACYaWNl; Wed, 5 Feb 03 09:39:05 +0100 Received: from trustcenter.de (titan.trustcenter.de [192.168.200.244]) by venus.trustcenter.de (8.11.0/8.11.0) with ESMTP id h158Tdw18900; Wed, 5 Feb 2003 09:29:40 +0100 (MET) Message-ID: <3E40CB73.2FB94FDF@trustcenter.de> Date: Wed, 05 Feb 2003 09:29:39 +0100 From: Juergen Brauckmann Organization: TC TrustCenter AG X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Olaf.Schlueter@secartis.com CC: ietf-pkix@imc.org Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf.Schlueter@secartis.com wrote: > In Germany the german signature law is identifying a fourth case: Just a short note: All these issues with the German Signature Law "only" relate to qualified certificates. > 4. the cert is in the repository, but not active yet (cert invalid, maybe > valid in the future) > > This case is required (by law) if a CA issues not only certificates but > private keys as well to the end user. Think of a bank producing and > delivering a smartcard with keys and certificates on it to you. [...] > This may be handled by an "onHold" status on a > CRL but is currently deployed in Germany using white list technology. Or by simply not publishing it. Otherwise you will get a somewhat oversized CRL if your bank decides to issue 2 million new banking cards, all with "on hold" certificates. Makes validation a little bit slower than normal :-) Juergen Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1524lK04719 for ietf-pkix-bks; Tue, 4 Feb 2003 18:04:47 -0800 (PST) Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1524kd04715 for ; Tue, 4 Feb 2003 18:04:46 -0800 (PST) Received: from [10.5.14.21] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04089; Tue, 4 Feb 2003 21:04:51 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: References: Date: Tue, 4 Feb 2003 21:02:31 -0500 To: Olaf.Schlueter@secartis.com From: Stephen Kent Subject: Re: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: pgut001@cs.auckland.ac.nz (Peter Gutmann), ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Olaf, > > >In Germany the german signature law is identifying a fourth case: > >4. the cert is in the repository, but not active yet (cert invalid, maybe >valid in the future) > >This case is required (by law) if a CA issues not only certificates but >private keys as well to the end user. Think of a bank producing and >delivering a smartcard with keys and certificates on it to you. As long as >you did not confirm the receipt of the card to the CA the CA must protect >you by having the certificate "on hold" so during transport no valid >signatures can be created. This may be handled by an "onHold" status on a >CRL but is currently deployed in Germany using white list technology. This seems an unnecessary complication. The CA could simply wait to post the cert to a directory until the user acknowledges receipt. I'm not in favor of adding complexity when there are other, simpler solutions to a problem. >The second reason why german electronic signature technology is requiring a >white list check is another obligation by law, namely that it is not >allowed to render correctly issued user certificates invalid due to a CA >key compromise (or any other kind of CA ceases operation). This is again >achieved with white list technology and status information signed by a key >with independent security. RTCS would fit well in here. My response to Simon addresses this issue, i.e., German law seems to have mandated a solution to a problem that is not technically justified, given the alternatives. PKIX is not in the habit of setting standards to accommodate national level laws that may be ill advised. Steve Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h1524JD04699 for ietf-pkix-bks; Tue, 4 Feb 2003 18:04:19 -0800 (PST) Received: from gto-mailer1.bbn.com (gto-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h1524Bd04692 for ; Tue, 4 Feb 2003 18:04:17 -0800 (PST) Received: from [10.5.14.21] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id VAA04067; Tue, 4 Feb 2003 21:03:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <052c01c2cc32$cfc76ea0$0a01a8c0@stl> References: <052c01c2cc32$cfc76ea0$0a01a8c0@stl> Date: Tue, 4 Feb 2003 21:01:35 -0500 To: "Simon Tardell" From: Stephen Kent Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Cc: , "'Peter Gutmann'" , Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:50 AM +0100 2/4/03, Simon Tardell wrote: > > The second reason why german electronic signature technology >> is requiring a white list check is another obligation by law, >> namely that it is not allowed to render correctly issued user >> certificates invalid due to a CA key compromise (or any other >> kind of CA ceases operation). This is again achieved with >> white list technology and status information signed by a key >> with independent security. RTCS would fit well in here. > >Ah, yes, the German OCSP-turned-into-a-certificate-notary. Too late to >change, but if you back up a bit isn't the problem that you don't want >the EE *keys* rendered useless by a CA key compromise? That is perfectly >valid concern: The EE keys are not compromised themselves, just the >binding to the identity (through the CA key compromise). Reissuing smart >cards, especially loads of them, is painfull and takes time, not to say >costs a lot of money. > >A simple solution that would not have mandated inventing a new protocol >("German OCSP") that is uninteroperable with just anything else would >have been to mandate that each EE key be certified with at least two >independent CAs. > There are many ways to address the concerns raised by CA key compromise. Relying on a secure directory to confirm the validity of an EE cert (not keys) is one approach, but too often it seems to be based on a very questionable assumption, i.e., that by using two authorities (the CA and the directory operator) and two keys to verify cert status, that this is necessarily more secure that relying on the CA only. Thios overlooks the possibility that the CA uses multi-party controls for its keys, e.g., analogous to the way that SetCo did for the SET root CA. Mandating use of a secure directory is only one possible way of addressing a valid concern, and to codify this approach as THE solution is unjustifiable. Steve Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h149oWU21533 for ietf-pkix-bks; Tue, 4 Feb 2003 01:50:32 -0800 (PST) Received: from nalle.datum.nu (as6-6-8.s.bonet.se [217.215.37.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h149oUd21524 for ; Tue, 4 Feb 2003 01:50:30 -0800 (PST) Received: from stl (as3-3-6.apv.s.bonet.se [217.215.35.57]) by nalle.datum.nu (Postfix) with ESMTP id 1EC6110F715; Tue, 4 Feb 2003 10:50:21 +0100 (CET) From: "Simon Tardell" To: , "'Peter Gutmann'" Cc: Subject: RE: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) Date: Tue, 4 Feb 2003 10:50:12 +0100 Message-ID: <052c01c2cc32$cfc76ea0$0a01a8c0@stl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > The second reason why german electronic signature technology > is requiring a white list check is another obligation by law, > namely that it is not allowed to render correctly issued user > certificates invalid due to a CA key compromise (or any other > kind of CA ceases operation). This is again achieved with > white list technology and status information signed by a key > with independent security. RTCS would fit well in here. Ah, yes, the German OCSP-turned-into-a-certificate-notary. Too late to change, but if you back up a bit isn't the problem that you don't want the EE *keys* rendered useless by a CA key compromise? That is perfectly valid concern: The EE keys are not compromised themselves, just the binding to the identity (through the CA key compromise). Reissuing smart cards, especially loads of them, is painfull and takes time, not to say costs a lot of money. A simple solution that would not have mandated inventing a new protocol ("German OCSP") that is uninteroperable with just anything else would have been to mandate that each EE key be certified with at least two independent CAs. Simon Simon Tardell, cell +46 70 3198319, simon@tardell.se Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13Iihm07913 for ietf-pkix-bks; Mon, 3 Feb 2003 10:44:43 -0800 (PST) Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Iifd07909 for ; Mon, 3 Feb 2003 10:44:42 -0800 (PST) Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id h13IiXH10043; Mon, 3 Feb 2003 19:44:33 +0100 (CET) Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Mon Feb 3 19:44:33 2003 Subject: Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-pkix@imc.org X-Mailer: Lotus Notes Release 5.07a May 14, 2001 Message-ID: From: Olaf.Schlueter@secartis.com Date: Mon, 3 Feb 2003 19:03:39 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 03.02.2003 19:44:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: While reading the introduction of Peters draft I got the feeling that OCSP is flawed as it is only able to assure the presence of a revocation but not the opposite. I looked up the OCSP specification and found that it delivers three different reponses, with "good" indicating that the certificate is definitely not revoked. Which has to be interpreted as "I have enough information to perform the revocation check, and the check returned not revoked." I understand that "unknown" is indicating that information avaliable is insufficient to decide the question. This, of course, can mean anything. I think that "yes", "no", or "don't know" is a perfect choice of answers for an agent answering the question "is this certificate revoked?. OCSP is not flawed (at least not here). I suggest Peter to review the introduction on this topic to avoid misunderstandings. The main difference between RTCS and standard OCSP is that RTCS is answering a different question and thus is providing different information. It is a white list check and a black list check. It answers the question "Is this certificate issued correctly AND not revoked ?" The most specific answer here is "yes" which means that the certificate is known in the cert repository and there is no revocation indication present. In the short form of the response "no" is ambigous. It can mean 1. that the cert is not in the repository (but should be there, indication of a CA key compromise, cert invalid), 2. the cert is in the repository and marked as revoked (cert invalid), or 3. the repository to look at is not available to the responder (cert state unknown, maybe valid, ask someone else). Looking at the available list of responses in the extended RTCS Response, I cannot map the response codes given there directly to the listed cases. The first and third case map to StatusUnknown, the second case to StatusRevoked. I suggest to provide more response codes to have a one-on-one mapping of the different cases to codes. The debate will probably continue on the topic "Do we really need a white list check?". In the common PKIX (and X.509) paradigm "CA key security is perfect" the answer probably is "no". A certificate carrying a signature of a trusted CA is valid, no need to ask the CA again. In Germany the german signature law is identifying a fourth case: 4. the cert is in the repository, but not active yet (cert invalid, maybe valid in the future) This case is required (by law) if a CA issues not only certificates but private keys as well to the end user. Think of a bank producing and delivering a smartcard with keys and certificates on it to you. As long as you did not confirm the receipt of the card to the CA the CA must protect you by having the certificate "on hold" so during transport no valid signatures can be created. This may be handled by an "onHold" status on a CRL but is currently deployed in Germany using white list technology. The second reason why german electronic signature technology is requiring a white list check is another obligation by law, namely that it is not allowed to render correctly issued user certificates invalid due to a CA key compromise (or any other kind of CA ceases operation). This is again achieved with white list technology and status information signed by a key with independent security. RTCS would fit well in here. pgut001@cs.auckla nd.ac.nz (Peter An: Denis.Pinkas@bull.net, pgut001@cs.auckland.ac.nz Gutmann) Kopie: anders.rundgren@telia.com, ietf-pkix@imc.org, kent@bbn.com Gesendet von: Thema: Re: Real-time Certificate Status Facility for OCSP - (RTCS) owner-ietf-pkix@m ail.imc.org 31.01.2003 10:51 [A bit of a flame, sorry folks] Denis Pinkas writes: >"invalid without being revoked" does not mean anything. So you're saying the only way a certificate can ever be regarded as invalid is if it's formally revoked by a CA? >>and can be valid but OCSP can't tell you that because it can only say "not >>revoked", which doesn't mean "valid" - see the endless debate on this over the >>years). > >There is no such an endless debate, except from your side. Anyone who bothers to search the PKIX archives can see how accurate Denis' claims are. (It's amazing you can even make such a claim, when anyone who's been on the PKIX list for more than a few months has seen the OCSP-status debate crop up at least once. You've even taken part in them yourself... a 30-second search of the archives dug up: Subject: Re: German Law and OCSP From: Denis Pinkas Date: Thu, 10 Feb 2000 16:59:24 +0100 as one example (I don't have the '01 archives becuase they're too big, that was the last one from '00)). >[Blah blah blah, lots more bogus whining and moaning] for example: Because the hash of a certificate is not included in the CRL, so using CRLs only would not be possible. and then right after it you quote the very text which refutes your claim: > memcpy( response.certHash, request.certHash, 20 ); and so on and so on. Look, I'm sorry, but you're grasping at any available (or imaginary) straw here in an attempt to criticse RTCS. It's obvious from your messages (and others have commented on this as well) that you've barely read the RTCS draft (if at all), and even then only to pick out bits to complain about. The posting of obviously incorrect claims such as the ones cited above aren't helping your credibility much either. It's simply a waste of time me even responding to stuff like this - the excerpt above shows that not only have you barely read RTCS, you're not reading the replies either, except to pick out bits to criticise. In the meantime I welcome intelligent debate with anyone else (the cert-HTTP draft has been considerably improved by recent user feedback). Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h13Cg7f18946 for ietf-pkix-bks; Mon, 3 Feb 2003 04:42:07 -0800 (PST) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h13Cg6d18942 for ; Mon, 3 Feb 2003 04:42:06 -0800 (PST) Received: from ofb.nist.gov (ofb.ncsl.nist.gov [129.6.54.187]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h13CfDf2026844; Mon, 3 Feb 2003 07:41:13 -0500 (EST) Message-Id: <5.1.0.14.2.20030203073129.00a2cec0@mail.nist.gov> X-Sender: cjbrown@mail.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Feb 2003 07:41:30 -0500 To: ietf-pkix@imc.org From: Christopher Brown Subject: Update: Progress report: RFC 3280/3281 Interop testing Cc: Tim Polk In-Reply-To: <5.1.0.14.2.20030122102513.01df0f40@email.nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h13Cg6d18943 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: An update on remaining features: At 01:38 PM 01/22/2003 -0500, you wrote: >Folks, > >This message is both a progress report on the RFC 3280 and 3281 testing >and a request for your assistance in completing that testing. > >We are working from a matrix initially developed by Jim Schaad. Chris >Brown here at NIST is performing the certificate and CRL feature testing, >with assistance from Nelson Hastings and David Cooper. We are also >working with DigitalNet (formerly Getronics) and DoD to develop tests for >the path validation algorithm. David Cooper is the NIST lead for that project. > >The certificate and CRL feature testing is largely complete. We have >generated two examples for most features from at least two independent >implementations. However, we need to obtain examples for a few remaining >features. > >The list is appended at the end of this message. The list is divided into >nine certificate fields and 10 CRL "fields", with a number of >subcategories. We are looking for folks that have an implementation which >satisfies these requirements, and can generate some examples for >us. Examples don't need to implement all of the subcategories; examples >that satisfy any one of them are acceptable! > >If you can help, please send email to Chris Brown. I cc'ed him on this >message so that you will all have his email address. Chris will need to >obtain at a minimum the certificate or CRL, but a path associated with the >certificate would be even more helpful. Please specify >which implementation was used to generate the example(s). > >When the path validation tests are complete, we will be looking for >volunteers to execute those tests as well. I will update the list on that >part of the testing once we are ready to go. > >Thanks, > >Tim Polk > > > >------------------------------- remaining features for RFC 3280 and 3281 >---------------------- > >CERTIFICATE FIELD #1: Names (subject or issuer acceptable) > Need one example each for names including the following attributes >a) dNqualifier >b) givenName >c) initials >d) pseudonym >e) generationQualifier > > >CERTIFICATE FIELD #3: SubjectPublicKey >a) DSA public key with parameters omitted >b) elliptic key with parameters present >c) elliptic curve key with NULL parameters (need 1 example: have Entrust) >d) Diffie-Hellman > >CERTIFICATE FIELD #4: Signature field >* ECDSA signature (need 1 example: have Entrust) > >CERTIFICATE FIELD #6: SubjectAltName >a) IPv6 addresses (need 1 example) > >CERTFICATE FIELD #7: CRL distribution points >b) CRLissuer field that has other name form (2 examples) > > >CERTIFICATE FIELD #9: subject information access >a) id-ca-repository and > 1. location is URI > 2. location is DAP > 3. location is rfc822 > >CRL FIELD #1: SignatureAlgorithm >* ECDSA with parameters NULL (1 example ­ have Entrust) > >CRL FIELD #2: Issuer Name >a) Distinguished name qualifier, state or province name, common name, >serial number (1 example ­ have OpenSSL) >b) Locality, title, surname(2 examples), given name, initials, >pseudonym, generation qualifier (1 example ­ have OpenSSL) >c) Use BMPString (2 examples) >d) Use UTF8String (2 examples) > >CRL FIELD #3: This Update >* Date >= 2050, encoded as GeneralizedTime (2 examples) > >CRL FIELD #4: Next Update >* Date >= 2050, encoded as GeneralizedTime (2 examples) > >CRL FIELD #5: Issuer Alternative Name >a) IpV4 address (1 example -- have openSSL) >b) IpV6 address, other name (2 examples) > > >CRL #6: CRL Number >a) Delta and CRLs on the same scope must share one numbering sequence >(1 example ­ have iPlanet) >b) Delta and CRL on same scope issued at same time must have same >number (2 examples) > >CRL #7: Delta Indicator >* (need 2 examples) >a) MUST list as removeFromHold in delta if held since base but now >not held >b) MUST list as removeFromCRL if certificate has expired and was revoked >c) MUST include revoked and expired certificate on delta until it >appears on at least one full CRL >* (1 example ­ have iPlanet) >d) All referenced base CRLs must be full CRLs >e) Delta CRLs MUST contain this extension as crititcal >f) Base and Delta MUST omit CDP or have identical CDPs >g) Use same key for Base and Delta CRLs >h) MUST include cert on delta if status changed since base > >CRL #9: Freshest CRL >* All tests (2 examples) >a) Extension must be non-critical >b) Extension must not be present in delta CRLs >c) Omit reasons and CRLIssuer from extension > >CRL #10: CRL Entry Extensions >a) Hold Instruction Code (1 example ­ have OpenSSL) >b) Certificate Issuer (2 examples) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h12L8Bf25312 for ietf-pkix-bks; Sun, 2 Feb 2003 13:08:11 -0800 (PST) Received: from jis.mit.edu (JIS.MIT.EDU [18.7.21.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h12L82o25303 for ; Sun, 2 Feb 2003 13:08:02 -0800 (PST) Received: from mit.edu (localhost [127.0.0.1]) by jis.mit.edu (8.9.2/8.9.3) with ESMTP id QAA02495; Sun, 2 Feb 2003 16:04:18 -0500 (EST) Message-ID: <3E3D87CB.4050209@mit.edu> Date: Sun, 02 Feb 2003 16:04:11 -0500 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" CC: Tim Polk , ietf-pkix@imc.org, Stephen Kent , Carlisle Adams , Stephen Farrell Subject: Re: Request for Consideration of RFC References: <20030131045703.958D87B4D@berkshire.research.att.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA844DA1B0061523182A917CB" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA844DA1B0061523182A917CB Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks. I'll take a look at them shortly (I've been fighting off a cold these last few days and am just now catching up). -Jeff Steven M. Bellovin wrote: > I've updated both in draft-tracker. They're now in state "publication > requested". The next step is for Jeff and/or I to review them. > > --Steve Bellovin, http://www.research.att.com/~smb (me) > http://www.wilyhacker.com (2nd edition of "Firewalls" book) > > --------------enigA844DA1B0061523182A917CB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+PYfL8CBzV/QUlSsRAtTgAKCq7EdpgA3ywyCMi3r28s/DPt5lbQCfaWiZ fr0r4UKar4GsuI0+Vt7kVoE= =e+5l -----END PGP SIGNATURE----- --------------enigA844DA1B0061523182A917CB--