ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent
scj2@gs4.revnet.com Sat, 31 October 1998 22:59 UTC
Received: from mail.proper.com (mail.proper.com [206.86.127.224]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA13619 for <pkix-archive@odin.ietf.org>; Sat, 31 Oct 1998 17:59:24 -0500 (EST)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA23903 for ietf-pkix-bks; Sat, 31 Oct 1998 12:44:38 -0800 (PST)
Received: from revnet4.revnet.com (revnet4.revnet.com [198.51.35.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA23899 for <ietf-pkix@imc.org>; Sat, 31 Oct 1998 12:44:37 -0800 (PST)
From: scj2@gs4.revnet.com
Received: from gs4.revnet.com (gs4.revnet.com [198.51.35.84]) by revnet4.revnet.com (8.8.7/8.8.7) with SMTP id OAA31179; Sat, 31 Oct 1998 14:42:43 -0600
Message-Id: <199810312042.OAA31179@revnet4.revnet.com>
To: scj2@gs4.revnet.com
Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent
Date: Sat, 31 Oct 1998 14:47:10 -0600
Originator: scj2@gs4.revnet.com
X-Mailer: GroupMaster
X-Mailer-Version: 1.5
X-GroupMasterUser: Revnet Express
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Please open the following message in your web browser
http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML
____________________________________________________________
International Shoe Manufacturing Corp Update:
International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage
financing to begin full-scale production at its plants in India. The $4.75 million is being
used to purchase the final equipment needed to begin production at the companys existing
plant in India. With equipment in place, the company projects net profits of over $25
million a year within two years.
The company stated that the financing will be followed up by a $9 million dollar IPO in
India, anticipated for March 1999. The IPO will be handled by underwriters in India, and
will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the
IPO will pay off the $4.75 million dollar financing. The balance will be used for the
acquisition of additional shoe manufacturing.
ISHO is in the business of manufacturing athletic footwear for the worlds leading shoe
companies. It owns a 23,000-square-foot plant located in the protected free trade zone in
Noida, just outside of New Delhi, India, where skilled labor is plentiful and very
inexpensive. The Indian government recently developed new economic policy to attract
foreign investment that is export-oriented, and could employ large numbers of people.
ISM is the only athletic shoe manufacturer in India directed toward the international
market. It currently has contracts with Adidas and The Pentland Group. These two
companies have agreed to purchase all the shoes ISM can manufacture.
The athletic shoe industry is estimated at $14.25 billion a year. The worlds leading shoe
companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design
and marketing organizations that spend hundreds of millions of dollars a year getting their
products sold. They then rely on others to manufacture to their specifications. Almost, if
not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of
millions of dollars spent on advertising by the name-brand companies. The result is an
open purchase order where such manufacturers literally can sell every pair of shoes they
can produce. A business like this lends itself to being privately held due to the large cash
flow allowing for internal financing. International Shoe Manufacturing Corp. is the only
company known to exist that offers a public investor the opportunity to own a share of this
highly lucrative business in a pure investment play.
For inquiries please contact the office of the director of investor relations toll free at:
877-ISM-CORP (877-476-2677) or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately. Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752
Please visit ISMs web site at www.ismcorp.net
Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press
release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of
1995. Forward-looking statements involve known and unknown risks and uncertainties which may cause the companys actual
results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things,
product price volatility, product demand, market competition, risk inherent in the companys domestic and international operations,
imprecision in estimating product reserves and the companys ability to replace and expand its holdings.
____________________________________________________________
Unsubscribe or access your membership settings at:
http://gs4.revnet.com/GMG/ctrlpanel/0/79
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA23903 for ietf-pkix-bks; Sat, 31 Oct 1998 12:44:38 -0800 (PST)
Received: from revnet4.revnet.com (revnet4.revnet.com [198.51.35.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA23899 for <ietf-pkix@imc.org>; Sat, 31 Oct 1998 12:44:37 -0800 (PST)
From: scj2@gs4.revnet.com
Received: from gs4.revnet.com (gs4.revnet.com [198.51.35.84]) by revnet4.revnet.com (8.8.7/8.8.7) with SMTP id OAA31179; Sat, 31 Oct 1998 14:42:43 -0600
Message-Id: <199810312042.OAA31179@revnet4.revnet.com>
To: scj2@gs4.revnet.com
Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent
Date: Sat, 31 Oct 1998 14:47:10 -0600
Originator: scj2@gs4.revnet.com
X-Mailer: GroupMaster
X-Mailer-Version: 1.5
X-GroupMasterUser: Revnet Express
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Please open the following message in your web browser
http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML
____________________________________________________________
International Shoe Manufacturing Corp Update:
International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage
financing to begin full-scale production at its plants in India. The $4.75 million is being
used to purchase the final equipment needed to begin production at the companys existing
plant in India. With equipment in place, the company projects net profits of over $25
million a year within two years.
The company stated that the financing will be followed up by a $9 million dollar IPO in
India, anticipated for March 1999. The IPO will be handled by underwriters in India, and
will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the
IPO will pay off the $4.75 million dollar financing. The balance will be used for the
acquisition of additional shoe manufacturing.
ISHO is in the business of manufacturing athletic footwear for the worlds leading shoe
companies. It owns a 23,000-square-foot plant located in the protected free trade zone in
Noida, just outside of New Delhi, India, where skilled labor is plentiful and very
inexpensive. The Indian government recently developed new economic policy to attract
foreign investment that is export-oriented, and could employ large numbers of people.
ISM is the only athletic shoe manufacturer in India directed toward the international
market. It currently has contracts with Adidas and The Pentland Group. These two
companies have agreed to purchase all the shoes ISM can manufacture.
The athletic shoe industry is estimated at $14.25 billion a year. The worlds leading shoe
companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design
and marketing organizations that spend hundreds of millions of dollars a year getting their
products sold. They then rely on others to manufacture to their specifications. Almost, if
not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of
millions of dollars spent on advertising by the name-brand companies. The result is an
open purchase order where such manufacturers literally can sell every pair of shoes they
can produce. A business like this lends itself to being privately held due to the large cash
flow allowing for internal financing. International Shoe Manufacturing Corp. is the only
company known to exist that offers a public investor the opportunity to own a share of this
highly lucrative business in a pure investment play.
For inquiries please contact the office of the director of investor relations toll free at:
877-ISM-CORP (877-476-2677) or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately. Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752
Please visit ISMs web site at www.ismcorp.net
Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press
release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of
1995. Forward-looking statements involve known and unknown risks and uncertainties which may cause the companys actual
results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things,
product price volatility, product demand, market competition, risk inherent in the companys domestic and international operations,
imprecision in estimating product reserves and the companys ability to replace and expand its holdings.
____________________________________________________________
Unsubscribe or access your membership settings at:
http://gs4.revnet.com/GMG/ctrlpanel/0/79
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27950 for ietf-pkix-bks; Fri, 30 Oct 1998 15:48:46 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27946 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 15:48:45 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id SAA00163; Fri, 30 Oct 1998 18:51:07 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id SAA09153; Fri, 30 Oct 1998 18:51:04 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AD.0082A38C ; Fri, 30 Oct 1998 18:46:55 -0500
X-Lotus-FromDomain: FDC
To: Al Arsenault <aarsenault@spyrus.com>
cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Bill Burr'" <william.burr@nist.gov>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Message-ID: <882566AD.006B35F7.00@lnsunr02.firstdata.com>
Date: Fri, 30 Oct 1998 15:48:03 -0800
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
while the current common certificate infrastructure model is SSL ... which
baiscally checks if the certificate has been manufactored by somebody in
the list of known certificate manufactors/issuers (aka CAs) .... the common
authentication model on the internet is logging on to the service provider.
This one is basically somebody signs up for an account and establishes a
password. When they want to use the internet ... they contact the router,
give their account name and proof of password. The router is likely running
something like radius ... in which case it forwards the account name and
password to an account authenticator.
For PKIX to address the most fundamental of internet authentication
requirements ... could involve the ISP issuing a relying party certificate
with just the account name (sidestepping liability and privacy issues). The
choice now would be would the ISP router accept the certificate
authentication at face-value ... or would it use a PKI flavor of radius to
contact an account authenticator .... for instance to have more timely
information on whether the account is in good standing.
This is possibly the most fundamental current internet requirement ... and
it illustrates again the extremely short step from relying party
certificates to the AADS model ... where if the account has to be touched
as part of the authentication/authoritization ... then it is easily shown
that shipping the certificate with the transaction is superfulous (if
somebody gives you a copy of something .... how many million times do you
have to send the same copy back to them ... before they realize that they
don't have to see the copy if they are already looking at the original
stored in the account record).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27693 for ietf-pkix-bks; Fri, 30 Oct 1998 15:03:12 -0800 (PST)
Received: from cane.deming.com (mail.smime.org [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27689; Fri, 30 Oct 1998 15:03:11 -0800 (PST)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Fri, 30 Oct 98 15:04:52 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.smime.org with Internet Mail Service (5.5.1960.3) id <VLN0Z7AH>; Fri, 30 Oct 1998 15:04:52 -0800
Message-ID: <01FF24001403D011AD7B00A024BC53C53A72A2@mail.smime.org>
From: "Blake Ramsdell" <BlakeR@deming.com>
To: "'Russ Housley'" <housley@spyrus.com>, "Robert Klerer" <klerer@xhair.com>
cc: <ietf-pkix@imc.org>, <ietf-smime@imc.org>
Subject: RE: email oid
Date: Fri, 30 Oct 1998 15:04:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 1A24999E55968-01-01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> -----Original Message-----
> From: Russ Housley [mailto:housley@spyrus.com]
> Sent: Thursday, October 29, 1998 5:39 PM
> To: Robert Klerer
> Cc: ietf-pkix@imc.org; ietf-smime@imc.org
> Subject: Re: email oid
>
> It is my understanding that the PKCS#9 OID is widely used in S/MIME v2
> implementations.
I have never seen anything other than the PKCS#9 OID used in S/MIME v2.
For the S/MIME camp this is not ambiguous at all.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA27278 for ietf-pkix-bks; Fri, 30 Oct 1998 13:46:15 -0800 (PST)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27274 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:46:14 -0800 (PST)
Received: from klerer.basit.com (shiva113 [128.209.144.113]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id QAA19715; Fri, 30 Oct 1998 16:47:07 -0500 (EST)
Message-ID: <006f01be044e$f2061e40$010ed180@klerer.basit.com>
From: "Robert Klerer" <klerer@xhair.com>
To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>, "'Russ Housley'" <housley@spyrus.com>
Cc: "'ietf-pkix'" <ietf-pkix@imc.org>, <John.Wang@CyberTrust.GTE.Com>
Subject: Re: email oid
Date: Fri, 30 Oct 1998 16:47:50 -0500
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 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sue,
Adding the additional OID would not be the optimum solution. Since if I
have an RDN of EA=klerer@xhair.com, am I referring to the RFC822mailbox or
the pkcs-9 address? Whichever choice will be wrong sometimes -- hence the
problem. pkix should NOT perpetuate the problem by again calling the same
thing two different names.
Robert
-----Original Message-----
From: Miklos, Sue A. <samiklo@missi.ncsc.mil>
To: 'Russ Housley' <housley@spyrus.com>
Cc: 'ietf-pkix' <ietf-pkix@imc.org>; 'klerer@xhair.com' <klerer@xhair.com>;
'John.Wang@CyberTrust.GTE.Com' <John.Wang@CyberTrust.GTE.Com>
Date: Friday, October 30, 1998 2:34 PM
Subject: RE: email oid
>Russ, and others, may I then request that it be included or is that not
>possible?
>
>Sandi
>
>>----------
>>From: Russ Housley[SMTP:housley@spyrus.com]
>>Sent: Friday, October 30, 1998 1:35 PM
>>To: Miklos, Sue A.
>>Cc: 'ietf-pkix'; 'klerer@xhair.com'; 'John.Wang@CyberTrust.GTE.Com'
>>Subject: Re: email oid
>>
>>Sandi:
>>
>>"Remain" is the issue. It is not in PKIX part 1!
>>
>>Russ
>>
>>
>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>All,
>>>In the specifications for the schema for an international defense
>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>registered
>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>I would like to request that this remain in whatever documentation you
>>>develop.
>>>
>>>Thanks,
>>>Sandi Miklos
>>>>
>>>>
>>>>----------
>>>>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>To: 'Robert Klerer'; ietf-pkix@imc.org
>>>>Subject: RE: email oid
>>>>
>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>if there is a demand for it.
>>>>
>>>>-----Original Message-----
>>>>From: Robert Klerer [mailto:klerer@xhair.com]
>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>To: ietf-pkix@imc.org
>>>>Subject: email oid
>>>>
>>>>
>>>>The other day in trying to accommodate a legacy pki, I ran into a
problem
>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1
>>>>specifies
>>>>that the oid used for an email address in the distinguished name is
>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
mail
>>>>as specified in RFC1274.
>>>>
>>>>Since I believe that the intention is for both of these oids are meant
to
>>>>represent attributes that hold the same information, this discrepancy
may
>>>>cause confusion and failures in the future. My suggestion would be to
>>>>change part1 to refer to the more commonly used OID.
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA27192 for ietf-pkix-bks; Fri, 30 Oct 1998 13:37:24 -0800 (PST)
Received: from mail.innetix.com (oldmail.innetix.com [207.126.108.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27188 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:37:23 -0800 (PST)
Received: from iris (user7.sj.dialup.innetix.com [209.172.68.70]) by mail.innetix.com (8.8.7/8.8.5) with SMTP id NAA28300; Fri, 30 Oct 1998 13:31:15 -0800 (PST)
Message-Id: <3.0.2.32.19981030133102.006d8b48@innetix.com>
X-Sender: bruceg@innetix.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32)
Date: Fri, 30 Oct 1998 13:31:02 -0800
To: helm@fionn.es.net, ietf-pkix@imc.org
From: Bruce Greenblatt <bruceg@innetix.com>
Subject: Re: Scale (and the SRV record)
In-Reply-To: <199810301749.JAA18064@fionn.es.net>
References: <Your message of "Fri, 30 Oct 1998 10:25:55 MST." <s639943d.073@prv-mail25.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
At 09:49 AM 10/30/98 -0800, Michael Helm wrote:
[snip]
>Arguments made in this vein seem convincing to me -- convincing
>that you need signed operations & a very hi standard of integrity,
[snip]
...
For signed operations, you might want to take a look at the Signed
Operations draft of the LDAP Extensions WG
(http://info.internet.isi.edu:80/0/in-drafts/files/draft-ietf-ldapext-sigops
-03.txt). Constructive comments are always welcome. Please post them in
the appropriate mailing list though (i.e. not this one), or privately to
the authors (e.g. me).
Bruce
================================================
Bruce Greenblatt bruceg@innetix.com
http://www.innetix.com/~bruceg
================================================
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25580 for ietf-pkix-bks; Fri, 30 Oct 1998 10:42:25 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25575 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 10:42:24 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA08535 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:44:45 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA08530 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:44:45 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA22393 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:43:50 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000336409@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:44:39 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BE040B.713A2560@avenger.missi.ncsc.mil>; Fri, 30 Oct 1998 13:44:40 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981030184439Z-3919@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'Russ Housley'" <housley@spyrus.com>
Cc: "'ietf-pkix'" <ietf-pkix@imc.org>, "'klerer@xhair.com'" <klerer@xhair.com>, "'John.Wang@CyberTrust.GTE.Com'" <John.Wang@CyberTrust.GTE.Com>
Subject: RE: email oid
Date: Fri, 30 Oct 1998 13:44:39 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Russ, and others, may I then request that it be included or is that not
possible?
Sandi
>----------
>From: Russ Housley[SMTP:housley@spyrus.com]
>Sent: Friday, October 30, 1998 1:35 PM
>To: Miklos, Sue A.
>Cc: 'ietf-pkix'; 'klerer@xhair.com'; 'John.Wang@CyberTrust.GTE.Com'
>Subject: Re: email oid
>
>Sandi:
>
>"Remain" is the issue. It is not in PKIX part 1!
>
>Russ
>
>
>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>All,
>>In the specifications for the schema for an international defense
>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>registered
>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>I would like to request that this remain in whatever documentation you
>>develop.
>>
>>Thanks,
>>Sandi Miklos
>>>
>>>
>>>----------
>>>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>To: 'Robert Klerer'; ietf-pkix@imc.org
>>>Subject: RE: email oid
>>>
>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>if there is a demand for it.
>>>
>>>-----Original Message-----
>>>From: Robert Klerer [mailto:klerer@xhair.com]
>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>To: ietf-pkix@imc.org
>>>Subject: email oid
>>>
>>>
>>>The other day in trying to accommodate a legacy pki, I ran into a problem
>>>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1
>>>specifies
>>>that the oid used for an email address in the distinguished name is
>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>>>as specified in RFC1274.
>>>
>>>Since I believe that the intention is for both of these oids are meant to
>>>represent attributes that hold the same information, this discrepancy may
>>>cause confusion and failures in the future. My suggestion would be to
>>>change part1 to refer to the more commonly used OID.
>>>
>>>
>>>
>>>
>>>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25487 for ietf-pkix-bks; Fri, 30 Oct 1998 10:34:30 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25483 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 10:34:29 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA12998; Fri, 30 Oct 1998 10:36:17 -0800 (PST)
Message-Id: <4.1.19981030133442.0099ded0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 13:35:10 -0500
To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
From: Russ Housley <housley@spyrus.com>
Subject: Re: email oid
Cc: "'ietf-pkix'" <ietf-pkix@imc.org>, "'klerer@xhair.com'" <klerer@xhair.com>, "'John.Wang@CyberTrust.GTE.Com'" <John.Wang@CyberTrust.GTE.Com>
In-Reply-To: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981030165333Z-3800@avenge r.missi.ncsc.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sandi:
"Remain" is the issue. It is not in PKIX part 1!
Russ
At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>All,
>In the specifications for the schema for an international defense
>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>registered
>in RFC 1274. This attribute was also called mail in one Internet Draft.
>I would like to request that this remain in whatever documentation you
>develop.
>
>Thanks,
>Sandi Miklos
>>
>>
>>----------
>>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>>Sent: Thursday, October 29, 1998 9:17 AM
>>To: 'Robert Klerer'; ietf-pkix@imc.org
>>Subject: RE: email oid
>>
>>It was my understanding that the RSA-pkcs-9 email address OID
>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>if there is a demand for it.
>>
>>-----Original Message-----
>>From: Robert Klerer [mailto:klerer@xhair.com]
>>Sent: Thursday, October 29, 1998 8:19 AM
>>To: ietf-pkix@imc.org
>>Subject: email oid
>>
>>
>>The other day in trying to accommodate a legacy pki, I ran into a problem
>>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
>>that the oid used for an email address in the distinguished name is
>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>>as specified in RFC1274.
>>
>>Since I believe that the intention is for both of these oids are meant to
>>represent attributes that hold the same information, this discrepancy may
>>cause confusion and failures in the future. My suggestion would be to
>>change part1 to refer to the more commonly used OID.
>>
>>
>>
>>
>>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25233 for ietf-pkix-bks; Fri, 30 Oct 1998 10:00:03 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25226 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:59:58 -0800 (PST)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id KAA18838 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 10:02:20 -0800 (PST)
Message-Id: <199810301802.KAA18838@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Fri, 30 Oct 1998 15:29:04 GMT." <199810301657.QAA22890@ns0.zergo.com>
Date: Fri, 30 Oct 1998 10:02:19 -0800
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
GBland@zergo.com writes:
> Could purchasing software from Microsoft (or Netscape or other) be
> regarded as an authentication mechanism and secure distribution
> mechanism for certificates.
Getting the CD would be, perhaps....
> > From: MHenry [mailto:MHenry@PEC.com]
> > interestingly enough, the largest base of existing
> > pki users (those that have browsers with a hard coded
> > certs at time of purchase) do, regularly, exactly what you take for
> > granted they would never do.=20
I think that the netscape online distribution of the 128-bit
browsers is done thru an ssl connection (& a verisign
certificate for their server). Somewhere along the line,
tho, you got a browser with a verisign CA cert via a connection
that wasn't "authenticated" in this fashion! (NB: It may be that
the software download switches over to non ssl after you pledge
allegiance.)
The IE distribution is different. For windows the browser itself
& related tools is done non-SSL, & you download a separate 128-bit
kit for some other part of 9*/NT via SSL. So the built-in certs are
delivered in a non-authenticated fashion. For Solaris (the
last time I tried this) you get a new 128-bit browser securely,
so the certs are delivered in an authenticated fashion.
(Same comment about browser applies as above.)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA25072 for ietf-pkix-bks; Fri, 30 Oct 1998 09:47:17 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25067 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:47:12 -0800 (PST)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id JAA18064 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:49:30 -0800 (PST)
Message-Id: <199810301749.JAA18064@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Fri, 30 Oct 1998 10:25:55 MST." <s639943d.073@prv-mail25.provo.novell.com>
Date: Fri, 30 Oct 1998 09:49:30 -0800
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
"Tolga Acar" writes:
> >up for an attack based on a single (or small integer number) point
> >of failure? For example maybe I could trick you into using
> Violation of integrity on the victim's side.
> if you ruin the baseline (integrity), and expect to be secure. can't do it.
> besides, this will hurt that particular victim, not others.
...
> insecurity is coming from the lack of integrity, so called "less reliable".
> you have to have them both: security and integrity. If one is missing, you can't have the other.
Arguments made in this vein seem convincing to me -- convincing
that you need signed operations & a very hi standard of integrity,
as put here, in the services that provide portions of the pki, even if it
seems unnecessary from a theoretical point of view. You never
can tell what a security breach will escalate into, & the
secureness or integrity of the potential victims is almost always
very questionable given the large number of variables (software,
protocol vulnerabilities, social engineering) that most of us
potential victims are subject to.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24969 for ietf-pkix-bks; Fri, 30 Oct 1998 09:34:46 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24941; Fri, 30 Oct 1998 09:32:49 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id JAA11982; Fri, 30 Oct 1998 09:34:08 -0800 (PST)
Message-Id: <4.1.19981029203817.0092fd20@mail.spyrus.com>
Message-Id: <4.1.19981029203817.0092fd20@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 29 Oct 1998 20:39:10 -0500
To: "Robert Klerer" <klerer@xhair.com>
From: Russ Housley <housley@spyrus.com>
Subject: Re: email oid
Cc: ietf-pkix@imc.org, ietf-smime@imc.org
In-Reply-To: <001201be033e$a3e06380$010ed180@klerer.basit.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
It is my understanding that the PKCS#9 OID is widely used in S/MIME v2
implementations.
Russ
At 08:18 AM 10/29/98 -0500, Robert Klerer wrote:
>The other day in trying to accommodate a legacy pki, I ran into a problem
>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
>that the oid used for an email address in the distinguished name is
>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>as specified in RFC1274.
>
>Since I believe that the intention is for both of these oids are meant to
>represent attributes that hold the same information, this discrepancy may
>cause confusion and failures in the future. My suggestion would be to
>change part1 to refer to the more commonly used OID.
>
>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24929 for ietf-pkix-bks; Fri, 30 Oct 1998 09:32:12 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24925 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:32:11 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id JAA11957; Fri, 30 Oct 1998 09:34:00 -0800 (PST)
Message-Id: <4.1.19981029202203.009f8450@mail.spyrus.com>
Message-Id: <4.1.19981029202203.009f8450@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 29 Oct 1998 20:25:20 -0500
To: salzr@certco.com
From: Russ Housley <housley@spyrus.com>
Subject: RE: Scale (and the SRV record)
Cc: ietf-pkix@imc.org
In-Reply-To: <29E0A6D39ABED111A36000A0C99609CA18D2FA@macertco-srv1.ma.ce rtco.com>
References: <000a01be0352$2b946660$c807a8c0@pbaker-pc.verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
This vulnerability cannt be completely eliminated. The CA's policy
determines the amount of risk associated with the frequency of CRL
issuance. Even if a fresh CRL is posted prior ti the earlier on expiring,
clinets may obtain the older one from a cache.
OCSP was supposed to address this concern. But, even OCSP does not get a
fresh answer for every query. Without a protocol that goes all the way to
the CA for a fresh response for every query, this vulnerability cannot be
eliminated.
Russ
At 01:59 PM 10/29/98 -0500, salzr@certco.com wrote:
>>If someone spoofed DNS the worst that would happen is that I would
>>recieve a certificate I didn't trust (and would ignore) or no >certificate
>at all.
>
>Well, if you're only fetching certificates, probably.
>
>But if you're fetching CRL's, then no. Suppose a cert is compromised,
>and CRLn is issued before the "next update" time purely because of
>that compromise. The adversary could spoof DNS and just send out
>the valid, but outdated CRL(n-1) and potentially have quite a
>window of opportunity.
> /r$
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24866 for ietf-pkix-bks; Fri, 30 Oct 1998 09:24:47 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA24862 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:24:46 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Oct 1998 10:26:09 -0700
Message-Id: <s6399441.007@orm-mail20.provo.novell.com>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 30 Oct 1998 10:25:55 -0700
From: "Tolga Acar" <TACAR@novell.com>
To: <helm@fionn.es.net>, <ietf-pkix@imc.org>
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA24863
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>>> Michael Helm <helm@fionn.es.net> 10/30/98 10:05:09 >>>
>This is theoretically true, but then, aren't you setting yourself
>up for an attack based on a single (or small integer number) point
>of failure? For example maybe I could trick you into using
>a bad certificate database (by breaking into a login of yours
>somewhere & trojanning your personal software) but I may not
Violation of integrity on the victim's side.
if you ruin the baseline (integrity), and expect to be secure. can't do it.
besides, this will hurt that particular victim, not others.
>On the other hand, would price would we pay for this complexity?
>Would we somehown make operations more insecure and/or less reliable?
insecurity is coming from the lack of integrity, so called "less reliable".
you have to have them both: security and integrity. If one is missing, you can't have the other.
- Tolga
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24654 for ietf-pkix-bks; Fri, 30 Oct 1998 09:02:53 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24649 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:02:52 -0800 (PST)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id JAA17214 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:05:10 -0800 (PST)
Message-Id: <199810301705.JAA17214@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Fri, 30 Oct 1998 09:32:51 GMT." <199810301101.LAA21997@ns0.zergo.com>
Date: Fri, 30 Oct 1998 09:05:09 -0800
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Graham Bland writes:
> Why would DNS need to be more secure with signed operations mutual
> authentication etc. Certificates and CRLs are signed objects and their
> security is inherent. Ignoring denial of service I cannot see any
This is theoretically true, but then, aren't you setting yourself
up for an attack based on a single (or small integer number) point
of failure? For example maybe I could trick you into using
a bad certificate database (by breaking into a login of yours
somewhere & trojanning your personal software) but I may not
have enuf access to change your ldap server's certificate db or
trojan your secure dns. If these things were doing signed operations
you may be able to notice you have a problem, or you may make the
attacker's need to fool you more complex & expensive.
On the other hand, would price would we pay for this complexity?
Would we somehown make operations more insecure and/or less reliable?
> What is the problem with the scalability of DNS (How many users does it
> support now ?)
The current commonly used software is terribly memory-intensive
& adding gigantic certificate data-blobs to that is scary.
If your dns stops working the internet (as far as you are concerned!)
goes away. Of course the software will improve.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24557 for ietf-pkix-bks; Fri, 30 Oct 1998 08:51:19 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24552 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 08:51:18 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA00425 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:53:35 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA00417 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:53:34 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA08478 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:52:40 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000336064@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:53:33 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BE03FB.EBF68970@avenger.missi.ncsc.mil>; Fri, 30 Oct 1998 11:53:34 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981030165333Z-3800@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'ietf-pkix'" <ietf-pkix@imc.org>
Cc: "'klerer@xhair.com'" <klerer@xhair.com>, "'John.Wang@CyberTrust.GTE.Com'" <John.Wang@CyberTrust.GTE.Com>
Subject: email oid
Date: Fri, 30 Oct 1998 11:53:33 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
In the specifications for the schema for an international defense
system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
registered
in RFC 1274. This attribute was also called mail in one Internet Draft.
I would like to request that this remain in whatever documentation you
develop.
Thanks,
Sandi Miklos
>
>
>----------
>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>Sent: Thursday, October 29, 1998 9:17 AM
>To: 'Robert Klerer'; ietf-pkix@imc.org
>Subject: RE: email oid
>
>It was my understanding that the RSA-pkcs-9 email address OID
>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>think you can remove the RSA oid but perhaps add the RFC1274 oid
>if there is a demand for it.
>
>-----Original Message-----
>From: Robert Klerer [mailto:klerer@xhair.com]
>Sent: Thursday, October 29, 1998 8:19 AM
>To: ietf-pkix@imc.org
>Subject: email oid
>
>
>The other day in trying to accommodate a legacy pki, I ran into a problem
>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
>that the oid used for an email address in the distinguished name is
>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>as specified in RFC1274.
>
>Since I believe that the intention is for both of these oids are meant to
>represent attributes that hold the same information, this discrepancy may
>cause confusion and failures in the future. My suggestion would be to
>change part1 to refer to the more commonly used OID.
>
>
>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24354 for ietf-pkix-bks; Fri, 30 Oct 1998 08:24:48 -0800 (PST)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24350 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 08:24:46 -0800 (PST)
Received: from stefans (t4o68p54.telia.com [62.20.139.174]) by maila.telia.com (8.8.8/8.8.8) with SMTP id RAA15715; Fri, 30 Oct 1998 17:26:51 +0100 (CET)
Message-Id: <3.0.32.19981030172236.00a5f980@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 30 Oct 1998 17:23:07 +0100
To: Anders Rundgren <anders.rundgren@jaybis.com>, "'SEIS-List'" <list@seis.nc-forum.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: QC - civicRegistrationNumber
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA24351
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Good point.
I made a search on "civic registration number" and found that it's only
used in Sweden. And as you say, there are countries where non-numeric
characters are used (as in Finland)
It appears that both the wordings "civic registration" and "registration
code" are used in a context wich match our purpose even though i can't find
any documents using the exact combination "civic registration code"
/Stefan
At 01:29 PM 10/30/98 +0100, Anders Rundgren wrote:
>Regarding Qualified Certificates:
>
>civicRegistrationNumber
>
>should IMHO be altered to
>
>civicRegistrationCode
>
>as it does not have to be numeric
>
>Anders Rundgren
>Senior Internet E-commerce Architect
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23968 for ietf-pkix-bks; Fri, 30 Oct 1998 07:36:45 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23964 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:36:44 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA10210; Fri, 30 Oct 1998 07:38:26 -0800 (PST)
Message-Id: <4.1.19981030103143.00a23630@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 10:33:26 -0500
To: David Boyce <D.Boyce@isode.com>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: ietf-pkix@imc.org
In-Reply-To: <5421.909760948@isode.com>
References: <Your message of "Fri, 30 Oct 1998 09:04:20 EST." <4.1.19981030083342.00a26a10@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
David,
I was unaware of such use. I stand corrected. I'll change my statement to
X.509 is not used in PKIX for its original, X.500-based purpose.
Al Arsenault
-- as if any employer would want to claim my opinions...
At 03:22 PM 10/30/98 +0000, David Boyce wrote:
>Al Arsenault writes:
>>>
>>> Isnt it odd that X.509 is used for PKI and X.500 is discounted?
>>>
>>
>>AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI
>business.
>>X.509 is not used for its original, X.500-based purpose, which was
>actually
>>to control access to the directory for the purpose of limiting who
>could
>>modify entries.
>
>I'm sorry, Al, but it is factually incorrect to say that X.509 is not
>used for its original, X.500-based purpose. There is at least one
>commercial implementation of X.500 which supports strong authentication
>using X.509 certificates, and makes use of the fact for Access Control
>purposes.
>
>I'll grant that X.509 is being used beyond its original purpose, but
>that's just a measure of its utility.
>
>David.
>--
>David Boyce
>
>Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
>Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23903 for ietf-pkix-bks; Fri, 30 Oct 1998 07:30:08 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23891 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:29:51 -0800 (PST)
From: GBland@zergo.com
Message-Id: <199810301657.QAA22890@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
To: MHenry@pec.com, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 15:29:04 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE041A.06C29E92"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE041A.06C29E92
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
An interesting thought.
Could purchasing software from Microsoft (or Netscape or other) be
regarded as an authentication mechanism and secure distribution
mechanism for certificates.
It depends on how much you trust the software vendor (if at all).
Perhaps free certificates are just good value for money.
Graham Bland
> -----Original Message-----
> From: MHenry [mailto:MHenry@PEC.com]
> Sent: 30 October 1998 14:57
> To: GBland@zergo.com; aarsenault@spyrus.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>=20
>=20
> al,
> interestingly enough, the largest base of existing
> pki users (those that have browsers with a hard coded
> certs at time of purchase) do, regularly, exactly what you take for
> granted they would never do.=20
> semper fi,
> mike henry
>=20
> > -----Original Message-----
> > From: GBland@zergo.com [SMTP:GBland@zergo.com]
> > Sent: Friday, October 30, 1998 8:41 AM
> > To: aarsenault@spyrus.com; ietf-pkix@imc.org
> > Subject: RE: Scale (and the SRV record)
> >=20
> > I had taken it for granted that nobody would trust a self signed
> > certificate without having validated it by either a secure=20
> distribution
> > mechanism or verification of the hash from a trusted source.
> >=20
> > I am pleased to say we are in total agreement.=20
> >=20
> > Graham Bland=20
> >=20
> > > -----Original Message-----=20
> > > From: Al Arsenault [ <mailto:aarsenault@spyrus.com>]=20
> > > Sent: 30 October 1998 13:29=20
> > > To: GBland@zergo.com; ietf-pkix@imc.org=20
> > > Subject: RE: Scale (and the SRV record)=20
> > >=20
> > >=20
> > > Since I agree with most of what Phill has to say on this=20
> > > topic, I'll go against=20
> > > my better judgement and jump in here.=20
> > >=20
> > > If I'm understanding this correctly, the attack of concern is=20
> > > as follows:=20
> > > Nothing today stops me from cobbling together my own=20
> > > certificate-generating and=20
> > > -signing software, and then generating a self-signed=20
> > > certificate for user "US=20
> > > Verisign Primary Class 3 Public Certificate Authority" (or=20
> > > whatever the magic=20
> > > string is that will exactly match what VeriSign uses).=A0 This=20
> > > new certificate=20
> > > will use the public key corresponding to a private key that I=20
> > > know, rather than=20
> > > the one that VeriSign actually uses.=A0 (This ignores the=20
> > > scenario described by=20
> > > Graham, in which I've managed to obtain VeriSign's private key.)=20
> > >=20
> > > Given this, can I get you, the unsuspecting user, to use MY=20
> > > certificate (and=20
> > > any user certificates I then issue with it) instead of the=20
> > > real one?=A0 After=20
> > > all, once you've retrieved the certificate, the DN or=20
> > > subjectAltName field will=20
> > > LOOK "right" to you, if you bother to check it.=A0 The argument=20
> > > has been that=20
> > > given an insecure, spoofable, distribution mechanism, I might=20
> > > be able to fool=20
> > > you into using the wrong "VeriSign certificate".=A0 If, for=20
> > > example, I can spoof=20
> > > DNS and make you think that the IP address corresponding to=20
> > > "VeriSign.com" is,=20
> > > say, 130.85.1.3,=A0 and I control that machine (note: I don't=20
> > > :-) then you'll go=20
> > > there for the "real certificate" and I've got you.=A0 So, to=20
> > > counter that, you=20
> > > need a "secure" distribution mechanism.=20
> > >=20
> > > I frankly don't buy that argument, though.=A0 What is required=20
> > > in a PKI is that I=20
> > > somehow securely obtain the certificate/public key of a CA=20
> > > that I have chosen=20
> > > to trust - normally, that's the one that issued my=20
> > > certificate.=A0 If this first=20
> > > step is broken - I'm fooled into accepting a certificate from=20
> > > a phony CA, or=20
> > > whatever - then the security of the entire PKI is shot, and=20
> > > no X.500 directory=20
> > > or other mechanism is going to help.=A0 Once I have that public=20
> > > key, though, I=20
> > > can detect any faked certificates based on the trust my CA=20
> > > has.=A0 My CA will=20
> > > have cross-certified with the REAL VeriSign Class 3 primary=20
> > > CA (when WHAT=20
> > > freezes over? :-)=A0=A0 Thus, even if I get your phony VeriSign=20
> > > cert that looks to=20
> > > be the right one based on the name, I can't build a=20
> > > certification path back to=20
> > > a node I trust, because my CA or whomever else I trust hasn't=20
> > > signed your=20
> > > spoof.=A0 I'm protected against your spoof by the certificates=20
> > > and CRLs, not the=20
> > > distribution mechanism.=20
> > >=20
> > > (Of course, if you can trick the people I trust - my CA, for=20
> > > example - into=20
> > > cross-certifying your fake certificate, I'm hosed.=A0 But that=20
> > > just means that I=20
> > > trusted some incompetent fool I shouldn't have.=A0 A '"secure"=20
> > > X.500 directory=20
> > > won't help at all once my CA has botched it.)=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > =
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Al Arsenault=20
> > >=20
> > > --- standard disclaimer - my own opinions; don't reflect=20
> > > those of my employer=20
> > > or of any other organization to which I may have a=20
> > > relationship; etc., etc., ad=20
> > > infinitum, ad nauseum=20
> > >=20
> > >=20
> > >=20
> > >=A0=A0=A0=A0=A0=A0=A0=A0=20
> > >=20
> > > At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:=20
> > >=20
> > > >=20
> > > > How are you going to do all this ?=20
> > > >=20
> > > > The only way I can think of is that either you know or have=20
> > > compromised the=20
> > > > CA private keys.=20
> > > > If you know the private signature keys then all information=20
> > > is compromised=20
> > > > regardless of source.=20
> > > > If you don't how will you construct the Certificates, CRLs,=20
> > > OCSP responses=20
> > > > etc.=20
> > > >=20
> > > > This is an attack based on the compromise of the CA, not=20
> > > the security of DNS=20
> > > > OCSP etc.=20
> > > >=20
> > > > Graham Bland=20
> > > >=20
> > > > > -----Original Message-----=20
> > > > > From: Ron Ramsay=20
> > > >=20
> > > [< <mailto:Ron.Ramsay@OpenDirectory.com.au>>=20
> <mailto:Ron.Ramsay@Ope>=20
> > > nDirectory.c=20
> > > > om.au]=20
> > > > > Sent: 30 October 1998 02:42=20
> > > > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd=20
> > > > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey=20
> > > > > Subject: RE: Scale (and the SRV record)=20
> > > > >=20
> > > > >=20
> > > > > Phillip,=20
> > > > >=20
> > > > > Thanks again.=20
> > > > >=20
> > > > > Let me pick up on two points.=20
> > > > >=20
> > > > > Firsly, DNS security. If I can spoof DNS (which doesn't look=20
> > > > > to hard) I=20
> > > > > can provide the address of my server in any of the records of =
> > > > > interest.=20
> > > > > A request for your certificate will come to my server and=20
> > > I will send=20
> > > > > back the certificate that I have constructed for you. If=20
> > > you ask for a=20
> > > > > CRL I will give you one that doesn't name this=20
> > > certificate. If you=20
> > > > > choose to use a validation service like OCSP that's OK=20
> > > because I'll=20
> > > > > return 'valid' for your/my certificate.=20
> > > > >=20
> > > > > Denial of service is the best bad behaviour you can=20
> > > expect. Positively=20
> > > > > helpful service is much worse!=20
> > > > >=20
> > > > > Secondly, you're going to send your certificate with the=20
> > > > > message. Why, I=20
> > > > > shall do that too! So I'm still you!=20
> > > > >=20
> > > > > It is interesting you say that the worst that can happen=20
> > > is that you=20
> > > > > receive a certificate you don't trust. How do you know=20
> > > you don't trust=20
> > > > > it? I should think if you already know what certificates you=20
> > > > > trust then=20
> > > > > you don't need PKI at all!=20
> > > > >=20
> > > > > Ron.=20
> > > > > > -----Original Message-----=20
> > > > > > From:=A0=A0=A0=A0=A0=A0 Phillip M Hallam-Baker=20
> [SMTP:pbaker@verisign.com]=20
> > > > > > Sent:=A0=A0=A0=A0=A0=A0 Friday, October 30, 1998 2:38 AM=20
> > > > > > To:Ron Ramsay; Alan Lloyd=20
> > > > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey=20
> > > > > > Subject:=A0=A0=A0 RE: Scale (and the SRV record)=20
> > > > > >=20
> > > > > >=20
> > > > > >=20
> > > > > > > Phillip,=20
> > > > > > >=20
> > > > > > > Thanks for taking time to develop the example.=20
> > > > > > >=20
> > > > > > > Two issues:=20
> > > > > > >=20
> > > > > > > 1. Surely DNS is not secure?=20
> > > > > >=20
> > > > > > Define secure? With the exception of a denial of=20
> > > service attack DNS=20
> > > > > > is 'secure enough' for this purpose since there is no=20
> > > trust placed=20
> > > > > > on the server. The origin of a signed message is=20
> > > irrelevant. Only=20
> > > > > > the signature is relevant.=20
> > > > > >=20
> > > > > > > 2. Your example seems to be based on encryption using=20
> > > public keys.=20
> > > > > > From=20
> > > > > > > what I know of the public key system, it is not used for=20
> > > > > encryption.=20
> > > > > >=20
> > > > > >=20
> > > > > > I think you are confusing DNS security here with PKIX.=20
> > > The two are=20
> > > > > > very=20
> > > > > > separate.=20
> > > > > >=20
> > > > > > If someone spoofed DNS the worst that would happen is=20
> > > that I would=20
> > > > > > recieve a certificate I didn't trust (and would=20
> ignore) or no=20
> > > > > > certificate=20
> > > > > > at all.=20
> > > > > >=20
> > > > > > >Its=20
> > > > > > > purpose is authentication and integrity. To bend your=20
> > > example, you=20
> > > > > > will=20
> > > > > > > be encrypting your message with your own private key.=20
> > > How is an=20
> > > > > > > addressee to verify it was you who sent the message=20
> > > and that the=20
> > > > > > message=20
> > > > > > > was not modified?=20
> > > > > >=20
> > > > > > I send my signing certificate with the message. Or once the =
> > > > > > infrastructure=20
> > > > > > is deployed the recipient could use the SRV pointer=20
> to locate a=20
> > > > > > directory=20
> > > > > > where a copy of the certificate was available.=20
> > > > > >=20
> > > > > >=A0=A0=A0=A0=A0=A0 Phill=20
> > > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
>=20
------ =_NextPart_001_01BE041A.06C29E92
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>An interesting thought.</FONT>
</P>
<P><FONT SIZE=3D2>Could purchasing software from Microsoft (or Netscape =
or other) be regarded as an authentication mechanism and secure =
distribution mechanism for certificates.</FONT></P>
<P><FONT SIZE=3D2>It depends on how much you trust the software vendor =
(if at all).</FONT>
</P>
<P><FONT SIZE=3D2>Perhaps free certificates are just good value for =
money.</FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: MHenry [<A HREF=3D"mailto:MHenry@PEC.com" =
TARGET=3D"_blank">mailto:MHenry@PEC.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 30 October 1998 14:57</FONT>
<BR><FONT SIZE=3D2>> To: GBland@zergo.com; aarsenault@spyrus.com; =
ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> al,</FONT>
<BR><FONT SIZE=3D2>> interestingly enough, the largest base of =
existing</FONT>
<BR><FONT SIZE=3D2>> pki users (those that have browsers with a hard =
coded</FONT>
<BR><FONT SIZE=3D2>> certs at time of purchase) do, regularly, =
exactly what you take for</FONT>
<BR><FONT SIZE=3D2>> granted they would never do. </FONT>
<BR><FONT SIZE=3D2>> semper fi,</FONT>
<BR><FONT SIZE=3D2>> mike henry</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> > From: =
GBland@zergo.com [SMTP:GBland@zergo.com]</FONT>
<BR><FONT SIZE=3D2>> > Sent: =
Friday, October 30, 1998 8:41 AM</FONT>
<BR><FONT SIZE=3D2>> > To:aarsenault@spyrus.com; =
ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> > Subject: RE: Scale (and =
the SRV record)</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I had taken it for granted that nobody =
would trust a self signed</FONT>
<BR><FONT SIZE=3D2>> > certificate without having validated it by =
either a secure </FONT>
<BR><FONT SIZE=3D2>> distribution</FONT>
<BR><FONT SIZE=3D2>> > mechanism or verification of the hash from =
a trusted source.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I am pleased to say we are in total =
agreement. </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Graham Bland </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > > -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>> > > From: Al Arsenault [ <<A =
HREF=3D"mailto:aarsenault@spyrus.com" =
TARGET=3D"_blank">mailto:aarsenault@spyrus.com</A>>] </FONT>
<BR><FONT SIZE=3D2>> > > Sent: 30 October 1998 13:29 </FONT>
<BR><FONT SIZE=3D2>> > > To: GBland@zergo.com; =
ietf-pkix@imc.org </FONT>
<BR><FONT SIZE=3D2>> > > Subject: RE: Scale (and the SRV =
record) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Since I agree with most of what Phill =
has to say on this </FONT>
<BR><FONT SIZE=3D2>> > > topic, I'll go against </FONT>
<BR><FONT SIZE=3D2>> > > my better judgement and jump in here. =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > If I'm understanding this correctly, =
the attack of concern is </FONT>
<BR><FONT SIZE=3D2>> > > as follows: </FONT>
<BR><FONT SIZE=3D2>> > > Nothing today stops me from cobbling =
together my own </FONT>
<BR><FONT SIZE=3D2>> > > certificate-generating and </FONT>
<BR><FONT SIZE=3D2>> > > -signing software, and then =
generating a self-signed </FONT>
<BR><FONT SIZE=3D2>> > > certificate for user "US </FONT>
<BR><FONT SIZE=3D2>> > > Verisign Primary Class 3 Public =
Certificate Authority" (or </FONT>
<BR><FONT SIZE=3D2>> > > whatever the magic </FONT>
<BR><FONT SIZE=3D2>> > > string is that will exactly match =
what VeriSign uses).=A0 This </FONT>
<BR><FONT SIZE=3D2>> > > new certificate </FONT>
<BR><FONT SIZE=3D2>> > > will use the public key corresponding =
to a private key that I </FONT>
<BR><FONT SIZE=3D2>> > > know, rather than </FONT>
<BR><FONT SIZE=3D2>> > > the one that VeriSign actually =
uses.=A0 (This ignores the </FONT>
<BR><FONT SIZE=3D2>> > > scenario described by </FONT>
<BR><FONT SIZE=3D2>> > > Graham, in which I've managed to =
obtain VeriSign's private key.) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Given this, can I get you, the =
unsuspecting user, to use MY </FONT>
<BR><FONT SIZE=3D2>> > > certificate (and </FONT>
<BR><FONT SIZE=3D2>> > > any user certificates I then issue =
with it) instead of the </FONT>
<BR><FONT SIZE=3D2>> > > real one?=A0 After </FONT>
<BR><FONT SIZE=3D2>> > > all, once you've retrieved the =
certificate, the DN or </FONT>
<BR><FONT SIZE=3D2>> > > subjectAltName field will </FONT>
<BR><FONT SIZE=3D2>> > > LOOK "right" to you, if you =
bother to check it.=A0 The argument </FONT>
<BR><FONT SIZE=3D2>> > > has been that </FONT>
<BR><FONT SIZE=3D2>> > > given an insecure, spoofable, =
distribution mechanism, I might </FONT>
<BR><FONT SIZE=3D2>> > > be able to fool </FONT>
<BR><FONT SIZE=3D2>> > > you into using the wrong =
"VeriSign certificate".=A0 If, for </FONT>
<BR><FONT SIZE=3D2>> > > example, I can spoof </FONT>
<BR><FONT SIZE=3D2>> > > DNS and make you think that the IP =
address corresponding to </FONT>
<BR><FONT SIZE=3D2>> > > "VeriSign.com" is, </FONT>
<BR><FONT SIZE=3D2>> > > say, 130.85.1.3,=A0 and I control =
that machine (note: I don't </FONT>
<BR><FONT SIZE=3D2>> > > :-) then you'll go </FONT>
<BR><FONT SIZE=3D2>> > > there for the "real =
certificate" and I've got you.=A0 So, to </FONT>
<BR><FONT SIZE=3D2>> > > counter that, you </FONT>
<BR><FONT SIZE=3D2>> > > need a "secure" =
distribution mechanism. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > I frankly don't buy that argument, =
though.=A0 What is required </FONT>
<BR><FONT SIZE=3D2>> > > in a PKI is that I </FONT>
<BR><FONT SIZE=3D2>> > > somehow securely obtain the =
certificate/public key of a CA </FONT>
<BR><FONT SIZE=3D2>> > > that I have chosen </FONT>
<BR><FONT SIZE=3D2>> > > to trust - normally, that's the one =
that issued my </FONT>
<BR><FONT SIZE=3D2>> > > certificate.=A0 If this first </FONT>
<BR><FONT SIZE=3D2>> > > step is broken - I'm fooled into =
accepting a certificate from </FONT>
<BR><FONT SIZE=3D2>> > > a phony CA, or </FONT>
<BR><FONT SIZE=3D2>> > > whatever - then the security of the =
entire PKI is shot, and </FONT>
<BR><FONT SIZE=3D2>> > > no X.500 directory </FONT>
<BR><FONT SIZE=3D2>> > > or other mechanism is going to =
help.=A0 Once I have that public </FONT>
<BR><FONT SIZE=3D2>> > > key, though, I </FONT>
<BR><FONT SIZE=3D2>> > > can detect any faked certificates =
based on the trust my CA </FONT>
<BR><FONT SIZE=3D2>> > > has.=A0 My CA will </FONT>
<BR><FONT SIZE=3D2>> > > have cross-certified with the REAL =
VeriSign Class 3 primary </FONT>
<BR><FONT SIZE=3D2>> > > CA (when WHAT </FONT>
<BR><FONT SIZE=3D2>> > > freezes over? :-)=A0=A0 Thus, even if =
I get your phony VeriSign </FONT>
<BR><FONT SIZE=3D2>> > > cert that looks to </FONT>
<BR><FONT SIZE=3D2>> > > be the right one based on the name, I =
can't build a </FONT>
<BR><FONT SIZE=3D2>> > > certification path back to </FONT>
<BR><FONT SIZE=3D2>> > > a node I trust, because my CA or =
whomever else I trust hasn't </FONT>
<BR><FONT SIZE=3D2>> > > signed your </FONT>
<BR><FONT SIZE=3D2>> > > spoof.=A0 I'm protected against your =
spoof by the certificates </FONT>
<BR><FONT SIZE=3D2>> > > and CRLs, not the </FONT>
<BR><FONT SIZE=3D2>> > > distribution mechanism. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > (Of course, if you can trick the =
people I trust - my CA, for </FONT>
<BR><FONT SIZE=3D2>> > > example - into </FONT>
<BR><FONT SIZE=3D2>> > > cross-certifying your fake =
certificate, I'm hosed.=A0 But that </FONT>
<BR><FONT SIZE=3D2>> > > just means that I </FONT>
<BR><FONT SIZE=3D2>> > > trusted some incompetent fool I =
shouldn't have.=A0 A '"secure" </FONT>
<BR><FONT SIZE=3D2>> > > X.500 directory </FONT>
<BR><FONT SIZE=3D2>> > > won't help at all once my CA has =
botched it.) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > =
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Al Arsenault =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > --- standard disclaimer - my own =
opinions; don't reflect </FONT>
<BR><FONT SIZE=3D2>> > > those of my employer </FONT>
<BR><FONT SIZE=3D2>> > > or of any other organization to which =
I may have a </FONT>
<BR><FONT SIZE=3D2>> > > relationship; etc., etc., ad </FONT>
<BR><FONT SIZE=3D2>> > > infinitum, ad nauseum </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > >=A0=A0=A0=A0=A0=A0=A0=A0 </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > At 11:06 AM 10/30/98 +0000, =
GBland@zergo.com wrote: </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > How are you going to do all this =
? </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > The only way I can think of is =
that either you know or have </FONT>
<BR><FONT SIZE=3D2>> > > compromised the </FONT>
<BR><FONT SIZE=3D2>> > > > CA private keys. </FONT>
<BR><FONT SIZE=3D2>> > > > If you know the private =
signature keys then all information </FONT>
<BR><FONT SIZE=3D2>> > > is compromised </FONT>
<BR><FONT SIZE=3D2>> > > > regardless of source. </FONT>
<BR><FONT SIZE=3D2>> > > > If you don't how will you =
construct the Certificates, CRLs, </FONT>
<BR><FONT SIZE=3D2>> > > OCSP responses </FONT>
<BR><FONT SIZE=3D2>> > > > etc. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > This is an attack based on the =
compromise of the CA, not </FONT>
<BR><FONT SIZE=3D2>> > > the security of DNS </FONT>
<BR><FONT SIZE=3D2>> > > > OCSP etc. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > Graham Bland </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > -----Original Message----- =
</FONT>
<BR><FONT SIZE=3D2>> > > > > From: Ron Ramsay </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > [< <<A =
HREF=3D"mailto:Ron.Ramsay@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Ron.Ramsay@OpenDirectory.com.au</A>>> =
</FONT>
<BR><FONT SIZE=3D2>> <<A HREF=3D"mailto:Ron.Ramsay@Ope" =
TARGET=3D"_blank">mailto:Ron.Ramsay@Ope</A>> </FONT>
<BR><FONT SIZE=3D2>> > > nDirectory.c </FONT>
<BR><FONT SIZE=3D2>> > > > om.au] </FONT>
<BR><FONT SIZE=3D2>> > > > > Sent: 30 October 1998 02:42 =
</FONT>
<BR><FONT SIZE=3D2>> > > > > To: 'Phillip M =
Hallam-Baker'; Ron Ramsay; Alan Lloyd </FONT>
<BR><FONT SIZE=3D2>> > > > > Cc: Stephen Kent; =
ietf-pkix@imc.org; Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > > > Subject: RE: Scale (and the =
SRV record) </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Thanks again. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Let me pick up on two =
points. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Firsly, DNS security. If I =
can spoof DNS (which doesn't look </FONT>
<BR><FONT SIZE=3D2>> > > > > to hard) I </FONT>
<BR><FONT SIZE=3D2>> > > > > can provide the address of =
my server in any of the records of </FONT>
<BR><FONT SIZE=3D2>> > > > > interest. </FONT>
<BR><FONT SIZE=3D2>> > > > > A request for your =
certificate will come to my server and </FONT>
<BR><FONT SIZE=3D2>> > > I will send </FONT>
<BR><FONT SIZE=3D2>> > > > > back the certificate that I =
have constructed for you. If </FONT>
<BR><FONT SIZE=3D2>> > > you ask for a </FONT>
<BR><FONT SIZE=3D2>> > > > > CRL I will give you one =
that doesn't name this </FONT>
<BR><FONT SIZE=3D2>> > > certificate. If you </FONT>
<BR><FONT SIZE=3D2>> > > > > choose to use a validation =
service like OCSP that's OK </FONT>
<BR><FONT SIZE=3D2>> > > because I'll </FONT>
<BR><FONT SIZE=3D2>> > > > > return 'valid' for your/my =
certificate. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Denial of service is the =
best bad behaviour you can </FONT>
<BR><FONT SIZE=3D2>> > > expect. Positively </FONT>
<BR><FONT SIZE=3D2>> > > > > helpful service is much =
worse! </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Secondly, you're going to =
send your certificate with the </FONT>
<BR><FONT SIZE=3D2>> > > > > message. Why, I </FONT>
<BR><FONT SIZE=3D2>> > > > > shall do that too! So I'm =
still you! </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > It is interesting you say =
that the worst that can happen </FONT>
<BR><FONT SIZE=3D2>> > > is that you </FONT>
<BR><FONT SIZE=3D2>> > > > > receive a certificate you =
don't trust. How do you know </FONT>
<BR><FONT SIZE=3D2>> > > you don't trust </FONT>
<BR><FONT SIZE=3D2>> > > > > it? I should think if you =
already know what certificates you </FONT>
<BR><FONT SIZE=3D2>> > > > > trust then </FONT>
<BR><FONT SIZE=3D2>> > > > > you don't need PKI at all! =
</FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Ron. </FONT>
<BR><FONT SIZE=3D2>> > > > > > -----Original =
Message----- </FONT>
<BR><FONT SIZE=3D2>> > > > > > =
From:=A0=A0=A0=A0=A0=A0 Phillip M Hallam-Baker </FONT>
<BR><FONT SIZE=3D2>> [SMTP:pbaker@verisign.com] </FONT>
<BR><FONT SIZE=3D2>> > > > > > =
Sent:=A0=A0=A0=A0=A0=A0 Friday, October 30, 1998 2:38 AM </FONT>
<BR><FONT SIZE=3D2>> > > > > > To:Ron Ramsay; Alan =
Lloyd </FONT>
<BR><FONT SIZE=3D2>> > > > > > Cc:Stephen Kent; =
ietf-pkix@imc.org; Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > > > > Subject:=A0=A0=A0 RE: =
Scale (and the SRV record) </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > Thanks for taking =
time to develop the example. </FONT>
<BR><FONT SIZE=3D2>> > > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > Two issues: =
</FONT>
<BR><FONT SIZE=3D2>> > > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > 1. Surely DNS is =
not secure? </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > Define secure? With =
the exception of a denial of </FONT>
<BR><FONT SIZE=3D2>> > > service attack DNS </FONT>
<BR><FONT SIZE=3D2>> > > > > > is 'secure enough' for =
this purpose since there is no </FONT>
<BR><FONT SIZE=3D2>> > > trust placed </FONT>
<BR><FONT SIZE=3D2>> > > > > > on the server. The =
origin of a signed message is </FONT>
<BR><FONT SIZE=3D2>> > > irrelevant. Only </FONT>
<BR><FONT SIZE=3D2>> > > > > > the signature is =
relevant. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > 2. Your example =
seems to be based on encryption using </FONT>
<BR><FONT SIZE=3D2>> > > public keys. </FONT>
<BR><FONT SIZE=3D2>> > > > > > From </FONT>
<BR><FONT SIZE=3D2>> > > > > > > what I know of =
the public key system, it is not used for </FONT>
<BR><FONT SIZE=3D2>> > > > > encryption. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > I think you are =
confusing DNS security here with PKIX. </FONT>
<BR><FONT SIZE=3D2>> > > The two are </FONT>
<BR><FONT SIZE=3D2>> > > > > > very </FONT>
<BR><FONT SIZE=3D2>> > > > > > separate. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > If someone spoofed DNS =
the worst that would happen is </FONT>
<BR><FONT SIZE=3D2>> > > that I would </FONT>
<BR><FONT SIZE=3D2>> > > > > > recieve a certificate =
I didn't trust (and would </FONT>
<BR><FONT SIZE=3D2>> ignore) or no </FONT>
<BR><FONT SIZE=3D2>> > > > > > certificate </FONT>
<BR><FONT SIZE=3D2>> > > > > > at all. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > >Its </FONT>
<BR><FONT SIZE=3D2>> > > > > > > purpose is =
authentication and integrity. To bend your </FONT>
<BR><FONT SIZE=3D2>> > > example, you </FONT>
<BR><FONT SIZE=3D2>> > > > > > will </FONT>
<BR><FONT SIZE=3D2>> > > > > > > be encrypting =
your message with your own private key. </FONT>
<BR><FONT SIZE=3D2>> > > How is an </FONT>
<BR><FONT SIZE=3D2>> > > > > > > addressee to =
verify it was you who sent the message </FONT>
<BR><FONT SIZE=3D2>> > > and that the </FONT>
<BR><FONT SIZE=3D2>> > > > > > message </FONT>
<BR><FONT SIZE=3D2>> > > > > > > was not modified? =
</FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > I send my signing =
certificate with the message. Or once the </FONT>
<BR><FONT SIZE=3D2>> > > > > > infrastructure </FONT>
<BR><FONT SIZE=3D2>> > > > > > is deployed the =
recipient could use the SRV pointer </FONT>
<BR><FONT SIZE=3D2>> to locate a </FONT>
<BR><FONT SIZE=3D2>> > > > > > directory </FONT>
<BR><FONT SIZE=3D2>> > > > > > where a copy of the =
certificate was available. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > >=A0=A0=A0=A0=A0=A0 =
Phill </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE041A.06C29E92--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23838 for ietf-pkix-bks; Fri, 30 Oct 1998 07:21:43 -0800 (PST)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23834 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:21:42 -0800 (PST)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Fri, 30 Oct 1998 15:22:42 +0000
X-Mailer: exmh version 2.0.2 2/24/98
To: Al Arsenault <aarsenault@spyrus.com>
cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Bill Burr'" <william.burr@nist.gov>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
In-reply-to: Your message of "Fri, 30 Oct 1998 09:04:20 EST." <4.1.19981030083342.00a26a10@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 Oct 1998 15:22:28 +0000
Message-ID: <5421.909760948@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al Arsenault writes:
>>
>> Isnt it odd that X.509 is used for PKI and X.500 is discounted?
>>
>
>AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI
business.
>X.509 is not used for its original, X.500-based purpose, which was
actually
>to control access to the directory for the purpose of limiting who
could
>modify entries.
I'm sorry, Al, but it is factually incorrect to say that X.509 is not
used for its original, X.500-based purpose. There is at least one
commercial implementation of X.500 which supports strong authentication
using X.509 certificates, and makes use of the fact for Access Control
purposes.
I'll grant that X.509 is being used beyond its original purpose, but
that's just a measure of its utility.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23827 for ietf-pkix-bks; Fri, 30 Oct 1998 07:20:20 -0800 (PST)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23822 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:20:19 -0800 (PST)
Received: from xedia.com by relay3.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfnir20374; Fri, 30 Oct 1998 10:22:20 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA20684; Fri, 30 Oct 98 10:20:30 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA06562; Fri, 30 Oct 1998 10:22:13 -0500
Date: Fri, 30 Oct 1998 10:22:13 -0500
Message-Id: <199810301522.KAA06562@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Ron.Ramsay@OpenDirectory.com.au
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC0656C6@DSG1>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I continue to be amazed at this thread.
It seems that there's a stream of statements of the form "<disliked
protocol X> is broken because you can open holes by denial of service
attacks on CLRs conveyed by <X>" -- and this is used as an argument
against <X>.
CRLs contain negative statements, so any attack on a CRL turns a
denial of service into a permission of service. That's fundamental in
CRLs, and no fiddling with the underlying directories, transports, or
whatnot will fix this. (Well, maybe if you implement Radia Perlman's
networks with Byzantine robustness you can avoid it.)
paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23785 for ietf-pkix-bks; Fri, 30 Oct 1998 07:16:45 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23781 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:16:44 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA29766; Fri, 30 Oct 1998 07:16:00 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA03205; Fri, 30 Oct 1998 07:18:12 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ron Ramsay" <Ron.Ramsay@OpenDirectory.com.au>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>, "Rick Harvey" <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 10:18:42 -0500
Message-ID: <000701be0418$941ff0c0$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-reply-to: <D1A949D4508DD1119C8100400533BEDC0656C6@DSG1>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Firsly, DNS security. If I can spoof DNS (which doesn't look to hard) I
> can provide the address of my server in any of the records of interest.
> A request for your certificate will come to my server and I will send
> back the certificate that I have constructed for you. If you ask for a
> CRL I will give you one that doesn't name this certificate. If you
> choose to use a validation service like OCSP that's OK because I'll
> return 'valid' for your/my certificate.
But I won't trust the signature on the response.
I think you are overplaying the DNS security issue. Although it is a
concern the routers are also subject to attack. This is the case regardless
of whether they are Internet routers or Telephone switches. People tend
to forget that Kevin Mitick was not primarily a cracker, he was a phone
phreak.
Whether the service is OCSP, LDAP or X.500 is irrelevant. They are
all vulnerable to a DNS spoofing attack when routing packets across
the Internet.
The work in DNSSec is useful and important but it is important to
recognize that it is raising the bar for attacks by forcing them to
take place at a lower level. It does not eliminate the risk of attack.
> Secondly, you're going to send your certificate with the message. Why, I
> shall do that too! So I'm still you!
>
> It is interesting you say that the worst that can happen is that you
> receive a certificate you don't trust. How do you know you don't trust
> it? I should think if you already know what certificates you trust then
> you don't need PKI at all!
? I think that your understanding of PKI appears to be so radically
different from the PKIX model as to be unrelated.
PKIX makes trust decisions on the basis of the CONTENT of the signed
objects alone. If you care how you got the signed objects it isn't
PKIX.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23599 for ietf-pkix-bks; Fri, 30 Oct 1998 06:53:58 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23595 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 06:53:57 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP (peer crosschecked as: [204.254.216.13]) id QQfnip14877; Fri, 30 Oct 1998 09:55:50 -0500 (EST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <V6SF02R2>; Fri, 30 Oct 1998 09:57:02 -0500
Message-ID: <3C7EABA3F6F1D1118FD90008C7F450FDB574E8@exchang-fairfax.pec.com>
From: MHenry <MHenry@pec.com>
To: GBland@zergo.com, aarsenault@spyrus.com, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:57:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA23596
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
al,
interestingly enough, the largest base of existing
pki users (those that have browsers with a hard coded
certs at time of purchase) do, regularly, exactly what you take for
granted they would never do.
semper fi,
mike henry
> -----Original Message-----
> From: GBland@zergo.com [SMTP:GBland@zergo.com]
> Sent: Friday, October 30, 1998 8:41 AM
> To: aarsenault@spyrus.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> I had taken it for granted that nobody would trust a self signed
> certificate without having validated it by either a secure distribution
> mechanism or verification of the hash from a trusted source.
>
> I am pleased to say we are in total agreement.
>
> Graham Bland
>
> > -----Original Message-----
> > From: Al Arsenault [ <mailto:aarsenault@spyrus.com>]
> > Sent: 30 October 1998 13:29
> > To: GBland@zergo.com; ietf-pkix@imc.org
> > Subject: RE: Scale (and the SRV record)
> >
> >
> > Since I agree with most of what Phill has to say on this
> > topic, I'll go against
> > my better judgement and jump in here.
> >
> > If I'm understanding this correctly, the attack of concern is
> > as follows:
> > Nothing today stops me from cobbling together my own
> > certificate-generating and
> > -signing software, and then generating a self-signed
> > certificate for user "US
> > Verisign Primary Class 3 Public Certificate Authority" (or
> > whatever the magic
> > string is that will exactly match what VeriSign uses). This
> > new certificate
> > will use the public key corresponding to a private key that I
> > know, rather than
> > the one that VeriSign actually uses. (This ignores the
> > scenario described by
> > Graham, in which I've managed to obtain VeriSign's private key.)
> >
> > Given this, can I get you, the unsuspecting user, to use MY
> > certificate (and
> > any user certificates I then issue with it) instead of the
> > real one? After
> > all, once you've retrieved the certificate, the DN or
> > subjectAltName field will
> > LOOK "right" to you, if you bother to check it. The argument
> > has been that
> > given an insecure, spoofable, distribution mechanism, I might
> > be able to fool
> > you into using the wrong "VeriSign certificate". If, for
> > example, I can spoof
> > DNS and make you think that the IP address corresponding to
> > "VeriSign.com" is,
> > say, 130.85.1.3, and I control that machine (note: I don't
> > :-) then you'll go
> > there for the "real certificate" and I've got you. So, to
> > counter that, you
> > need a "secure" distribution mechanism.
> >
> > I frankly don't buy that argument, though. What is required
> > in a PKI is that I
> > somehow securely obtain the certificate/public key of a CA
> > that I have chosen
> > to trust - normally, that's the one that issued my
> > certificate. If this first
> > step is broken - I'm fooled into accepting a certificate from
> > a phony CA, or
> > whatever - then the security of the entire PKI is shot, and
> > no X.500 directory
> > or other mechanism is going to help. Once I have that public
> > key, though, I
> > can detect any faked certificates based on the trust my CA
> > has. My CA will
> > have cross-certified with the REAL VeriSign Class 3 primary
> > CA (when WHAT
> > freezes over? :-) Thus, even if I get your phony VeriSign
> > cert that looks to
> > be the right one based on the name, I can't build a
> > certification path back to
> > a node I trust, because my CA or whomever else I trust hasn't
> > signed your
> > spoof. I'm protected against your spoof by the certificates
> > and CRLs, not the
> > distribution mechanism.
> >
> > (Of course, if you can trick the people I trust - my CA, for
> > example - into
> > cross-certifying your fake certificate, I'm hosed. But that
> > just means that I
> > trusted some incompetent fool I shouldn't have. A '"secure"
> > X.500 directory
> > won't help at all once my CA has botched it.)
> >
> >
> >
> >
> >
> > Al Arsenault
> >
> > --- standard disclaimer - my own opinions; don't reflect
> > those of my employer
> > or of any other organization to which I may have a
> > relationship; etc., etc., ad
> > infinitum, ad nauseum
> >
> >
> >
> >
> >
> > At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
> >
> > >
> > > How are you going to do all this ?
> > >
> > > The only way I can think of is that either you know or have
> > compromised the
> > > CA private keys.
> > > If you know the private signature keys then all information
> > is compromised
> > > regardless of source.
> > > If you don't how will you construct the Certificates, CRLs,
> > OCSP responses
> > > etc.
> > >
> > > This is an attack based on the compromise of the CA, not
> > the security of DNS
> > > OCSP etc.
> > >
> > > Graham Bland
> > >
> > > > -----Original Message-----
> > > > From: Ron Ramsay
> > >
> > [< <mailto:Ron.Ramsay@OpenDirectory.com.au>> <mailto:Ron.Ramsay@Ope>
> > nDirectory.c
> > > om.au]
> > > > Sent: 30 October 1998 02:42
> > > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > Subject: RE: Scale (and the SRV record)
> > > >
> > > >
> > > > Phillip,
> > > >
> > > > Thanks again.
> > > >
> > > > Let me pick up on two points.
> > > >
> > > > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > > > to hard) I
> > > > can provide the address of my server in any of the records of
> > > > interest.
> > > > A request for your certificate will come to my server and
> > I will send
> > > > back the certificate that I have constructed for you. If
> > you ask for a
> > > > CRL I will give you one that doesn't name this
> > certificate. If you
> > > > choose to use a validation service like OCSP that's OK
> > because I'll
> > > > return 'valid' for your/my certificate.
> > > >
> > > > Denial of service is the best bad behaviour you can
> > expect. Positively
> > > > helpful service is much worse!
> > > >
> > > > Secondly, you're going to send your certificate with the
> > > > message. Why, I
> > > > shall do that too! So I'm still you!
> > > >
> > > > It is interesting you say that the worst that can happen
> > is that you
> > > > receive a certificate you don't trust. How do you know
> > you don't trust
> > > > it? I should think if you already know what certificates you
> > > > trust then
> > > > you don't need PKI at all!
> > > >
> > > > Ron.
> > > > > -----Original Message-----
> > > > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > > > Sent: Friday, October 30, 1998 2:38 AM
> > > > > To:Ron Ramsay; Alan Lloyd
> > > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > > Subject: RE: Scale (and the SRV record)
> > > > >
> > > > >
> > > > >
> > > > > > Phillip,
> > > > > >
> > > > > > Thanks for taking time to develop the example.
> > > > > >
> > > > > > Two issues:
> > > > > >
> > > > > > 1. Surely DNS is not secure?
> > > > >
> > > > > Define secure? With the exception of a denial of
> > service attack DNS
> > > > > is 'secure enough' for this purpose since there is no
> > trust placed
> > > > > on the server. The origin of a signed message is
> > irrelevant. Only
> > > > > the signature is relevant.
> > > > >
> > > > > > 2. Your example seems to be based on encryption using
> > public keys.
> > > > > From
> > > > > > what I know of the public key system, it is not used for
> > > > encryption.
> > > > >
> > > > >
> > > > > I think you are confusing DNS security here with PKIX.
> > The two are
> > > > > very
> > > > > separate.
> > > > >
> > > > > If someone spoofed DNS the worst that would happen is
> > that I would
> > > > > recieve a certificate I didn't trust (and would ignore) or no
> > > > > certificate
> > > > > at all.
> > > > >
> > > > > >Its
> > > > > > purpose is authentication and integrity. To bend your
> > example, you
> > > > > will
> > > > > > be encrypting your message with your own private key.
> > How is an
> > > > > > addressee to verify it was you who sent the message
> > and that the
> > > > > message
> > > > > > was not modified?
> > > > >
> > > > > I send my signing certificate with the message. Or once the
> > > > > infrastructure
> > > > > is deployed the recipient could use the SRV pointer to locate a
> > > > > directory
> > > > > where a copy of the certificate was available.
> > > > >
> > > > > Phill
> > > >
> >
> >
> >
> >
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23409 for ietf-pkix-bks; Fri, 30 Oct 1998 06:24:03 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23405 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 06:24:01 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP (peer crosschecked as: [204.254.216.13]) id QQfnin28918; Fri, 30 Oct 1998 09:25:46 -0500 (EST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <V6SF02MH>; Fri, 30 Oct 1998 09:26:57 -0500
Message-ID: <3C7EABA3F6F1D1118FD90008C7F450FDA65C34@exchang-fairfax.pec.com>
From: WHenry <WHenry@pec.com>
To: "'Al Arsenault'" <aarsenault@spyrus.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:26:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All:
Al Arsenault said:
"What is required in a PKI is that I somehow securely obtain the
certificate/public key of a CA that I have chosen to trust - normally,
that's the one that issued my certificate. If this first
step is broken - I'm fooled into accepting a certificate from a phony CA, or
whatever - then the security of the entire PKI is shot, and no X.500
directory
or other mechanism is going to help."
I couldn't agree more! This is precisely the reason why CA certs that come
embedded in my browser are, from a trust standpoint, worthless.
-Bill Henry
> -----Original Message-----
> From: Al Arsenault [SMTP:aarsenault@spyrus.com]
> Sent: Friday, October 30, 1998 8:29 AM
> To: GBland@zergo.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> Since I agree with most of what Phill has to say on this topic, I'll go
> against
> my better judgement and jump in here.
>
> If I'm understanding this correctly, the attack of concern is as follows:
> Nothing today stops me from cobbling together my own
> certificate-generating and
> -signing software, and then generating a self-signed certificate for user
> "US
> Verisign Primary Class 3 Public Certificate Authority" (or whatever the
> magic
> string is that will exactly match what VeriSign uses). This new
> certificate
> will use the public key corresponding to a private key that I know, rather
> than
> the one that VeriSign actually uses. (This ignores the scenario described
> by
> Graham, in which I've managed to obtain VeriSign's private key.)
>
> Given this, can I get you, the unsuspecting user, to use MY certificate
> (and
> any user certificates I then issue with it) instead of the real one?
> After
> all, once you've retrieved the certificate, the DN or subjectAltName field
> will
> LOOK "right" to you, if you bother to check it. The argument has been
> that
> given an insecure, spoofable, distribution mechanism, I might be able to
> fool
> you into using the wrong "VeriSign certificate". If, for example, I can
> spoof
> DNS and make you think that the IP address corresponding to "VeriSign.com"
> is,
> say, 130.85.1.3, and I control that machine (note: I don't :-) then
> you'll go
> there for the "real certificate" and I've got you. So, to counter that,
> you
> need a "secure" distribution mechanism.
>
> I frankly don't buy that argument, though. What is required in a PKI is
> that I
> somehow securely obtain the certificate/public key of a CA that I have
> chosen
> to trust - normally, that's the one that issued my certificate. If this
> first
> step is broken - I'm fooled into accepting a certificate from a phony CA,
> or
> whatever - then the security of the entire PKI is shot, and no X.500
> directory
> or other mechanism is going to help. Once I have that public key, though,
> I
> can detect any faked certificates based on the trust my CA has. My CA
> will
> have cross-certified with the REAL VeriSign Class 3 primary CA (when WHAT
> freezes over? :-) Thus, even if I get your phony VeriSign cert that
> looks to
> be the right one based on the name, I can't build a certification path
> back to
> a node I trust, because my CA or whomever else I trust hasn't signed your
> spoof. I'm protected against your spoof by the certificates and CRLs, not
> the
> distribution mechanism.
>
> (Of course, if you can trick the people I trust - my CA, for example -
> into
> cross-certifying your fake certificate, I'm hosed. But that just means
> that I
> trusted some incompetent fool I shouldn't have. A '"secure" X.500
> directory
> won't help at all once my CA has botched it.)
>
>
>
>
>
> Al Arsenault
>
> --- standard disclaimer - my own opinions; don't reflect those of my
> employer
> or of any other organization to which I may have a relationship; etc.,
> etc., ad
> infinitum, ad nauseum
>
>
>
>
>
> At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
>
> >
> > How are you going to do all this ?
> >
> > The only way I can think of is that either you know or have compromised
> the
> > CA private keys.
> > If you know the private signature keys then all information is
> compromised
> > regardless of source.
> > If you don't how will you construct the Certificates, CRLs, OCSP
> responses
> > etc.
> >
> > This is an attack based on the compromise of the CA, not the security of
> DNS
> > OCSP etc.
> >
> > Graham Bland
> >
> > > -----Original Message-----
> > > From: Ron Ramsay
> >
> [<mailto:Ron.Ramsay@OpenDirectory.com.au>mailto:Ron.Ramsay@OpenDirectory.c
> > om.au]
> > > Sent: 30 October 1998 02:42
> > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > Subject: RE: Scale (and the SRV record)
> > >
> > >
> > > Phillip,
> > >
> > > Thanks again.
> > >
> > > Let me pick up on two points.
> > >
> > > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > > to hard) I
> > > can provide the address of my server in any of the records of
> > > interest.
> > > A request for your certificate will come to my server and I will send
> > > back the certificate that I have constructed for you. If you ask for a
>
> > > CRL I will give you one that doesn't name this certificate. If you
> > > choose to use a validation service like OCSP that's OK because I'll
> > > return 'valid' for your/my certificate.
> > >
> > > Denial of service is the best bad behaviour you can expect. Positively
>
> > > helpful service is much worse!
> > >
> > > Secondly, you're going to send your certificate with the
> > > message. Why, I
> > > shall do that too! So I'm still you!
> > >
> > > It is interesting you say that the worst that can happen is that you
> > > receive a certificate you don't trust. How do you know you don't trust
>
> > > it? I should think if you already know what certificates you
> > > trust then
> > > you don't need PKI at all!
> > >
> > > Ron.
> > > > -----Original Message-----
> > > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > > Sent: Friday, October 30, 1998 2:38 AM
> > > > To:Ron Ramsay; Alan Lloyd
> > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > Subject: RE: Scale (and the SRV record)
> > > >
> > > >
> > > >
> > > > > Phillip,
> > > > >
> > > > > Thanks for taking time to develop the example.
> > > > >
> > > > > Two issues:
> > > > >
> > > > > 1. Surely DNS is not secure?
> > > >
> > > > Define secure? With the exception of a denial of service attack DNS
> > > > is 'secure enough' for this purpose since there is no trust placed
> > > > on the server. The origin of a signed message is irrelevant. Only
> > > > the signature is relevant.
> > > >
> > > > > 2. Your example seems to be based on encryption using public keys.
>
> > > > From
> > > > > what I know of the public key system, it is not used for
> > > encryption.
> > > >
> > > >
> > > > I think you are confusing DNS security here with PKIX. The two are
> > > > very
> > > > separate.
> > > >
> > > > If someone spoofed DNS the worst that would happen is that I would
> > > > recieve a certificate I didn't trust (and would ignore) or no
> > > > certificate
> > > > at all.
> > > >
> > > > >Its
> > > > > purpose is authentication and integrity. To bend your example, you
>
> > > > will
> > > > > be encrypting your message with your own private key. How is an
> > > > > addressee to verify it was you who sent the message and that the
> > > > message
> > > > > was not modified?
> > > >
> > > > I send my signing certificate with the message. Or once the
> > > > infrastructure
> > > > is deployed the recipient could use the SRV pointer to locate a
> > > > directory
> > > > where a copy of the certificate was available.
> > > >
> > > > Phill
> > >
>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23284 for ietf-pkix-bks; Fri, 30 Oct 1998 06:07:53 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23280 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 06:07:53 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA09170; Fri, 30 Oct 1998 06:09:21 -0800 (PST)
Message-Id: <4.1.19981030083342.00a26a10@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 09:04:20 -0500
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Bill Burr'" <william.burr@nist.gov>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
From: Al Arsenault <aarsenault@spyrus.com>
Subject: A PKI for the Internet (was RE: Scale (and the SRV record))
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I tend to agree with Bill Burr on this one. Phill's proposal makes a lot of
sense, as long as we're willing to understand its limits. If we're building
a PKI for the Internet (supposedly, that's PKIX's charter), then it is is
wholly appropriate to think in terms of the Internet paradigm. I have no
problem with names of entities being based on Internet things like domain
names, IP addresses, etc.
This is one of the areas where the SPKI folk make sense. There is not, and
will not ever be, a single, unified, global directory where everything has
a name that fits into the schema. There are instead "directories" of
information that apply to a specific "domain". In PKIX's case, it's the
information that applies to the Internet. The namespace covers those
things that are important in the Internet context, and nothing else. To
me, that's (right now), IP addresses, domain names, port numbers, service
names, user names/mailbox names, and maybe one or two other things. If the
Internet expands to cover toll plazas, then a naming space will have to be
developed for them, and after it's defined and standardized we can figure
out how to put the proper names in certificates.
(You can learn more about my views on this by reading the "naming" section
of the Roadmap document. If you think it's wrong, please let Sean and/or
me know.)
Now, a few specific comments:
<Snip>
>> I think that we would want to think very hard about basing PKI names
>> on
>> domain names. It seems desirable to make names in certificates more
>> directly related to the "real world" than domain names and e-mail
>> addresses
>> often seem to be. But, if we are dong a PKI for the Internet (and
>> isn't
>> this what PKIX is about?), then domain names and the DNS are the
>> foundation
>> that we build the whole Internet on anyhow.
> [Alan Lloyd]
> The Internet has many layers in my book. The physical layer and
>Lans and things, the Internet layer, the domain layer for machine based
>names, and the application layer. DNS deals with Internet addresses and
>Domains. Its history that domains relate to organisations. However, as
>applications over the Internet evolve, then the higher level naming
>constructs relate to real life. Ie. I have a name of Alan, but I may get
>services from many internet domains eg Ozemail, Compuserve, MSN, etc. I
>dont want 10 names because I use 10 domain based services.
>
AWA: I disagree. Last time I counted closely, I had at least six
different Internet access points, in at least five different domains. I
use them for different purposes - one for working on this job; one for
working on this other thing; one for my use at home; one for shared use
with my children; etc. I want them to have different names and different
certificates, with rights/limits/policies that reflect what I use them for.
That's the way things work in real life.
That's what I like about using the existing Internet paradigms for cert
names, etc. The account I let my children use is one that only allows
text-based e-mail, for example. Picture attachments don't work; that's the
way the provider sets it up. Thus, I'm not as worried about spam with
offensive pictures showing up in the mailbox - if such a message does make
it through, it won't be rendered as an image without massive human
intervention. I'd like a certificate for this account that reflects its
capabilities and uses - e.g., since I don't use it for on-line purchases, a
certificate should have a financial limit of 0; and a low trust level. For
other accounts, I'd like more "powerful" certificates.
I'm one of those people who think that the "ideal world" painted by some
(like, some of the DII designers) of one certificate per person is simply
wrong. It may make their system design easier, but it doesn't reflect the
real world. I want different certificates for the different things I do,
just like I have different physical pieces of identification for different
purposes. Following an Internet paradigm is a good thing - just as I have
those different e-mail addresses and different service providers, I'd like
different certificates that match them.
>> If the car, or perhaps the toll road operator, in your toll plaza
>> example,
>> doesn't have a domain name, or an IP address, why is it the concern of
>> PKIX, which is, after all, an Internet standard group. Is it even
>> appropriate for the PKIX group to worry about things that don't relate
>> to
>> the Internet?
> [Alan Lloyd] Thats a view. I tend to think that the Internet
>and Internet style technologies get used where they can. So why not
>build things with the widest capability. Thats what the market wants.
>
AWA: I disagree that that's what the "market wants". Some people do, but
many share my views about separation (at least I think many do. I'm
willing to be corrected.)
>
>> Until now, I have also been saying, does anybody have a believable
>> alternative to the mythological, pervasive X.500 directory service?
>> It
>> seemed almost a rhetorical question. But I think perhaps Phill has
>> outlined an alternative, that looks like it probably ought to work,
>> and is
>> based on something, DNS, that we know works well, scales well, and
>> exists
>> now. Moreover, we should be able to create the service we need
>> incrementally, by just by adding servers as we need them, one at a
>> time.
>> And, If I understand the proposal, all we have to do is agree on some
>> simple naming conventions.
> [Alan Lloyd] I am not against alternative proposals - its all a
>question of how much effort and implementation goes behind it. Phills
>solution has to be backed by all the DNS and PKI suppliers on this
>planet and DNS then has to become secure - with signed operations,
>mutual authentication, access controls, real life naming, and scale a
>lot better and of course be easy to manage and follow Object Oriented
>design. (does this mean turning DNS into X.500?) I would vote for that -
>thats more X.500!
>
AWA: I disagre with these assertions. DNS does not need to be secure,
unless what you're trying to stop is the denial of service problem. If
you're implementing the PKI properly, you can't get fooled into using the
wrong certificate just because DNS is defeated; the worst that will happen
is that you can't get the real certificate or CRL. I'll post another
transaction today that explains my views on that in more detail. (Yes, I
agree with those who argue that a denial of service problem that prevents
you from getting the current CRL can lead to a violation of confidentiality
or integrity, because you won't know that a key has been compromised. The
threat also applies to OCSP services, unless you're operating in a mode
where "no response from the OCSP responder means reject everything".)
>
> Isnt it odd that X.509 is used for PKI and X.500 is discounted?
>
AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI business.
X.509 is not used for its original, X.500-based purpose, which was actually
to control access to the directory for the purpose of limiting who could
modify entries. We - the PKI community - needed a common terminology to
express things. The X.509 syntax existed and seemed to be reasonably well
understood, and thus was adopted. We could have easily gone down a SPKI
path and invented "S expressions" or some other similar thing, but that
seemed to be a waste of time.
Al Arsenault
-- my opinions only; no employer endorsement implied; etc., etc., etc.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23133 for ietf-pkix-bks; Fri, 30 Oct 1998 05:41:26 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23129 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 05:41:20 -0800 (PST)
From: GBland@zergo.com
Message-Id: <199810301509.PAA22673@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
To: aarsenault@spyrus.com, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 13:41:01 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE040A.EF04FF3E"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE040A.EF04FF3E
Content-Type: text/plain;
charset="iso-8859-1"
I had taken it for granted that nobody would trust a self signed
certificate without having validated it by either a secure distribution
mechanism or verification of the hash from a trusted source.
I am pleased to say we are in total agreement.
Graham Bland
> -----Original Message-----
> From: Al Arsenault [mailto:aarsenault@spyrus.com]
> Sent: 30 October 1998 13:29
> To: GBland@zergo.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
>
> Since I agree with most of what Phill has to say on this
> topic, I'll go against
> my better judgement and jump in here.
>
> If I'm understanding this correctly, the attack of concern is
> as follows:
> Nothing today stops me from cobbling together my own
> certificate-generating and
> -signing software, and then generating a self-signed
> certificate for user "US
> Verisign Primary Class 3 Public Certificate Authority" (or
> whatever the magic
> string is that will exactly match what VeriSign uses). This
> new certificate
> will use the public key corresponding to a private key that I
> know, rather than
> the one that VeriSign actually uses. (This ignores the
> scenario described by
> Graham, in which I've managed to obtain VeriSign's private key.)
>
> Given this, can I get you, the unsuspecting user, to use MY
> certificate (and
> any user certificates I then issue with it) instead of the
> real one? After
> all, once you've retrieved the certificate, the DN or
> subjectAltName field will
> LOOK "right" to you, if you bother to check it. The argument
> has been that
> given an insecure, spoofable, distribution mechanism, I might
> be able to fool
> you into using the wrong "VeriSign certificate". If, for
> example, I can spoof
> DNS and make you think that the IP address corresponding to
> "VeriSign.com" is,
> say, 130.85.1.3, and I control that machine (note: I don't
> :-) then you'll go
> there for the "real certificate" and I've got you. So, to
> counter that, you
> need a "secure" distribution mechanism.
>
> I frankly don't buy that argument, though. What is required
> in a PKI is that I
> somehow securely obtain the certificate/public key of a CA
> that I have chosen
> to trust - normally, that's the one that issued my
> certificate. If this first
> step is broken - I'm fooled into accepting a certificate from
> a phony CA, or
> whatever - then the security of the entire PKI is shot, and
> no X.500 directory
> or other mechanism is going to help. Once I have that public
> key, though, I
> can detect any faked certificates based on the trust my CA
> has. My CA will
> have cross-certified with the REAL VeriSign Class 3 primary
> CA (when WHAT
> freezes over? :-) Thus, even if I get your phony VeriSign
> cert that looks to
> be the right one based on the name, I can't build a
> certification path back to
> a node I trust, because my CA or whomever else I trust hasn't
> signed your
> spoof. I'm protected against your spoof by the certificates
> and CRLs, not the
> distribution mechanism.
>
> (Of course, if you can trick the people I trust - my CA, for
> example - into
> cross-certifying your fake certificate, I'm hosed. But that
> just means that I
> trusted some incompetent fool I shouldn't have. A '"secure"
> X.500 directory
> won't help at all once my CA has botched it.)
>
>
>
>
>
> Al Arsenault
>
> --- standard disclaimer - my own opinions; don't reflect
> those of my employer
> or of any other organization to which I may have a
> relationship; etc., etc., ad
> infinitum, ad nauseum
>
>
>
>
>
> At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
>
> >
> > How are you going to do all this ?
> >
> > The only way I can think of is that either you know or have
> compromised the
> > CA private keys.
> > If you know the private signature keys then all information
> is compromised
> > regardless of source.
> > If you don't how will you construct the Certificates, CRLs,
> OCSP responses
> > etc.
> >
> > This is an attack based on the compromise of the CA, not
> the security of DNS
> > OCSP etc.
> >
> > Graham Bland
> >
> > > -----Original Message-----
> > > From: Ron Ramsay
> >
> [<mailto:Ron.Ramsay@OpenDirectory.com.au>mailto:Ron.Ramsay@Ope
> nDirectory.c
> > om.au]
> > > Sent: 30 October 1998 02:42
> > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > Subject: RE: Scale (and the SRV record)
> > >
> > >
> > > Phillip,
> > >
> > > Thanks again.
> > >
> > > Let me pick up on two points.
> > >
> > > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > > to hard) I
> > > can provide the address of my server in any of the records of
> > > interest.
> > > A request for your certificate will come to my server and
> I will send
> > > back the certificate that I have constructed for you. If
> you ask for a
> > > CRL I will give you one that doesn't name this
> certificate. If you
> > > choose to use a validation service like OCSP that's OK
> because I'll
> > > return 'valid' for your/my certificate.
> > >
> > > Denial of service is the best bad behaviour you can
> expect. Positively
> > > helpful service is much worse!
> > >
> > > Secondly, you're going to send your certificate with the
> > > message. Why, I
> > > shall do that too! So I'm still you!
> > >
> > > It is interesting you say that the worst that can happen
> is that you
> > > receive a certificate you don't trust. How do you know
> you don't trust
> > > it? I should think if you already know what certificates you
> > > trust then
> > > you don't need PKI at all!
> > >
> > > Ron.
> > > > -----Original Message-----
> > > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > > Sent: Friday, October 30, 1998 2:38 AM
> > > > To:Ron Ramsay; Alan Lloyd
> > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > Subject: RE: Scale (and the SRV record)
> > > >
> > > >
> > > >
> > > > > Phillip,
> > > > >
> > > > > Thanks for taking time to develop the example.
> > > > >
> > > > > Two issues:
> > > > >
> > > > > 1. Surely DNS is not secure?
> > > >
> > > > Define secure? With the exception of a denial of
> service attack DNS
> > > > is 'secure enough' for this purpose since there is no
> trust placed
> > > > on the server. The origin of a signed message is
> irrelevant. Only
> > > > the signature is relevant.
> > > >
> > > > > 2. Your example seems to be based on encryption using
> public keys.
> > > > From
> > > > > what I know of the public key system, it is not used for
> > > encryption.
> > > >
> > > >
> > > > I think you are confusing DNS security here with PKIX.
> The two are
> > > > very
> > > > separate.
> > > >
> > > > If someone spoofed DNS the worst that would happen is
> that I would
> > > > recieve a certificate I didn't trust (and would ignore) or no
> > > > certificate
> > > > at all.
> > > >
> > > > >Its
> > > > > purpose is authentication and integrity. To bend your
> example, you
> > > > will
> > > > > be encrypting your message with your own private key.
> How is an
> > > > > addressee to verify it was you who sent the message
> and that the
> > > > message
> > > > > was not modified?
> > > >
> > > > I send my signing certificate with the message. Or once the
> > > > infrastructure
> > > > is deployed the recipient could use the SRV pointer to locate a
> > > > directory
> > > > where a copy of the certificate was available.
> > > >
> > > > Phill
> > >
>
>
>
>
------ =_NextPart_001_01BE040A.EF04FF3E
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I had taken it for granted that nobody would trust a =
self signed certificate without having validated it by either a secure =
distribution mechanism or verification of the hash from a trusted =
source.</FONT></P>
<P><FONT SIZE=3D2>I am pleased to say we are in total agreement.</FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Al Arsenault [<A =
HREF=3D"mailto:aarsenault@spyrus.com" =
TARGET=3D"_blank">mailto:aarsenault@spyrus.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 30 October 1998 13:29</FONT>
<BR><FONT SIZE=3D2>> To: GBland@zergo.com; ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Since I agree with most of what Phill has to =
say on this </FONT>
<BR><FONT SIZE=3D2>> topic, I'll go against</FONT>
<BR><FONT SIZE=3D2>> my better judgement and jump in here.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If I'm understanding this correctly, the attack =
of concern is </FONT>
<BR><FONT SIZE=3D2>> as follows:</FONT>
<BR><FONT SIZE=3D2>> Nothing today stops me from cobbling together =
my own </FONT>
<BR><FONT SIZE=3D2>> certificate-generating and</FONT>
<BR><FONT SIZE=3D2>> -signing software, and then generating a =
self-signed </FONT>
<BR><FONT SIZE=3D2>> certificate for user "US</FONT>
<BR><FONT SIZE=3D2>> Verisign Primary Class 3 Public Certificate =
Authority" (or </FONT>
<BR><FONT SIZE=3D2>> whatever the magic</FONT>
<BR><FONT SIZE=3D2>> string is that will exactly match what VeriSign =
uses). This </FONT>
<BR><FONT SIZE=3D2>> new certificate</FONT>
<BR><FONT SIZE=3D2>> will use the public key corresponding to a =
private key that I </FONT>
<BR><FONT SIZE=3D2>> know, rather than</FONT>
<BR><FONT SIZE=3D2>> the one that VeriSign actually uses. =
(This ignores the </FONT>
<BR><FONT SIZE=3D2>> scenario described by</FONT>
<BR><FONT SIZE=3D2>> Graham, in which I've managed to obtain =
VeriSign's private key.)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Given this, can I get you, the unsuspecting =
user, to use MY </FONT>
<BR><FONT SIZE=3D2>> certificate (and</FONT>
<BR><FONT SIZE=3D2>> any user certificates I then issue with it) =
instead of the </FONT>
<BR><FONT SIZE=3D2>> real one? After</FONT>
<BR><FONT SIZE=3D2>> all, once you've retrieved the certificate, the =
DN or </FONT>
<BR><FONT SIZE=3D2>> subjectAltName field will</FONT>
<BR><FONT SIZE=3D2>> LOOK "right" to you, if you bother to =
check it. The argument </FONT>
<BR><FONT SIZE=3D2>> has been that</FONT>
<BR><FONT SIZE=3D2>> given an insecure, spoofable, distribution =
mechanism, I might </FONT>
<BR><FONT SIZE=3D2>> be able to fool</FONT>
<BR><FONT SIZE=3D2>> you into using the wrong "VeriSign =
certificate". If, for </FONT>
<BR><FONT SIZE=3D2>> example, I can spoof</FONT>
<BR><FONT SIZE=3D2>> DNS and make you think that the IP address =
corresponding to </FONT>
<BR><FONT SIZE=3D2>> "VeriSign.com" is,</FONT>
<BR><FONT SIZE=3D2>> say, 130.85.1.3, and I control that =
machine (note: I don't </FONT>
<BR><FONT SIZE=3D2>> :-) then you'll go</FONT>
<BR><FONT SIZE=3D2>> there for the "real certificate" and =
I've got you. So, to </FONT>
<BR><FONT SIZE=3D2>> counter that, you</FONT>
<BR><FONT SIZE=3D2>> need a "secure" distribution =
mechanism.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I frankly don't buy that argument, =
though. What is required </FONT>
<BR><FONT SIZE=3D2>> in a PKI is that I</FONT>
<BR><FONT SIZE=3D2>> somehow securely obtain the certificate/public =
key of a CA </FONT>
<BR><FONT SIZE=3D2>> that I have chosen</FONT>
<BR><FONT SIZE=3D2>> to trust - normally, that's the one that issued =
my </FONT>
<BR><FONT SIZE=3D2>> certificate. If this first</FONT>
<BR><FONT SIZE=3D2>> step is broken - I'm fooled into accepting a =
certificate from </FONT>
<BR><FONT SIZE=3D2>> a phony CA, or</FONT>
<BR><FONT SIZE=3D2>> whatever - then the security of the entire PKI =
is shot, and </FONT>
<BR><FONT SIZE=3D2>> no X.500 directory</FONT>
<BR><FONT SIZE=3D2>> or other mechanism is going to help. Once =
I have that public </FONT>
<BR><FONT SIZE=3D2>> key, though, I</FONT>
<BR><FONT SIZE=3D2>> can detect any faked certificates based on the =
trust my CA </FONT>
<BR><FONT SIZE=3D2>> has. My CA will</FONT>
<BR><FONT SIZE=3D2>> have cross-certified with the REAL VeriSign =
Class 3 primary </FONT>
<BR><FONT SIZE=3D2>> CA (when WHAT</FONT>
<BR><FONT SIZE=3D2>> freezes over? :-) Thus, even if I =
get your phony VeriSign </FONT>
<BR><FONT SIZE=3D2>> cert that looks to</FONT>
<BR><FONT SIZE=3D2>> be the right one based on the name, I can't =
build a </FONT>
<BR><FONT SIZE=3D2>> certification path back to</FONT>
<BR><FONT SIZE=3D2>> a node I trust, because my CA or whomever else =
I trust hasn't </FONT>
<BR><FONT SIZE=3D2>> signed your</FONT>
<BR><FONT SIZE=3D2>> spoof. I'm protected against your spoof =
by the certificates </FONT>
<BR><FONT SIZE=3D2>> and CRLs, not the</FONT>
<BR><FONT SIZE=3D2>> distribution mechanism.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> (Of course, if you can trick the people I trust =
- my CA, for </FONT>
<BR><FONT SIZE=3D2>> example - into</FONT>
<BR><FONT SIZE=3D2>> cross-certifying your fake certificate, I'm =
hosed. But that </FONT>
<BR><FONT SIZE=3D2>> just means that I</FONT>
<BR><FONT SIZE=3D2>> trusted some incompetent fool I shouldn't =
have. A '"secure" </FONT>
<BR><FONT SIZE=3D2>> X.500 directory</FONT>
<BR><FONT SIZE=3D2>> won't help at all once my CA has botched =
it.)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
;  =
; Al Arsenault</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> --- standard disclaimer - my own opinions; =
don't reflect </FONT>
<BR><FONT SIZE=3D2>> those of my employer</FONT>
<BR><FONT SIZE=3D2>> or of any other organization to which I may =
have a </FONT>
<BR><FONT SIZE=3D2>> relationship; etc., etc., ad</FONT>
<BR><FONT SIZE=3D2>> infinitum, ad nauseum</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At 11:06 AM 10/30/98 +0000, GBland@zergo.com =
wrote: </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > How are you going to do all this ? </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > The only way I can think of is that either =
you know or have </FONT>
<BR><FONT SIZE=3D2>> compromised the</FONT>
<BR><FONT SIZE=3D2>> > CA private keys. </FONT>
<BR><FONT SIZE=3D2>> > If you know the private signature keys =
then all information </FONT>
<BR><FONT SIZE=3D2>> is compromised</FONT>
<BR><FONT SIZE=3D2>> > regardless of source. </FONT>
<BR><FONT SIZE=3D2>> > If you don't how will you construct the =
Certificates, CRLs, </FONT>
<BR><FONT SIZE=3D2>> OCSP responses</FONT>
<BR><FONT SIZE=3D2>> > etc. </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > This is an attack based on the compromise =
of the CA, not </FONT>
<BR><FONT SIZE=3D2>> the security of DNS</FONT>
<BR><FONT SIZE=3D2>> > OCSP etc. </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > Graham Bland </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > > -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>> > > From: Ron Ramsay</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> [<<A =
HREF=3D"mailto:Ron.Ramsay@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Ron.Ramsay@OpenDirectory.com.au</A>><A =
HREF=3D"mailto:Ron.Ramsay@Ope" =
TARGET=3D"_blank">mailto:Ron.Ramsay@Ope</A></FONT>
<BR><FONT SIZE=3D2>> nDirectory.c</FONT>
<BR><FONT SIZE=3D2>> > om.au] </FONT>
<BR><FONT SIZE=3D2>> > > Sent: 30 October 1998 02:42 </FONT>
<BR><FONT SIZE=3D2>> > > To: 'Phillip M Hallam-Baker'; Ron =
Ramsay; Alan Lloyd </FONT>
<BR><FONT SIZE=3D2>> > > Cc: Stephen Kent; ietf-pkix@imc.org; =
Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > Subject: RE: Scale (and the SRV =
record) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Thanks again. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Let me pick up on two points. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Firsly, DNS security. If I can spoof =
DNS (which doesn't look </FONT>
<BR><FONT SIZE=3D2>> > > to hard) I </FONT>
<BR><FONT SIZE=3D2>> > > can provide the address of my server =
in any of the records of </FONT>
<BR><FONT SIZE=3D2>> > > interest. </FONT>
<BR><FONT SIZE=3D2>> > > A request for your certificate will =
come to my server and </FONT>
<BR><FONT SIZE=3D2>> I will send </FONT>
<BR><FONT SIZE=3D2>> > > back the certificate that I have =
constructed for you. If </FONT>
<BR><FONT SIZE=3D2>> you ask for a </FONT>
<BR><FONT SIZE=3D2>> > > CRL I will give you one that doesn't =
name this </FONT>
<BR><FONT SIZE=3D2>> certificate. If you </FONT>
<BR><FONT SIZE=3D2>> > > choose to use a validation service =
like OCSP that's OK </FONT>
<BR><FONT SIZE=3D2>> because I'll </FONT>
<BR><FONT SIZE=3D2>> > > return 'valid' for your/my =
certificate. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Denial of service is the best bad =
behaviour you can </FONT>
<BR><FONT SIZE=3D2>> expect. Positively </FONT>
<BR><FONT SIZE=3D2>> > > helpful service is much worse! =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Secondly, you're going to send your =
certificate with the </FONT>
<BR><FONT SIZE=3D2>> > > message. Why, I </FONT>
<BR><FONT SIZE=3D2>> > > shall do that too! So I'm still you! =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > It is interesting you say that the =
worst that can happen </FONT>
<BR><FONT SIZE=3D2>> is that you </FONT>
<BR><FONT SIZE=3D2>> > > receive a certificate you don't =
trust. How do you know </FONT>
<BR><FONT SIZE=3D2>> you don't trust </FONT>
<BR><FONT SIZE=3D2>> > > it? I should think if you already =
know what certificates you </FONT>
<BR><FONT SIZE=3D2>> > > trust then </FONT>
<BR><FONT SIZE=3D2>> > > you don't need PKI at all! </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Ron. </FONT>
<BR><FONT SIZE=3D2>> > > > -----Original Message----- =
</FONT>
<BR><FONT SIZE=3D2>> > > > =
From: Phillip M Hallam-Baker =
[SMTP:pbaker@verisign.com] </FONT>
<BR><FONT SIZE=3D2>> > > > =
Sent: Friday, October 30, 1998 2:38 =
AM </FONT>
<BR><FONT SIZE=3D2>> > > > To:Ron Ramsay; Alan Lloyd =
</FONT>
<BR><FONT SIZE=3D2>> > > > Cc:Stephen Kent; =
ietf-pkix@imc.org; Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > > Subject: RE: =
Scale (and the SRV record) </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Thanks for taking time to =
develop the example. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Two issues: </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > 1. Surely DNS is not =
secure? </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > Define secure? With the =
exception of a denial of </FONT>
<BR><FONT SIZE=3D2>> service attack DNS </FONT>
<BR><FONT SIZE=3D2>> > > > is 'secure enough' for this =
purpose since there is no </FONT>
<BR><FONT SIZE=3D2>> trust placed </FONT>
<BR><FONT SIZE=3D2>> > > > on the server. The origin of a =
signed message is </FONT>
<BR><FONT SIZE=3D2>> irrelevant. Only </FONT>
<BR><FONT SIZE=3D2>> > > > the signature is relevant. =
</FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > 2. Your example seems to be =
based on encryption using </FONT>
<BR><FONT SIZE=3D2>> public keys. </FONT>
<BR><FONT SIZE=3D2>> > > > From </FONT>
<BR><FONT SIZE=3D2>> > > > > what I know of the public =
key system, it is not used for </FONT>
<BR><FONT SIZE=3D2>> > > encryption. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > I think you are confusing DNS =
security here with PKIX. </FONT>
<BR><FONT SIZE=3D2>> The two are </FONT>
<BR><FONT SIZE=3D2>> > > > very </FONT>
<BR><FONT SIZE=3D2>> > > > separate. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > If someone spoofed DNS the worst =
that would happen is </FONT>
<BR><FONT SIZE=3D2>> that I would </FONT>
<BR><FONT SIZE=3D2>> > > > recieve a certificate I didn't =
trust (and would ignore) or no </FONT>
<BR><FONT SIZE=3D2>> > > > certificate </FONT>
<BR><FONT SIZE=3D2>> > > > at all. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > >Its </FONT>
<BR><FONT SIZE=3D2>> > > > > purpose is authentication =
and integrity. To bend your </FONT>
<BR><FONT SIZE=3D2>> example, you </FONT>
<BR><FONT SIZE=3D2>> > > > will </FONT>
<BR><FONT SIZE=3D2>> > > > > be encrypting your message =
with your own private key. </FONT>
<BR><FONT SIZE=3D2>> How is an </FONT>
<BR><FONT SIZE=3D2>> > > > > addressee to verify it was =
you who sent the message </FONT>
<BR><FONT SIZE=3D2>> and that the </FONT>
<BR><FONT SIZE=3D2>> > > > message </FONT>
<BR><FONT SIZE=3D2>> > > > > was not modified? </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > I send my signing certificate =
with the message. Or once the </FONT>
<BR><FONT SIZE=3D2>> > > > infrastructure </FONT>
<BR><FONT SIZE=3D2>> > > > is deployed the recipient could =
use the SRV pointer to locate a </FONT>
<BR><FONT SIZE=3D2>> > > > directory </FONT>
<BR><FONT SIZE=3D2>> > > > where a copy of the certificate =
was available. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > =
> Phill </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE040A.EF04FF3E--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23083 for ietf-pkix-bks; Fri, 30 Oct 1998 05:33:57 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23078 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 05:33:56 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA08850; Fri, 30 Oct 1998 05:34:25 -0800 (PST)
Message-Id: <4.1.19981030074722.00a2d6f0@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 08:29:14 -0500
To: GBland@zergo.com, ietf-pkix@imc.org
From: Al Arsenault <aarsenault@spyrus.com>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <199810301234.MAA22292@ns0.zergo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Since I agree with most of what Phill has to say on this topic, I'll go against
my better judgement and jump in here.
If I'm understanding this correctly, the attack of concern is as follows:
Nothing today stops me from cobbling together my own certificate-generating and
-signing software, and then generating a self-signed certificate for user "US
Verisign Primary Class 3 Public Certificate Authority" (or whatever the magic
string is that will exactly match what VeriSign uses). This new certificate
will use the public key corresponding to a private key that I know, rather than
the one that VeriSign actually uses. (This ignores the scenario described by
Graham, in which I've managed to obtain VeriSign's private key.)
Given this, can I get you, the unsuspecting user, to use MY certificate (and
any user certificates I then issue with it) instead of the real one? After
all, once you've retrieved the certificate, the DN or subjectAltName field will
LOOK "right" to you, if you bother to check it. The argument has been that
given an insecure, spoofable, distribution mechanism, I might be able to fool
you into using the wrong "VeriSign certificate". If, for example, I can spoof
DNS and make you think that the IP address corresponding to "VeriSign.com" is,
say, 130.85.1.3, and I control that machine (note: I don't :-) then you'll go
there for the "real certificate" and I've got you. So, to counter that, you
need a "secure" distribution mechanism.
I frankly don't buy that argument, though. What is required in a PKI is that I
somehow securely obtain the certificate/public key of a CA that I have chosen
to trust - normally, that's the one that issued my certificate. If this first
step is broken - I'm fooled into accepting a certificate from a phony CA, or
whatever - then the security of the entire PKI is shot, and no X.500 directory
or other mechanism is going to help. Once I have that public key, though, I
can detect any faked certificates based on the trust my CA has. My CA will
have cross-certified with the REAL VeriSign Class 3 primary CA (when WHAT
freezes over? :-) Thus, even if I get your phony VeriSign cert that looks to
be the right one based on the name, I can't build a certification path back to
a node I trust, because my CA or whomever else I trust hasn't signed your
spoof. I'm protected against your spoof by the certificates and CRLs, not the
distribution mechanism.
(Of course, if you can trick the people I trust - my CA, for example - into
cross-certifying your fake certificate, I'm hosed. But that just means that I
trusted some incompetent fool I shouldn't have. A '"secure" X.500 directory
won't help at all once my CA has botched it.)
Al Arsenault
--- standard disclaimer - my own opinions; don't reflect those of my employer
or of any other organization to which I may have a relationship; etc., etc., ad
infinitum, ad nauseum
At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
>
> How are you going to do all this ?
>
> The only way I can think of is that either you know or have compromised the
> CA private keys.
> If you know the private signature keys then all information is compromised
> regardless of source.
> If you don't how will you construct the Certificates, CRLs, OCSP responses
> etc.
>
> This is an attack based on the compromise of the CA, not the security of DNS
> OCSP etc.
>
> Graham Bland
>
> > -----Original Message-----
> > From: Ron Ramsay
> [<mailto:Ron.Ramsay@OpenDirectory.com.au>mailto:Ron.Ramsay@OpenDirectory.c
> om.au]
> > Sent: 30 October 1998 02:42
> > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > Subject: RE: Scale (and the SRV record)
> >
> >
> > Phillip,
> >
> > Thanks again.
> >
> > Let me pick up on two points.
> >
> > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > to hard) I
> > can provide the address of my server in any of the records of
> > interest.
> > A request for your certificate will come to my server and I will send
> > back the certificate that I have constructed for you. If you ask for a
> > CRL I will give you one that doesn't name this certificate. If you
> > choose to use a validation service like OCSP that's OK because I'll
> > return 'valid' for your/my certificate.
> >
> > Denial of service is the best bad behaviour you can expect. Positively
> > helpful service is much worse!
> >
> > Secondly, you're going to send your certificate with the
> > message. Why, I
> > shall do that too! So I'm still you!
> >
> > It is interesting you say that the worst that can happen is that you
> > receive a certificate you don't trust. How do you know you don't trust
> > it? I should think if you already know what certificates you
> > trust then
> > you don't need PKI at all!
> >
> > Ron.
> > > -----Original Message-----
> > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > Sent: Friday, October 30, 1998 2:38 AM
> > > To:Ron Ramsay; Alan Lloyd
> > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > Subject: RE: Scale (and the SRV record)
> > >
> > >
> > >
> > > > Phillip,
> > > >
> > > > Thanks for taking time to develop the example.
> > > >
> > > > Two issues:
> > > >
> > > > 1. Surely DNS is not secure?
> > >
> > > Define secure? With the exception of a denial of service attack DNS
> > > is 'secure enough' for this purpose since there is no trust placed
> > > on the server. The origin of a signed message is irrelevant. Only
> > > the signature is relevant.
> > >
> > > > 2. Your example seems to be based on encryption using public keys.
> > > From
> > > > what I know of the public key system, it is not used for
> > encryption.
> > >
> > >
> > > I think you are confusing DNS security here with PKIX. The two are
> > > very
> > > separate.
> > >
> > > If someone spoofed DNS the worst that would happen is that I would
> > > recieve a certificate I didn't trust (and would ignore) or no
> > > certificate
> > > at all.
> > >
> > > >Its
> > > > purpose is authentication and integrity. To bend your example, you
> > > will
> > > > be encrypting your message with your own private key. How is an
> > > > addressee to verify it was you who sent the message and that the
> > > message
> > > > was not modified?
> > >
> > > I send my signing certificate with the message. Or once the
> > > infrastructure
> > > is deployed the recipient could use the SRV pointer to locate a
> > > directory
> > > where a copy of the certificate was available.
> > >
> > > Phill
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22557 for ietf-pkix-bks; Fri, 30 Oct 1998 04:34:45 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22553 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 04:34:43 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id NAA17357 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:36:58 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA38420; Fri, 30 Oct 1998 13:36:52 +0100
Received: by HYDRA with Microsoft Mail id <01BE0409.59059F30@HYDRA>; Fri, 30 Oct 1998 13:29:40 +0100
Message-ID: <01BE0409.59059F30@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'SEIS-List'" <list@seis.nc-forum.com>, "'Stefan Santesson'" <stefan@accurata.se>
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: QC - civicRegistrationNumber
Date: Fri, 30 Oct 1998 13:29:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Regarding Qualified Certificates:
civicRegistrationNumber
should IMHO be altered to
civicRegistrationCode
as it does not have to be numeric
Anders Rundgren
Senior Internet E-commerce Architect
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19218 for ietf-pkix-bks; Fri, 30 Oct 1998 03:06:18 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA19214 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 03:06:13 -0800 (PST)
From: GBland@zergo.com
Message-Id: <199810301234.MAA22292@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
To: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 11:06:06 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE03F5.4A711B70"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE03F5.4A711B70
Content-Type: text/plain
How are you going to do all this ?
The only way I can think of is that either you know or have compromised
the CA private keys.
If you know the private signature keys then all information is
compromised regardless of source.
If you don't how will you construct the Certificates, CRLs, OCSP
responses etc.
This is an attack based on the compromise of the CA, not the security of
DNS OCSP etc.
Graham Bland
> -----Original Message-----
> From: Ron Ramsay [mailto:Ron.Ramsay@OpenDirectory.com.au]
> Sent: 30 October 1998 02:42
> To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> Subject: RE: Scale (and the SRV record)
>
>
> Phillip,
>
> Thanks again.
>
> Let me pick up on two points.
>
> Firsly, DNS security. If I can spoof DNS (which doesn't look
> to hard) I
> can provide the address of my server in any of the records of
> interest.
> A request for your certificate will come to my server and I will send
> back the certificate that I have constructed for you. If you ask for a
> CRL I will give you one that doesn't name this certificate. If you
> choose to use a validation service like OCSP that's OK because I'll
> return 'valid' for your/my certificate.
>
> Denial of service is the best bad behaviour you can expect. Positively
> helpful service is much worse!
>
> Secondly, you're going to send your certificate with the
> message. Why, I
> shall do that too! So I'm still you!
>
> It is interesting you say that the worst that can happen is that you
> receive a certificate you don't trust. How do you know you don't trust
> it? I should think if you already know what certificates you
> trust then
> you don't need PKI at all!
>
> Ron.
> > -----Original Message-----
> > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > Sent: Friday, October 30, 1998 2:38 AM
> > To: Ron Ramsay; Alan Lloyd
> > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > Subject: RE: Scale (and the SRV record)
> >
> >
> >
> > > Phillip,
> > >
> > > Thanks for taking time to develop the example.
> > >
> > > Two issues:
> > >
> > > 1. Surely DNS is not secure?
> >
> > Define secure? With the exception of a denial of service attack DNS
> > is 'secure enough' for this purpose since there is no trust placed
> > on the server. The origin of a signed message is irrelevant. Only
> > the signature is relevant.
> >
> > > 2. Your example seems to be based on encryption using public keys.
> > From
> > > what I know of the public key system, it is not used for
> encryption.
> >
> >
> > I think you are confusing DNS security here with PKIX. The two are
> > very
> > separate.
> >
> > If someone spoofed DNS the worst that would happen is that I would
> > recieve a certificate I didn't trust (and would ignore) or no
> > certificate
> > at all.
> >
> > >Its
> > > purpose is authentication and integrity. To bend your example, you
> > will
> > > be encrypting your message with your own private key. How is an
> > > addressee to verify it was you who sent the message and that the
> > message
> > > was not modified?
> >
> > I send my signing certificate with the message. Or once the
> > infrastructure
> > is deployed the recipient could use the SRV pointer to locate a
> > directory
> > where a copy of the certificate was available.
> >
> > Phill
>
------ =_NextPart_001_01BE03F5.4A711B70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>How are you going to do all this ?</FONT>
</P>
<P><FONT SIZE=3D2>The only way I can think of is that either you know =
or have compromised the CA private keys.</FONT>
<BR><FONT SIZE=3D2>If you know the private signature keys then all =
information is compromised regardless of source.</FONT>
<BR><FONT SIZE=3D2>If you don't how will you construct the =
Certificates, CRLs, OCSP responses etc.</FONT>
</P>
<P><FONT SIZE=3D2>This is an attack based on the compromise of the CA, =
not the security of DNS OCSP etc.</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Ron Ramsay [<A =
HREF=3D"mailto:Ron.Ramsay@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Ron.Ramsay@OpenDirectory.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 30 October 1998 02:42</FONT>
<BR><FONT SIZE=3D2>> To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan =
Lloyd</FONT>
<BR><FONT SIZE=3D2>> Cc: Stephen Kent; ietf-pkix@imc.org; Rick =
Harvey</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Phillip,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Thanks again.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Let me pick up on two points.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Firsly, DNS security. If I can spoof DNS (which =
doesn't look </FONT>
<BR><FONT SIZE=3D2>> to hard) I</FONT>
<BR><FONT SIZE=3D2>> can provide the address of my server in any of =
the records of </FONT>
<BR><FONT SIZE=3D2>> interest.</FONT>
<BR><FONT SIZE=3D2>> A request for your certificate will come to my =
server and I will send</FONT>
<BR><FONT SIZE=3D2>> back the certificate that I have constructed =
for you. If you ask for a</FONT>
<BR><FONT SIZE=3D2>> CRL I will give you one that doesn't name this =
certificate. If you</FONT>
<BR><FONT SIZE=3D2>> choose to use a validation service like OCSP =
that's OK because I'll</FONT>
<BR><FONT SIZE=3D2>> return 'valid' for your/my certificate.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Denial of service is the best bad behaviour you =
can expect. Positively</FONT>
<BR><FONT SIZE=3D2>> helpful service is much worse!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Secondly, you're going to send your certificate =
with the </FONT>
<BR><FONT SIZE=3D2>> message. Why, I</FONT>
<BR><FONT SIZE=3D2>> shall do that too! So I'm still you!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> It is interesting you say that the worst that =
can happen is that you</FONT>
<BR><FONT SIZE=3D2>> receive a certificate you don't trust. How do =
you know you don't trust</FONT>
<BR><FONT SIZE=3D2>> it? I should think if you already know what =
certificates you </FONT>
<BR><FONT SIZE=3D2>> trust then</FONT>
<BR><FONT SIZE=3D2>> you don't need PKI at all!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Ron.</FONT>
<BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> > From: =
Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]</FONT>
<BR><FONT SIZE=3D2>> > Sent: =
Friday, October 30, 1998 2:38 AM</FONT>
<BR><FONT SIZE=3D2>> > To:Ron Ramsay; Alan Lloyd</FONT>
<BR><FONT SIZE=3D2>> > Cc:Stephen Kent; ietf-pkix@imc.org; Rick =
Harvey</FONT>
<BR><FONT SIZE=3D2>> > Subject: RE: Scale (and =
the SRV record)</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > > Phillip,</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Thanks for taking time to develop the =
example.</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Two issues:</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > 1. Surely DNS is not secure?</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Define secure? With the exception of a =
denial of service attack DNS</FONT>
<BR><FONT SIZE=3D2>> > is 'secure enough' for this purpose since =
there is no trust placed</FONT>
<BR><FONT SIZE=3D2>> > on the server. The origin of a signed =
message is irrelevant. Only</FONT>
<BR><FONT SIZE=3D2>> > the signature is relevant.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > > 2. Your example seems to be based on =
encryption using public keys.</FONT>
<BR><FONT SIZE=3D2>> > From</FONT>
<BR><FONT SIZE=3D2>> > > what I know of the public key system, =
it is not used for </FONT>
<BR><FONT SIZE=3D2>> encryption.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I think you are confusing DNS security =
here with PKIX. The two are</FONT>
<BR><FONT SIZE=3D2>> > very</FONT>
<BR><FONT SIZE=3D2>> > separate.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > If someone spoofed DNS the worst that =
would happen is that I would </FONT>
<BR><FONT SIZE=3D2>> > recieve a certificate I didn't trust (and =
would ignore) or no</FONT>
<BR><FONT SIZE=3D2>> > certificate</FONT>
<BR><FONT SIZE=3D2>> > at all.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > >Its</FONT>
<BR><FONT SIZE=3D2>> > > purpose is authentication and =
integrity. To bend your example, you</FONT>
<BR><FONT SIZE=3D2>> > will</FONT>
<BR><FONT SIZE=3D2>> > > be encrypting your message with your =
own private key. How is an</FONT>
<BR><FONT SIZE=3D2>> > > addressee to verify it was you who =
sent the message and that the</FONT>
<BR><FONT SIZE=3D2>> > message</FONT>
<BR><FONT SIZE=3D2>> > > was not modified?</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I send my signing certificate with the =
message. Or once the</FONT>
<BR><FONT SIZE=3D2>> > infrastructure</FONT>
<BR><FONT SIZE=3D2>> > is deployed the recipient could use the =
SRV pointer to locate a</FONT>
<BR><FONT SIZE=3D2>> > directory</FONT>
<BR><FONT SIZE=3D2>> > where a copy of the certificate was =
available. </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Phill</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE03F5.4A711B70--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA17840 for ietf-pkix-bks; Fri, 30 Oct 1998 01:33:13 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA17832 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 01:33:10 -0800 (PST)
Message-Id: <199810301101.LAA21997@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
From: Graham Bland <GBland@zergo.com>
To: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:32:51 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE03E8.438B173C"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE03E8.438B173C
Content-Type: text/plain;
charset="iso-8859-1"
Large portions of original message deleted for readability, relevant
sections only maintained with comments in line.
Graham Bland
> -----Original Message-----
> From: Alan Lloyd [mailto:Alan.Lloyd@OpenDirectory.com.au]
> Sent: 29 October 1998 21:37
> To: 'Bill Burr'; Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
...deleted
> > I have been saying for some time that don't know of anybody who has
> > built
> > an X.500 directory of a size that convinces me that it is a viable
> > technology to base a US national PKI, or even a US Federal
> > government-wide
> > PKI on. I keep asking the question, where are the really big
> > distributed
> > X.500 directories? Particularly multivendor directories.
> But I don't
> > seem
> > to get any answers. What I hear are horror stories about the
> > difficulties
> > of getting any two X.500 products to work together.
> [Alan Lloyd]
> No horror stories from us. 20 million entries, 1000s of searches
> a second, distributed, multi master, etc We have very scaleable,
> distributed technology - that also integrates LDAP servers, etc We are
> very busy deploying X.500 into major corporate infrastructures who are
> following the themes I described. Including those in the US.
> Please read
> our WEB site. "Uses of Directory Services"
>
Can I access these directories or are they private islands. If they are
private islands then they might as well not exist.
> > If the X.500 directory industry builds products that interoperate
> > and scale
> > well, it has done a really bad job of getting the word out.
> [Alan Lloyd]
> My view here is that the LDAP hype has done a really good job of
> damaging X.500. However, now the LDAP hype has dissipated and reality
> has set in we are left with a protocol that can only ACCESS a
> directory
> service ? is twice as big as DAP and has half the functionality. In
> addition, getting LDAP only solutions is proving to many that X.500 is
> the way to go because of LDAPs NO distribution and a model
> that demands
> Replicate everything to everywhere. LDAP has high operational
> costs and
> gets to a point where it is unworkable.
> So LDAP accessed X.500 in my book is the way to go and is being
> deployed globally.
I think you meant to say DAP accessed X.500 from the flow of the text
>
> > Until now, I have also been saying, does anybody have a believable
> > alternative to the mythological, pervasive X.500 directory service?
> > It
> > seemed almost a rhetorical question. But I think perhaps Phill has
> > outlined an alternative, that looks like it probably ought to work,
> > and is
> > based on something, DNS, that we know works well, scales well, and
> > exists
> > now. Moreover, we should be able to create the service we need
> > incrementally, by just by adding servers as we need them, one at a
> > time.
> > And, If I understand the proposal, all we have to do is
> agree on some
> > simple naming conventions.
> [Alan Lloyd] I am not against alternative proposals - its all a
> question of how much effort and implementation goes behind it. Phills
> solution has to be backed by all the DNS and PKI suppliers on this
> planet and DNS then has to become secure - with signed operations,
> mutual authentication, access controls, real life naming, and scale a
> lot better and of course be easy to manage and follow Object Oriented
> design. (does this mean turning DNS into X.500?) I would vote
> for that -
> thats more X.500!
Why would DNS need to be more secure with signed operations mutual
authentication etc. Certificates and CRLs are signed objects and their
security is inherent. Ignoring denial of service I cannot see any
attacks from an insecure distribution method. The whole point of the
distribution method is that I have no trust relationship with it and
have no need of a trust relationship be it email, X.500 or anything
else.
How is it relevant if DNS follows OO design, why should it. While I
agree that OO design and methods have many advantages the relevant
questions are does it work and how much will it cost, not what its
internal structure is.
What is the problem with the scalability of DNS (How many users does it
support now ?)
X.500 is easy to manage? later you say "But LDAP did prove that
directorys are difficult
and complex and X.500 got most things right."
Graham Bland
------ =_NextPart_001_01BE03E8.438B173C
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=3D2>Large portions of original message deleted for =
readability, relevant sections only maintained with comments in =
line.</FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Alan Lloyd [<A =
HREF=3D"mailto:Alan.Lloyd@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Alan.Lloyd@OpenDirectory.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 29 October 1998 21:37</FONT>
<BR><FONT SIZE=3D2>> To: 'Bill Burr'; Alan Lloyd; 'Phillip M =
Hallam-Baker'; Russ Housley;</FONT>
<BR><FONT SIZE=3D2>> ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
</P>
<P><FONT SIZE=3D2>...deleted</FONT>
<BR><FONT SIZE=3D2>> > I have been saying for some time that =
don't know of anybody who has</FONT>
<BR><FONT SIZE=3D2>> > built</FONT>
<BR><FONT SIZE=3D2>> > an X.500 directory of a size that =
convinces me that it is a viable</FONT>
<BR><FONT SIZE=3D2>> > technology to base a US national PKI, or =
even a US Federal</FONT>
<BR><FONT SIZE=3D2>> > government-wide</FONT>
<BR><FONT SIZE=3D2>> > PKI on. I keep asking the question, where =
are the really big</FONT>
<BR><FONT SIZE=3D2>> > distributed</FONT>
<BR><FONT SIZE=3D2>> > X.500 directories? Particularly =
multivendor directories. </FONT>
<BR><FONT SIZE=3D2>> But I don't</FONT>
<BR><FONT SIZE=3D2>> > seem</FONT>
<BR><FONT SIZE=3D2>> > to get any answers. What I hear are =
horror stories about the</FONT>
<BR><FONT SIZE=3D2>> > difficulties</FONT>
<BR><FONT SIZE=3D2>> > of getting any two X.500 products to work =
together.</FONT>
<BR><FONT SIZE=3D2>> [Alan =
Lloyd] </FONT>
<BR><FONT SIZE=3D2>> No horror =
stories from us. 20 million entries, 1000s of searches</FONT>
<BR><FONT SIZE=3D2>> a second, distributed, multi master, etc We =
have very scaleable,</FONT>
<BR><FONT SIZE=3D2>> distributed technology - that also integrates =
LDAP servers, etc We are</FONT>
<BR><FONT SIZE=3D2>> very busy deploying X.500 into major corporate =
infrastructures who are</FONT>
<BR><FONT SIZE=3D2>> following the themes I described. Including =
those in the US. </FONT>
<BR><FONT SIZE=3D2>> Please read</FONT>
<BR><FONT SIZE=3D2>> our WEB site. "Uses of Directory =
Services"</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
<P><FONT SIZE=3D2>Can I access these directories or are they private =
islands. If they are private islands then they might as well not =
exist.</FONT></P>
<BR>
<P><FONT SIZE=3D2>> > If the X.500 directory industry =
builds products that interoperate</FONT>
<BR><FONT SIZE=3D2>> > and scale</FONT>
<BR><FONT SIZE=3D2>> > well, it has done a really bad job of =
getting the word out. </FONT>
<BR><FONT SIZE=3D2>> [Alan =
Lloyd] </FONT>
<BR><FONT SIZE=3D2>> My view here is =
that the LDAP hype has done a really good job of</FONT>
<BR><FONT SIZE=3D2>> damaging X.500. However, now the LDAP hype has =
dissipated and reality</FONT>
<BR><FONT SIZE=3D2>> has set in we are left with a protocol that can =
only ACCESS a </FONT>
<BR><FONT SIZE=3D2>> directory</FONT>
<BR><FONT SIZE=3D2>> service ? is twice as big as DAP and has half =
the functionality. In</FONT>
<BR><FONT SIZE=3D2>> addition, getting LDAP only solutions is =
proving to many that X.500 is</FONT>
<BR><FONT SIZE=3D2>> the way to go because of LDAPs NO distribution =
and a model </FONT>
<BR><FONT SIZE=3D2>> that demands</FONT>
<BR><FONT SIZE=3D2>> Replicate everything to everywhere. LDAP has =
high operational </FONT>
<BR><FONT SIZE=3D2>> costs and</FONT>
<BR><FONT SIZE=3D2>> gets to a point where it is unworkable.</FONT>
<BR><FONT SIZE=3D2>> So LDAP accessed =
X.500 in my book is the way to go and is being</FONT>
<BR><FONT SIZE=3D2>> deployed globally.</FONT>
</P>
<P><FONT SIZE=3D2>I think you meant to say DAP accessed X.500 from the =
flow of the text</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > Until now, I have also been saying, =
does anybody have a believable</FONT>
<BR><FONT SIZE=3D2>> > alternative to the mythological, pervasive =
X.500 directory service?</FONT>
<BR><FONT SIZE=3D2>> > It</FONT>
<BR><FONT SIZE=3D2>> > seemed almost a rhetorical question. =
But I think perhaps Phill has</FONT>
<BR><FONT SIZE=3D2>> > outlined an alternative, that looks like =
it probably ought to work,</FONT>
<BR><FONT SIZE=3D2>> > and is</FONT>
<BR><FONT SIZE=3D2>> > based on something, DNS, that we know =
works well, scales well, and</FONT>
<BR><FONT SIZE=3D2>> > exists</FONT>
<BR><FONT SIZE=3D2>> > now. Moreover, we should be able to create =
the service we need</FONT>
<BR><FONT SIZE=3D2>> > incrementally, by just by adding servers =
as we need them, one at a</FONT>
<BR><FONT SIZE=3D2>> > time.</FONT>
<BR><FONT SIZE=3D2>> > And, If I understand the proposal, all we =
have to do is </FONT>
<BR><FONT SIZE=3D2>> agree on some</FONT>
<BR><FONT SIZE=3D2>> > simple naming conventions.</FONT>
<BR><FONT SIZE=3D2>> [Alan =
Lloyd] I am not against alternative proposals - its all a</FONT>
<BR><FONT SIZE=3D2>> question of how much effort and implementation =
goes behind it. Phills</FONT>
<BR><FONT SIZE=3D2>> solution has to be backed by all the DNS and =
PKI suppliers on this</FONT>
<BR><FONT SIZE=3D2>> planet and DNS then has to become secure - with =
signed operations,</FONT>
<BR><FONT SIZE=3D2>> mutual authentication, access controls, real =
life naming, and scale a</FONT>
<BR><FONT SIZE=3D2>> lot better and of course be easy to manage and =
follow Object Oriented</FONT>
<BR><FONT SIZE=3D2>> design. (does this mean turning DNS into =
X.500?) I would vote </FONT>
<BR><FONT SIZE=3D2>> for that -</FONT>
<BR><FONT SIZE=3D2>> thats more X.500!</FONT>
</P>
<P><FONT SIZE=3D2>Why would DNS need to be more secure with signed =
operations mutual authentication etc. Certificates and CRLs are signed =
objects and their security is inherent. Ignoring denial of =
service I cannot see any attacks from an insecure distribution =
method. The whole point of the distribution method is that I have =
no trust relationship with it and have no need of a trust relationship =
be it email, X.500 or anything else.</FONT></P>
<P><FONT SIZE=3D2>How is it relevant if DNS follows OO design, why =
should it. While I agree that OO design and methods have many =
advantages the relevant questions are does it work and how much will it =
cost, not what its internal structure is.</FONT></P>
<P><FONT SIZE=3D2>What is the problem with the scalability of DNS (How =
many users does it support now ?)</FONT>
</P>
<P><FONT SIZE=3D2>X.500 is easy to manage? later you say "But LDAP =
did prove that directorys are difficult</FONT>
<BR><FONT SIZE=3D2> and complex and X.500 got most things =
right." </FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE03E8.438B173C--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA27821 for ietf-pkix-bks; Thu, 29 Oct 1998 18:44:29 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA27815 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 18:44:21 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PNR>; Fri, 30 Oct 1998 13:42:14 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0656C6@DSG1>
From: Ron Ramsay <Ron.Ramsay@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Ron Ramsay <Ron.Ramsay@OpenDirectory.com.au>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org, Rick Harvey <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 13:42:13 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phillip,
Thanks again.
Let me pick up on two points.
Firsly, DNS security. If I can spoof DNS (which doesn't look to hard) I
can provide the address of my server in any of the records of interest.
A request for your certificate will come to my server and I will send
back the certificate that I have constructed for you. If you ask for a
CRL I will give you one that doesn't name this certificate. If you
choose to use a validation service like OCSP that's OK because I'll
return 'valid' for your/my certificate.
Denial of service is the best bad behaviour you can expect. Positively
helpful service is much worse!
Secondly, you're going to send your certificate with the message. Why, I
shall do that too! So I'm still you!
It is interesting you say that the worst that can happen is that you
receive a certificate you don't trust. How do you know you don't trust
it? I should think if you already know what certificates you trust then
you don't need PKI at all!
Ron.
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, October 30, 1998 2:38 AM
> To: Ron Ramsay; Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> Subject: RE: Scale (and the SRV record)
>
>
>
> > Phillip,
> >
> > Thanks for taking time to develop the example.
> >
> > Two issues:
> >
> > 1. Surely DNS is not secure?
>
> Define secure? With the exception of a denial of service attack DNS
> is 'secure enough' for this purpose since there is no trust placed
> on the server. The origin of a signed message is irrelevant. Only
> the signature is relevant.
>
> > 2. Your example seems to be based on encryption using public keys.
> From
> > what I know of the public key system, it is not used for encryption.
>
>
> I think you are confusing DNS security here with PKIX. The two are
> very
> separate.
>
> If someone spoofed DNS the worst that would happen is that I would
> recieve a certificate I didn't trust (and would ignore) or no
> certificate
> at all.
>
> >Its
> > purpose is authentication and integrity. To bend your example, you
> will
> > be encrypting your message with your own private key. How is an
> > addressee to verify it was you who sent the message and that the
> message
> > was not modified?
>
> I send my signing certificate with the message. Or once the
> infrastructure
> is deployed the recipient could use the SRV pointer to locate a
> directory
> where a copy of the certificate was available.
>
> Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27269 for ietf-pkix-bks; Thu, 29 Oct 1998 17:45:20 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27265 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 17:45:17 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PNH>; Fri, 30 Oct 1998 12:43:04 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4D7@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: More - RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 12:43:03 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill in the email I sent I did ask some questions re OCSP and its
information model and how it does work with recipents who get many
messages for anywhere. No answers to these questions make OCSP a
mechanism, not a solution.
And the reason for all this debate is how we easily support the multi
domain validation process in a way that scales, keeps client software as
simple as possible and from a conceptual point of view provides CAs/PKI
suppliers with a way that enables them to upgrade their information
models and services without affecting all the client software concerned.
In addition most have recognised that a large scale PKI function must
align to business information systems and service delivery requirements.
The issue is still open I believe.
However, the proposals to investigate the use of directory matching
rules in support of a validation service and directory enable PKI
validation functions are still on the table.
Any one want to progress these views?
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, 30 October 1998 11:19
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27074 for ietf-pkix-bks; Thu, 29 Oct 1998 17:15:07 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27067 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 17:14:58 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PNC>; Fri, 30 Oct 1998 12:12:49 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4D3@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 12:12:48 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill - this one jumped to light speed eh? Comments as usual follow.
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, 30 October 1998 11:19
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> > > Hence the motivation for an Online Status service like OCSP.
> > [Alan Lloyd] Please enlighten me.
> > Companies make telephones based on the fact that there is a
> > distributed telephone network (switching infrastructure) out there
> that
> > supports global numbering and common protocols.
>
> The Internet is not like a telephone service. It is a network of
> networks
> and not a network.
[Alan Lloyd] So is the phone service - see BT, AT&T, NTT, I
wonder what the P in PABX means.
> The differences between the circuit switching infrastructure of the
> telephone system and the packet switching infrastructure of the
> Internet
> are significant and fundamental. The telephone system is optimized for
> voice, not data. As the role of data networks increases it is the
> telephone infrastructure which is being absorbed into the data network
> and not vice versa.
[Alan Lloyd] The telephone paradigm is used to indicate an
infrastructure which is distributed, owned by many, applies universal
numbering plans and scales efficiently.
It was not used in the debate to talk of bits and bytes.
> Don't try to re-fight the OSI vs IP protocol stack wars. This is not
> the place to do that. You might as well advocate gun control in
> talk.guns
> or go to a Klu-Klux-Klanbake and advocate racial tollerance. Nobody is
>
> arguing that directories do not have an important role in the
> Internet.
> But you seem to have to insist that everything that could be done by
> a directory SHOULD indeed MUST be done by one or it will fail to meet
> the catalog of noise word criteria you state.
[Alan Lloyd] Warp 7 on this one. I just say that when
directories are applied as the information infrastructure then PKIs are
much better and collectively they suit service provisioning for
businesses more efficiently. This is natural and expected being that
X.509 and PKIs is part of the X.500 directory standards.
(But isnt it odd that ASN.1 was defined as the tool for creating
presentation layers (layer 6 in OSI) and now its in many
specifications.)
> I don't think you are doing a very good job of being an advocate for
> directories. When you lump them together with terms that are so
> overused
> as to be meaningless marketing noise I suspect that many people will
> dismiss directories as another sales pitch hype
[Alan Lloyd] But there are many that arent - to their benefit.
> which will promise
> everything but deliver little: Object oriented - Isn't everything?
> Scale - in whose laboratory? Oh its a pitch for a directory and it
> will solve all my problems - I'll buy 3, make that 4 if it will also
> solve my Y2K. Do you support OpenGenera?
[Alan Lloyd] You obviously have one world, I have another. I
help design large scale distributed (secure) information systems that
work across continents so my views might be different to yours.
> The directory plays a very specific role in a PKI as a repository of
> signed objects. It does not create signed objects, it does not vouch
> for their trustworthiness.
[Alan Lloyd] Never said it did.
> It does not replace DNS.
[Alan Lloyd] But it could and may be it will.
> How the directory
> system manages its bits is its own affair. It is not the concern of
> the PKI except that the PKI must not rely on the directory service to
> fulfil expectations it is not capable of meeting.
[Alan Lloyd] Thats a view again. Not mine.
> There are roles for other types of PKI components but they are not
> called directories. They may share parts of the code base, they may
> re-use the protocols but it is not usefull to call everything a
> directory just because as Dilbert and Wally said 'we always build
> a directory', 'we like directories'[1].
[Alan Lloyd] Never said that a directory does everything. Just
said that a PKI is a Directory enabled function, so that distribution,
scaleability and a common information service paradigm can be applied -
rather that bespoke protocols and mechanisms that seem to provide
mystery and misery and limited functionality.
High functionality distributed infrastructure provides a
capability eg a telephone service or a directory service. Why not use it
rather than try to re-invent it?
regards alan
> Phill
>
> [1] I know it was actually a database.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26618 for ietf-pkix-bks; Thu, 29 Oct 1998 16:16:26 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26614 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 16:16:25 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id QAA22307; Thu, 29 Oct 1998 16:15:57 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id QAA06056; Thu, 29 Oct 1998 16:18:10 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 19:19:02 -0500
Message-ID: <004601be039a$e5c20fe0$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <D1A949D4508DD1119C8100400533BEDC05D4D1@DSG1>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> > Hence the motivation for an Online Status service like OCSP.
> [Alan Lloyd] Please enlighten me.
> Companies make telephones based on the fact that there is a
> distributed telephone network (switching infrastructure) out there that
> supports global numbering and common protocols.
The Internet is not like a telephone service. It is a network of networks
and not a network.
The differences between the circuit switching infrastructure of the
telephone system and the packet switching infrastructure of the Internet
are significant and fundamental. The telephone system is optimized for
voice, not data. As the role of data networks increases it is the
telephone infrastructure which is being absorbed into the data network
and not vice versa.
Don't try to re-fight the OSI vs IP protocol stack wars. This is not
the place to do that. You might as well advocate gun control in talk.guns
or go to a Klu-Klux-Klanbake and advocate racial tollerance. Nobody is
arguing that directories do not have an important role in the Internet.
But you seem to have to insist that everything that could be done by
a directory SHOULD indeed MUST be done by one or it will fail to meet
the catalog of noise word criteria you state.
I don't think you are doing a very good job of being an advocate for
directories. When you lump them together with terms that are so overused
as to be meaningless marketing noise I suspect that many people will
dismiss directories as another sales pitch hype which will promise
everything but deliver little: Object oriented - Isn't everything?
Scale - in whose laboratory? Oh its a pitch for a directory and it
will solve all my problems - I'll buy 3, make that 4 if it will also
solve my Y2K. Do you support OpenGenera?
The directory plays a very specific role in a PKI as a repository of
signed objects. It does not create signed objects, it does not vouch
for their trustworthiness. It does not replace DNS. How the directory
system manages its bits is its own affair. It is not the concern of
the PKI except that the PKI must not rely on the directory service to
fulfil expectations it is not capable of meeting.
There are roles for other types of PKI components but they are not
called directories. They may share parts of the code base, they may
re-use the protocols but it is not usefull to call everything a
directory just because as Dilbert and Wally said 'we always build
a directory', 'we like directories'[1].
Phill
[1] I know it was actually a database.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25943 for ietf-pkix-bks; Thu, 29 Oct 1998 14:18:57 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25939 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 14:18:50 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PMT>; Fri, 30 Oct 1998 09:16:43 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4D1@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:16:41 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
HMMMMMMMMMMMMMMMM!
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, 30 October 1998 6:55
> To: salzr@certco.com
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
>
>
> > >If someone spoofed DNS the worst that would happen is that I would
> > >recieve a certificate I didn't trust (and would ignore) or no
> > >certificate
> > at all.
> >
> > Well, if you're only fetching certificates, probably.
> >
> > But if you're fetching CRL's, then no. Suppose a cert is
> compromised,
> > and CRLn is issued before the "next update" time purely because of
> > that compromise. The adversary could spoof DNS and just send out
> > the valid, but outdated CRL(n-1) and potentially have quite a
> > window of opportunity.
>
> Hence the motivation for an Online Status service like OCSP.
[Alan Lloyd] Please enlighten me.
Companies make telephones based on the fact that there is a
distributed telephone network (switching infrastructure) out there that
supports global numbering and common protocols.
I thought that as X.509, certs, crls and CAs as used in PKIs are
part of globally named (or within a domain) named objects that reside in
a directory service (X.500), that those building PKIs would use the
distributed information infrastucture to support such functions. Not re
invent the infrastucture by disjoint mechanisms.
I hear the words Meta certs, OCSP, but what is the distributed
information infrastructure that supports it?
How is this modelled, how does it scale, who builds the clients,
what is the knowledge and configuration issues. How does a recipient
client know when it receives a signed message that one of the many OCSP
servers it knows about is responsible for validation or validation is
via the directory service. Do OCSP servers connect to the directory
service.... What is the SYSTEM (that scales) and whats the Business
level Information design . How does the OCSP architecture (what ever
that is) fit in with business service delivery?
There is a difference between a "protocol mechanism" to a
"server" and a directory service.
regards alan
> Alternatively use the OCDP mechanism to provide a 'meta CRL'. A
> master
> CRL can be issued every minute which would contain a list (CRLList) of
>
> the most current CRLs in each partition.
>
> This issue is orthogonal to the issue of directory discovery however.
> Any infrastructure for distributing CRLs has the same problem. I don't
> see that the solution is to attempt to guarantee delivery of the CRLs
> by hypothesizing secure infrastructures will be installed. I believe
> we should address the issue by removing the dependence.
>
>
> Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25765 for ietf-pkix-bks; Thu, 29 Oct 1998 13:39:37 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25760 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 13:39:24 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PMK>; Fri, 30 Oct 1998 08:37:16 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Bill Burr'" <william.burr@nist.gov>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 08:37:13 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line.
> -----Original Message-----
> From: Bill Burr [SMTP:william.burr@nist.gov]
> Sent: Friday, 30 October 1998 2:34
> To: Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> Alan,
>
> I'm more than a little confused about what it is that makes X.500
> directories particularly OO things. Is mashing the world into an
> X.500 DIT
> an object oriented approach? There is a level of OO theology here
> that
> seems beyond my grasp.
[Alan Lloyd] X.500 defines an information model that uses
Object Classes, Attributes, in a distributed Named Tree. A X.509 CA is
in fact an auxilliary Object Class, A certificate is an attribute of an
object class. A CRL Distribution Point is an Object Class. A country
entry in the DIT is an Object Class. All things in X.500 are identified
with Object Identifiers and when instanciated in a DIB they are named.
Operations on X.500 entries are atomic - ie a property of object
processing.....
> I think that we would want to think very hard about basing PKI names
> on
> domain names. It seems desirable to make names in certificates more
> directly related to the "real world" than domain names and e-mail
> addresses
> often seem to be. But, if we are dong a PKI for the Internet (and
> isn't
> this what PKIX is about?), then domain names and the DNS are the
> foundation
> that we build the whole Internet on anyhow.
[Alan Lloyd]
The Internet has many layers in my book. The physical layer and
Lans and things, the Internet layer, the domain layer for machine based
names, and the application layer. DNS deals with Internet addresses and
Domains. Its history that domains relate to organisations. However, as
applications over the Internet evolve, then the higher level naming
constructs relate to real life. Ie. I have a name of Alan, but I may get
services from many internet domains eg Ozemail, Compuserve, MSN, etc. I
dont want 10 names because I use 10 domain based services.
> If the car, or perhaps the toll road operator, in your toll plaza
> example,
> doesn't have a domain name, or an IP address, why is it the concern of
> PKIX, which is, after all, an Internet standard group. Is it even
> appropriate for the PKIX group to worry about things that don't relate
> to
> the Internet?
[Alan Lloyd] Thats a view. I tend to think that the Internet
and Internet style technologies get used where they can. So why not
build things with the widest capability. Thats what the market wants.
> I have been saying for some time that don't know of anybody who has
> built
> an X.500 directory of a size that convinces me that it is a viable
> technology to base a US national PKI, or even a US Federal
> government-wide
> PKI on. I keep asking the question, where are the really big
> distributed
> X.500 directories? Particularly multivendor directories. But I don't
> seem
> to get any answers. What I hear are horror stories about the
> difficulties
> of getting any two X.500 products to work together.
[Alan Lloyd]
No horror stories from us. 20 million entries, 1000s of searches
a second, distributed, multi master, etc We have very scaleable,
distributed technology - that also integrates LDAP servers, etc We are
very busy deploying X.500 into major corporate infrastructures who are
following the themes I described. Including those in the US. Please read
our WEB site. "Uses of Directory Services"
> If the X.500 directory industry builds products that interoperate
> and scale
> well, it has done a really bad job of getting the word out.
[Alan Lloyd]
My view here is that the LDAP hype has done a really good job of
damaging X.500. However, now the LDAP hype has dissipated and reality
has set in we are left with a protocol that can only ACCESS a directory
service ? is twice as big as DAP and has half the functionality. In
addition, getting LDAP only solutions is proving to many that X.500 is
the way to go because of LDAPs NO distribution and a model that demands
Replicate everything to everywhere. LDAP has high operational costs and
gets to a point where it is unworkable.
So LDAP accessed X.500 in my book is the way to go and is being
deployed globally.
> Until now, I have also been saying, does anybody have a believable
> alternative to the mythological, pervasive X.500 directory service?
> It
> seemed almost a rhetorical question. But I think perhaps Phill has
> outlined an alternative, that looks like it probably ought to work,
> and is
> based on something, DNS, that we know works well, scales well, and
> exists
> now. Moreover, we should be able to create the service we need
> incrementally, by just by adding servers as we need them, one at a
> time.
> And, If I understand the proposal, all we have to do is agree on some
> simple naming conventions.
[Alan Lloyd] I am not against alternative proposals - its all a
question of how much effort and implementation goes behind it. Phills
solution has to be backed by all the DNS and PKI suppliers on this
planet and DNS then has to become secure - with signed operations,
mutual authentication, access controls, real life naming, and scale a
lot better and of course be easy to manage and follow Object Oriented
design. (does this mean turning DNS into X.500?) I would vote for that -
thats more X.500!
> That seems very, very appealing.
>
> Once we accept domain names as the basis PKI naming, we are probably
> stuck
> with it forever. Folks who aren't even on the Internet themselves,
> may
> wind up getting domain names for PKI purposes. Perhaps the world
> would, in
> the end, be a better place if we waited for X.500 directory technology
> to
> mature, and then built a pervasive PKI DIT that has nothing to do with
> Internet domain names. But solutions that we can get to work
> reasonably
> well now, with a fairly small effort, usually seem to beat arguably
> better,
> but more distant solutions.
>
[Alan Lloyd] Thats a view but its not mine or the major
organisations that I work with.
I think the best way forward is for who want to build
distributed information systems for business purposes to use X.500 and
for those who want high configuration, low trust, high operational costs
and wait for 5 years go down the DNS route.
Isnt it odd that X.509 is used for PKI and X.500 is discounted?
In addition X.500 solves a complex problem - ie. distributed,
object oriented, name based transaction systems that scale and provide
business information infrastructures. Yet as we have seen with LDAP,
trying to address a complex problem with a simple solution just does not
work. LDAP has taken three years to re invent 10% of a standard that was
released 10 years ago. But LDAP did prove that directorys are difficult
and complex and X.500 got most things right. Is this DNS approach about
to set off on the same track. Ie if distributed PKI is a complex problem
its going to take the same time?
regards alan
> At 10:52 AM 10/29/98 +1100, Alan Lloyd wrote:
> >But why do this - this is yet more configuration and operational cost
> to
> >large systems - and it means relating certificates and CAs to DNS
> when
> >they are in fact (from an OO perspective) just attributes of
> >objects/functions in real life. Ie a Car might have a key and
> >certificate issued by a traffic controller or toll plaza - to deal
> with
> >acqisition, identification and charging of the vehicle through Toll
> >sections on a freeway. Where does DNS fit here? The "DNS SRV
> configure
> >everything" route just seems to denegrate the , real life OO
> principles
> >of directories - which are there so that we can get away from these
> >machine level plumbing issues.
> >
> >I think of CAs as functions and certs that are applied to real life
> >entities which are represented as attributes of objects in a business
> >level directory system.
> >
> >Bashing DNS records into certs and CA operations and validation paths
> >just complicates life with a higher operational costs and does not
> use
> >the utility of distributed information infrastructures. Its like
> >configuring every phone with every one elses phone number. When in
> fact
> >we use the distributed telephone network and its directory system to
> >avoid that.
> >
> >
> >regards alan
> >
> >> -----Original Message-----
> >> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> >> Sent: Thursday, 29 October 1998 6:02
> >> To: Russ Housley; ietf-pkix@imc.org
> >> Subject: RE: Scale (and the SRV record)
> >>
> >> Russ,
> >>
> >> You are right of course! Note that the scheme I propose allows a
> >> certificate repository whose naming scheme is PKIX compatible to
> also
> >> be
> >> advertised. We might have:
> >>
> >> __pkix._http._tcp.arius.com
> >> __pkix._ldap._tcp.arius.com
> >> __pkix._finger._tcp.arius.com
> >>
> >> or even!
> >>
> >> __pkix._verynewprotocol.arius.com
> >>
> >> And since an SRV record is simply an MX record on steroids each
> >> can define server priorities and preferences.
> >>
> >> What would then be required is a draft describing the naming
> >> conventions such a server would conform to and how clients should
> >> interpret the scope of the statement. __pkix._http._tcp.arius.com
> >> is essentially saying "look at the corresponding server where you
> >> will find a PKIX repository whose scope includes (all?)
> certificates
> >> issued which are bound to DNS names within the scope 'arius.com'."
> >>
> >> Alan will have a directory there (we presume) as I would expect
> >> would most enterprises. There might be a move in favour of an HTTP
> >> service acting as a border directory and an LDAP server providing
> >> a more flexible, searchable service inside the enterprise.
> >>
> >> Phill
> >>
> >> > -----Original Message-----
> >> > From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On
> >> Behalf
> >> > Of Russ Housley
> >> > Sent: Wednesday, October 28, 1998 1:29 PM
> >> > To: Alan Lloyd
> >> > Cc: ietf-pkix@imc.org
> >> > Subject: Scale (and the SRV record)
> >> >
> >> >
> >> > Alan asks:
> >> >
> >> > > I need to be enlightened - How does one deploy a large scale
> >> distributed
> >> > > PKI without a large scale object oriented distributed (and
> >> protected by
> >> > > ACI, etc) directory system?
> >> >
> >> > Directory is the preferred certificate repository, but it is not
> the
> >> only
> >> > repository that will scale. People have used FTP, Finger, HTTP,
> and
> >> other
> >> > mechanisms to distribute certificates.
> >> >
> >> > The PKI is not dependent on the deployment of a Directory, as
> these
> >> other
> >> > mechanism can be used until the Directory become widely
> available.
> >> >
> >> > Further, a trusted repository is not a requirement. Since
> >> > certificates and
> >> > CRLs are signed, the repository cannot make undetected
> modification
> >> to the
> >> > data structures. Denial of service is allways an issue; it is a
> >> > concern in
> >> > all of the possible repository alternatives.
> >> >
> >> > Russ
> >> >
> >> >
> >
> >
> Regards,
>
> Bill Burr
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25081 for ietf-pkix-bks; Thu, 29 Oct 1998 11:52:40 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25077 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 11:52:39 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA15572; Thu, 29 Oct 1998 11:52:06 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA15172; Thu, 29 Oct 1998 11:54:20 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: <salzr@certco.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 14:55:11 -0500
Message-ID: <001601be0376$0972df20$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <29E0A6D39ABED111A36000A0C99609CA18D2FA@macertco-srv1.ma.certco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> >If someone spoofed DNS the worst that would happen is that I would
> >recieve a certificate I didn't trust (and would ignore) or no
> >certificate
> at all.
>
> Well, if you're only fetching certificates, probably.
>
> But if you're fetching CRL's, then no. Suppose a cert is compromised,
> and CRLn is issued before the "next update" time purely because of
> that compromise. The adversary could spoof DNS and just send out
> the valid, but outdated CRL(n-1) and potentially have quite a
> window of opportunity.
Hence the motivation for an Online Status service like OCSP.
Alternatively use the OCDP mechanism to provide a 'meta CRL'. A master
CRL can be issued every minute which would contain a list (CRLList) of
the most current CRLs in each partition.
This issue is orthogonal to the issue of directory discovery however.
Any infrastructure for distributing CRLs has the same problem. I don't
see that the solution is to attempt to guarantee delivery of the CRLs
by hypothesizing secure infrastructures will be installed. I believe
we should address the issue by removing the dependence.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24756 for ietf-pkix-bks; Thu, 29 Oct 1998 10:57:01 -0800 (PST)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24752 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 10:56:59 -0800 (PST)
From: salzr@certco.com
Received: (from uucp@localhost) by fwma1.certco.com (8.8.8/8.8.8) id NAA17758; Thu, 29 Oct 1998 13:59:15 -0500 (EST)
Received: from smtp.ma.certco.com(10.200.200.11) by fwma1.certco.com via smap (V2.1) id xma017756; Thu, 29 Oct 98 13:59:10 -0500
Received: from stig (stig.ma.certco.com [10.200.200.45]) by smtp.ma.certco.com (8.8.5/8.8.5) with SMTP id NAA12302; Thu, 29 Oct 1998 13:59:05 -0500 (EST)
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 13:59:04 -0500
Message-ID: <29E0A6D39ABED111A36000A0C99609CA18D2FA@macertco-srv1.ma.certco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <000a01be0352$2b946660$c807a8c0@pbaker-pc.verisign.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>If someone spoofed DNS the worst that would happen is that I would
>recieve a certificate I didn't trust (and would ignore) or no >certificate
at all.
Well, if you're only fetching certificates, probably.
But if you're fetching CRL's, then no. Suppose a cert is compromised,
and CRLn is issued before the "next update" time purely because of
that compromise. The adversary could spoof DNS and just send out
the valid, but outdated CRL(n-1) and potentially have quite a
window of opportunity.
/r$
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23068 for ietf-pkix-bks; Thu, 29 Oct 1998 07:36:01 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23064 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 07:36:00 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA08551; Thu, 29 Oct 1998 07:35:23 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA25873; Thu, 29 Oct 1998 07:37:35 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ron Ramsay" <Ron.Ramsay@OpenDirectory.com.au>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>, "Rick Harvey" <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:38:26 -0500
Message-ID: <000a01be0352$2b946660$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <D1A949D4508DD1119C8100400533BEDC0656BE@DSG1>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Phillip,
>
> Thanks for taking time to develop the example.
>
> Two issues:
>
> 1. Surely DNS is not secure?
Define secure? With the exception of a denial of service attack DNS
is 'secure enough' for this purpose since there is no trust placed
on the server. The origin of a signed message is irrelevant. Only
the signature is relevant.
> 2. Your example seems to be based on encryption using public keys. From
> what I know of the public key system, it is not used for encryption.
I think you are confusing DNS security here with PKIX. The two are very
separate.
If someone spoofed DNS the worst that would happen is that I would
recieve a certificate I didn't trust (and would ignore) or no certificate
at all.
>Its
> purpose is authentication and integrity. To bend your example, you will
> be encrypting your message with your own private key. How is an
> addressee to verify it was you who sent the message and that the message
> was not modified?
I send my signing certificate with the message. Or once the infrastructure
is deployed the recipient could use the SRV pointer to locate a directory
where a copy of the certificate was available.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22988 for ietf-pkix-bks; Thu, 29 Oct 1998 07:31:05 -0800 (PST)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA22984 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 07:31:04 -0800 (PST)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA28665; Thu, 29 Oct 1998 10:32:31 -0500
Message-Id: <3.0.5.32.19981029103331.039352b0@csmes.ncsl.nist.gov>
X-Sender: burr@csmes.ncsl.nist.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 29 Oct 1998 10:33:31 -0500
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
From: Bill Burr <william.burr@nist.gov>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4BC@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
I'm more than a little confused about what it is that makes X.500
directories particularly OO things. Is mashing the world into an X.500 DIT
an object oriented approach? There is a level of OO theology here that
seems beyond my grasp.
I think that we would want to think very hard about basing PKI names on
domain names. It seems desirable to make names in certificates more
directly related to the "real world" than domain names and e-mail addresses
often seem to be. But, if we are dong a PKI for the Internet (and isn't
this what PKIX is about?), then domain names and the DNS are the foundation
that we build the whole Internet on anyhow.
If the car, or perhaps the toll road operator, in your toll plaza example,
doesn't have a domain name, or an IP address, why is it the concern of
PKIX, which is, after all, an Internet standard group. Is it even
appropriate for the PKIX group to worry about things that don't relate to
the Internet?
I have been saying for some time that don't know of anybody who has built
an X.500 directory of a size that convinces me that it is a viable
technology to base a US national PKI, or even a US Federal government-wide
PKI on. I keep asking the question, where are the really big distributed
X.500 directories? Particularly multivendor directories. But I don't seem
to get any answers. What I hear are horror stories about the difficulties
of getting any two X.500 products to work together.
If the X.500 directory industry builds products that interoperate and scale
well, it has done a really bad job of getting the word out.
Until now, I have also been saying, does anybody have a believable
alternative to the mythological, pervasive X.500 directory service? It
seemed almost a rhetorical question. But I think perhaps Phill has
outlined an alternative, that looks like it probably ought to work, and is
based on something, DNS, that we know works well, scales well, and exists
now. Moreover, we should be able to create the service we need
incrementally, by just by adding servers as we need them, one at a time.
And, If I understand the proposal, all we have to do is agree on some
simple naming conventions.
That seems very, very appealing.
Once we accept domain names as the basis PKI naming, we are probably stuck
with it forever. Folks who aren't even on the Internet themselves, may
wind up getting domain names for PKI purposes. Perhaps the world would, in
the end, be a better place if we waited for X.500 directory technology to
mature, and then built a pervasive PKI DIT that has nothing to do with
Internet domain names. But solutions that we can get to work reasonably
well now, with a fairly small effort, usually seem to beat arguably better,
but more distant solutions.
At 10:52 AM 10/29/98 +1100, Alan Lloyd wrote:
>But why do this - this is yet more configuration and operational cost to
>large systems - and it means relating certificates and CAs to DNS when
>they are in fact (from an OO perspective) just attributes of
>objects/functions in real life. Ie a Car might have a key and
>certificate issued by a traffic controller or toll plaza - to deal with
>acqisition, identification and charging of the vehicle through Toll
>sections on a freeway. Where does DNS fit here? The "DNS SRV configure
>everything" route just seems to denegrate the , real life OO principles
>of directories - which are there so that we can get away from these
>machine level plumbing issues.
>
>I think of CAs as functions and certs that are applied to real life
>entities which are represented as attributes of objects in a business
>level directory system.
>
>Bashing DNS records into certs and CA operations and validation paths
>just complicates life with a higher operational costs and does not use
>the utility of distributed information infrastructures. Its like
>configuring every phone with every one elses phone number. When in fact
>we use the distributed telephone network and its directory system to
>avoid that.
>
>
>regards alan
>
>> -----Original Message-----
>> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
>> Sent: Thursday, 29 October 1998 6:02
>> To: Russ Housley; ietf-pkix@imc.org
>> Subject: RE: Scale (and the SRV record)
>>
>> Russ,
>>
>> You are right of course! Note that the scheme I propose allows a
>> certificate repository whose naming scheme is PKIX compatible to also
>> be
>> advertised. We might have:
>>
>> __pkix._http._tcp.arius.com
>> __pkix._ldap._tcp.arius.com
>> __pkix._finger._tcp.arius.com
>>
>> or even!
>>
>> __pkix._verynewprotocol.arius.com
>>
>> And since an SRV record is simply an MX record on steroids each
>> can define server priorities and preferences.
>>
>> What would then be required is a draft describing the naming
>> conventions such a server would conform to and how clients should
>> interpret the scope of the statement. __pkix._http._tcp.arius.com
>> is essentially saying "look at the corresponding server where you
>> will find a PKIX repository whose scope includes (all?) certificates
>> issued which are bound to DNS names within the scope 'arius.com'."
>>
>> Alan will have a directory there (we presume) as I would expect
>> would most enterprises. There might be a move in favour of an HTTP
>> service acting as a border directory and an LDAP server providing
>> a more flexible, searchable service inside the enterprise.
>>
>> Phill
>>
>> > -----Original Message-----
>> > From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On
>> Behalf
>> > Of Russ Housley
>> > Sent: Wednesday, October 28, 1998 1:29 PM
>> > To: Alan Lloyd
>> > Cc: ietf-pkix@imc.org
>> > Subject: Scale (and the SRV record)
>> >
>> >
>> > Alan asks:
>> >
>> > > I need to be enlightened - How does one deploy a large scale
>> distributed
>> > > PKI without a large scale object oriented distributed (and
>> protected by
>> > > ACI, etc) directory system?
>> >
>> > Directory is the preferred certificate repository, but it is not the
>> only
>> > repository that will scale. People have used FTP, Finger, HTTP, and
>> other
>> > mechanisms to distribute certificates.
>> >
>> > The PKI is not dependent on the deployment of a Directory, as these
>> other
>> > mechanism can be used until the Directory become widely available.
>> >
>> > Further, a trusted repository is not a requirement. Since
>> > certificates and
>> > CRLs are signed, the repository cannot make undetected modification
>> to the
>> > data structures. Denial of service is allways an issue; it is a
>> > concern in
>> > all of the possible repository alternatives.
>> >
>> > Russ
>> >
>> >
>
>
Regards,
Bill Burr
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22878 for ietf-pkix-bks; Thu, 29 Oct 1998 07:21:36 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22874 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 07:21:35 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA08302; Thu, 29 Oct 1998 07:21:05 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA25200; Thu, 29 Oct 1998 07:23:16 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Bill Burr" <william.burr@nist.gov>, "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:24:07 -0500
Message-ID: <000801be0350$2b396000$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <3.0.5.32.19981028172103.03924b80@csmes.ncsl.nist.gov>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Phill,
>
> I'm in a bit over my head here now (arguably I have been all along),
> because I don't understand SRVs very well, and I had the impression that
> they're more a proposal than a reality. Would we be betting on the come
> here? Or is support SRVs really in DNS servers and resolvers now?
The proposal is actually quite old - the RFC has been out for two years
as 'experimental'. But the code is widely deployed in the bind code, not
surprising sinc Paul Vixie was the author of the SRV draft and the re-author
of bind.
The Vixie-bind code is greatly preferred over its predecessors in any
case since it has considerable proofing against DNS spoofing attacks added.
Irresprective of whether a site was to use SRV they should upgrade to
the latest release of bind.
The Microsoft situation is slightly different. I could not persuade my
NT DNS server to accept an SRV record, but as Microsoft stated at the TWG
they are awfully keen on it. Basically the SRV record is the glue between
the DNS system and active directory it appears.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22590 for ietf-pkix-bks; Thu, 29 Oct 1998 06:41:10 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22586 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 06:41:09 -0800 (PST)
Received: id JAA19380; Thu, 29 Oct 1998 09:34:00 -0500
Received: by gateway id <V6M8VRQC>; Thu, 29 Oct 1998 09:31:25 -0500
Message-ID: <D789F71F24B4D111955D00A0C99B4F5001789133@sothmxs01.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: ietf-pkix@imc.org, "'Robert Klerer'" <klerer@xhair.com>
Subject: RE: email oid
Date: Thu, 29 Oct 1998 09:29:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi,
> ----------
> From: Robert Klerer[SMTP:klerer@xhair.com]
> Sent: Thursday, October 29, 1998 8:18 AM
> To: ietf-pkix@imc.org
> Subject: email oid
>
> The other day in trying to accommodate a legacy pki, I ran into a
> problem
> with an oid specified in draft-ietf-pkix-ipki-part1-11...
>
"Legacy PKI". There's a term I haven't heard before.
PKIX has certainly come a long way in a short time... :-)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22379 for ietf-pkix-bks; Thu, 29 Oct 1998 06:15:06 -0800 (PST)
Received: from Sonnet.GSC.GTE.Com (Sonnet.GSC.GTE.Com [131.131.251.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22375 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 06:15:04 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 1313"@gscex01.ndhm.gtegsc.com [155.95.162.170]) by Sonnet.GSC.GTE.Com (PMDF V5.2-27 #29038) with ESMTP id <01J3JDBCIBMQ000DBO@Sonnet.GSC.GTE.Com> for ietf-pkix@imc.org; Thu, 29 Oct 1998 09:16:57 -0400 (EDT)
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.0.1460.8) id <VNQY4F6A>; Thu, 29 Oct 1998 09:14:09 -0500
Content-return: allowed
Date: Thu, 29 Oct 1998 09:17:15 -0500
From: "Wang, John" <John.Wang@CyberTrust.GTE.Com>
Subject: RE: email oid
To: "'Robert Klerer'" <klerer@xhair.com>, ietf-pkix@imc.org
Message-id: <F97906F6A12CD211AF5D00805F0DB87814D790@ndhm08.ndhm.gtegsc.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
It was my understanding that the RSA-pkcs-9 email address OID
(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
think you can remove the RSA oid but perhaps add the RFC1274 oid
if there is a demand for it.
-----Original Message-----
From: Robert Klerer [mailto:klerer@xhair.com]
Sent: Thursday, October 29, 1998 8:19 AM
To: ietf-pkix@imc.org
Subject: email oid
The other day in trying to accommodate a legacy pki, I ran into a problem
with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
that the oid used for an email address in the distinguished name is
1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
as specified in RFC1274.
Since I believe that the intention is for both of these oids are meant to
represent attributes that hold the same information, this discrepancy may
cause confusion and failures in the future. My suggestion would be to
change part1 to refer to the more commonly used OID.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA22075 for ietf-pkix-bks; Thu, 29 Oct 1998 05:16:21 -0800 (PST)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA22071 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 05:16:19 -0800 (PST)
Received: from klerer.basit.com (shiva112 [128.209.144.112]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id IAA18504 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 08:18:04 -0500 (EST)
Message-ID: <001201be033e$a3e06380$010ed180@klerer.basit.com>
From: "Robert Klerer" <klerer@xhair.com>
To: <ietf-pkix@imc.org>
Subject: email oid
Date: Thu, 29 Oct 1998 08:18:37 -0500
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 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
The other day in trying to accommodate a legacy pki, I ran into a problem
with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
that the oid used for an email address in the distinguished name is
1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
as specified in RFC1274.
Since I believe that the intention is for both of these oids are meant to
represent attributes that hold the same information, this discrepancy may
cause confusion and failures in the future. My suggestion would be to
change part1 to refer to the more commonly used OID.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA19448 for ietf-pkix-bks; Thu, 29 Oct 1998 02:33:04 -0800 (PST)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19444 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 02:33:02 -0800 (PST)
Received: from stefans (t1o68p32.telia.com [62.20.138.32]) by maila.telia.com (8.8.8/8.8.8) with SMTP id LAA18941; Thu, 29 Oct 1998 11:35:09 +0100 (CET)
Message-Id: <3.0.32.19981029113047.00a11bd0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 29 Oct 1998 11:31:27 +0100
To: Anders Rundgren <anders.rundgren@jaybis.com>, "'SEIS-List'" <list@seis.nc-forum.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: Unmistakable Identity (Was: Internet draft for Qualified Certificates.)
Cc: ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA19445
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Anders,
I see your problems but fail to see in what way they are unique to digital
agreements.
Many long term contracts are drawn up using "non static" ID-attributes.
They work so I'm convinced that they would work if they are signed through
digital mechanisms.
Clearly the requirements on a supporting infrastructure will differ
dependent on which ID-attributes that are used. But that's outside the
scope of this draft.
Secondly all ID-attributes have different characteristics. I wouldn't know
how to categorize them in a way that is internationally meaningful. You are
free though to propose any writing in this sense.
/Stefan
At 10:15 AM 10/29/98 +0100, Anders Rundgren wrote:
>Stefan,
>New try with this Unmistakable business:
>
>Assumptions
> Users have SEIS EID certificates (qualified I assume) based on the
proposed CP
> The certificate-relaying party is a computer program
> The certificate-relaying part and the certificate-subject have a
long-term relation
>
>Now I try to apply the algorithm from the I-D that says that an
*unmistakable* name
>should be created by combining Name, civicRegNr etc..
>
>Statement 1: By combining the name of physical persons in Sweden with other
>attributes to form an unmistakable identity, the chance that some future
certificate
>for a certain person will fail during authentication due to name changes
is around *20%*!
>Unless of course the certificate-relying party is free to ask the CA
>questions like: Was XYX formerly known as DFT?
>
>Statement 2: By only using civicRegNr (which departs from the I-D
definition) this risk
>goes down to a mere *0.001%*.
>
>Do I smell interoperability problems and confusion? Lots of it. I was
actually recommended
>by one major EID-vendor (who's identity will remain in secret) to use the
entire certificate (!!!)
>as a key in authentication so even the s.c professionals have problems
with this part.
>
>
>Now to this *static* thing. That there is currently no room in the I-D
for the definition
>of such a characteristic is a serious omission. This is as you pointed
out a market and
>legislative issue so it is very important for certificate-subjects and
certificate-relying
>parties to know what they can expect. And for issuers to point out in
their marketing.
>Note that this has nothing to do with recommendations
>
>Anders
>
>----------
>From: Stefan Santesson [SMTP:stefan@accurata.se]
>Sent: Wednesday, October 28, 1998 17:07
>To: 'SEIS-List'
>Subject: RE: Internet draft for Qualified Certificates.
>
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Anders,
>
>An unmistakable name doesn't have to be static. It is unmitakable as long
>as the relying party can use the name to identiy the subject for as long as
>the certificate is valid and not revoked.
>
>It is at this moment outside the scope of this I-D to make any requirements
>on how static a name should be. This is up to the CA to decide and up to
>the relying party to accept.
>
>/Stefan
>
>
>At 04:17 PM 10/28/98 +0100, Anders Rundgren wrote:
>>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>>
>>Stefan, I still have some serious problems with the definitions and
>interpretations.
>>
>>>>How does a certificate-relying party know what fields form
>>>>an unmistakable name of the subject?
>>>>
>>>>Unmistakable is different from static identity I guess?
>>>>
>>>>Anders
>>
>>>An unmistakable name of the subject SHALL be obtained by combining the
>value of the subjects
>>>registered name attributes or pseudonym attributes, with the values of
>the following attribute
>>>types;
>>>countryName
>>>civicRegistrationNumber
>>>serialNumber
>>>organizationName
>>>organizationalUnitName
>>>postalAddress
>>
>>To me a Swedish EID forms an unmistakable subject identity (99.999%) by just
>>using civicRegistrationNumber.
>>
>>By using the other (non-static) attributes you loose unmistakable. You
>just have to change
>>employer to break it!
>>
>>I would also like to see the *static* identity possibility covered by the
>draft. I.e. it should
>>be clear for a certificate-relaying party if is unmistakable in the way
>you use that
>>word in other contexts.
>>
>>Anders
>>
>>
>>
>>----------------- SEIS mailing list (list@seis.nc-forum.com)
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: info@seis.se
>>
>>
>>
>-------------------------------------------------------------------
>Stefan Santesson <stefan@accurata.se>
>Accurata Systemsäkerhet AB
>Lotsgatan 27 D Tel. +46-40 152211
>216 42 Malmö Fax. +46-40 150790
>Sweden Mobile +46-70 5247799
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>
>
>----------------- SEIS mailing list (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29403 for ietf-pkix-bks; Wed, 28 Oct 1998 20:55:19 -0800 (PST)
Received: from mail.innetix.com (oldmail.innetix.com [207.126.108.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29398 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 20:55:17 -0800 (PST)
Received: from iris (user46.sj.dialup.innetix.com [209.172.68.109]) by mail.innetix.com (8.8.7/8.8.5) with SMTP id UAA11246; Wed, 28 Oct 1998 20:49:32 -0800 (PST)
Message-Id: <3.0.2.32.19981028205654.006dfab8@innetix.com>
X-Sender: bruceg@innetix.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32)
Date: Wed, 28 Oct 1998 20:56:54 -0800
To: Bill Burr <william.burr@nist.gov>, "Phillip M Hallam-Baker" <pbaker@verisign.com>, "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
From: Bruce Greenblatt <bruceg@innetix.com>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <3.0.5.32.19981028172103.03924b80@csmes.ncsl.nist.gov>
References: <001501be02a5$77fd4920$c807a8c0@pbaker-pc.verisign.com> <4.1.19981028132138.009c32b0@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I know the answer to this one... SRV records are a reality, and are
supported in the current version of Bind (the most common implementation).
It is also my understanding that several other implementations have support
for SRV records. Another interesting DNS resource record that could be
useful in this area is the NAPTR record. Note that SRV records are defined
in RFC 2052, and NAPTR records are defined in RFC 2168.
Bruce
At 05:21 PM 10/28/98 -0500, Bill Burr wrote:
>Phill,
>
>I'm in a bit over my head here now (arguably I have been all along),
>because I don't understand SRVs very well, and I had the impression that
>they're more a proposal than a reality. Would we be betting on the come
>here? Or is support SRVs really in DNS servers and resolvers now?
>
>
>Regards,
>
>Bill Burr
>
>
================================================
Bruce Greenblatt bruceg@innetix.com
http://www.innetix.com/~bruceg
================================================
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27961 for ietf-pkix-bks; Wed, 28 Oct 1998 16:13:19 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27955 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 16:13:11 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PJM>; Thu, 29 Oct 1998 11:10:59 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0656BE@DSG1>
From: Ron Ramsay <Ron.Ramsay@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org, Rick Harvey <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 11:10:57 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phillip,
Thanks for taking time to develop the example.
Two issues:
1. Surely DNS is not secure?
2. Your example seems to be based on encryption using public keys. From
what I know of the public key system, it is not used for encryption. Its
purpose is authentication and integrity. To bend your example, you will
be encrypting your message with your own private key. How is an
addressee to verify it was you who sent the message and that the message
was not modified?
Ron.
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Thursday, October 29, 1998 3:37 AM
> To: Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan issued the following challenge,
>
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
>
> Seems like a good question, it occured to me that now is a good time
> to
> raise it.
>
> Look at the one already deployed and work it out. The SSL secured part
> of
> the Web does not stop working if directory.verisign.com goes down.
>
> I have had this arguement before with the hypertext establishment.
> They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were
> completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L
> to
> give the keynote!
>
> The greater the scale the less weight a base information system can
> carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of
> consistency
> across transactions. Finally at global scale it is not practical to
> deal in
> data, we must deal in names instead, names in this case being of
> Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live)
> to
> make the DNS sytem tractable, precisely because they have Sebok's
> 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
>
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
>
> Making PKI scale to global reach is no more than a matter of naming.
> Bind
> the network level directory infrastructures to the internet naming
> system
> which is and will continue to be DNS.
>
> There is already a DNS resource record defined for the purpose - SRV.
> If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
>
> Email client is to send to fred@arius.com, there is no cert in the
> address
> book:
>
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> _ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> _ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> _ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest
> priority
> number which offers a directory protocol that is understood,
> in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> fred@arius.com
> 5) The client retrieves the certificates for the entry, there are
> three
> of which one is a currently valid one for fred@arius.com
> 6) The client encrypts the email
> 7) The client sends the email
>
>
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
>
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
>
>
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
>
>
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
>
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
>
> __pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> __pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> __pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
>
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
>
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
>
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have
> deployed.
>
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
>
>
> Phill
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27953 for ietf-pkix-bks; Wed, 28 Oct 1998 16:13:03 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27948 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 16:12:59 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PJL>; Thu, 29 Oct 1998 11:10:41 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4BE@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Paul Koning'" <pkoning@xedia.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 11:10:39 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I think the response I gave was about denial/system integrity re getting
CRLs or not with master/replicas.
As LDAP is now much bigger than DAP (with half the functionality) I
would rather call LDAP HDAP and DAP EDAP (efficient DAP) :-)
I agree that no matter what protocol you use, denial of service is an
issue as protocols cannot prevent hogging by other or someone switching
the machine off.
The real issue is that some protocols (not simple or lightweight ones)
provide system selection features (chaining/replication selection
control) and the use of these assist with system operation and
information integrity ie. improve reliability and trust.
regards alan
> -----Original Message-----
> From: Paul Koning [SMTP:pkoning@xedia.com]
> Sent: Thursday, 29 October 1998 11:02
> To: Alan.Lloyd@OpenDirectory.com.au
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> >>>>> "Alan" == Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> writes:
>
> >> -----Original Message----- From: salzr@certco.com
> >> [SMTP:salzr@certco.com] Sent: Thursday, 29 October 1998 5:56 To:
> >> 'Russ Housley'; Alan Lloyd Cc: ietf-pkix@imc.org Subject: RE:
> >> Scale (and the SRV record)
> >>
> >> >Denial of service is allways an issue; it is a concern in >all of
> >> the possible repository alternatives.
> >>
> >> At the risk of stating the obvious, a denial of service that
> >> prevents you from getting revocation information (such as a CRL)
> >> can be Very Bad, given the implementation quality of most network
> >> services that I've seen...
> Alan> [Alan Lloyd] Yes, and we enforce that risk by saying LDAP is
> Alan> the way to go. :-)
>
> How so? I've never heard of a protocol that's immune to denial of
> service attack. Why would replacing LDAP by HDAP help?
>
> paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27850 for ietf-pkix-bks; Wed, 28 Oct 1998 16:00:06 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27845 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 16:00:05 -0800 (PST)
Received: from xedia.com by relay1.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfncq13061; Wed, 28 Oct 1998 19:01:33 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01892; Wed, 28 Oct 98 18:59:51 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id TAA04116; Wed, 28 Oct 1998 19:01:31 -0500
Date: Wed, 28 Oct 1998 19:01:31 -0500
Message-Id: <199810290001.TAA04116@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Alan.Lloyd@OpenDirectory.com.au
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC05D4B6@DSG1>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>>>>> "Alan" == Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> writes:
>> -----Original Message----- From: salzr@certco.com
>> [SMTP:salzr@certco.com] Sent: Thursday, 29 October 1998 5:56 To:
>> 'Russ Housley'; Alan Lloyd Cc: ietf-pkix@imc.org Subject: RE:
>> Scale (and the SRV record)
>>
>> >Denial of service is allways an issue; it is a concern in >all of
>> the possible repository alternatives.
>>
>> At the risk of stating the obvious, a denial of service that
>> prevents you from getting revocation information (such as a CRL)
>> can be Very Bad, given the implementation quality of most network
>> services that I've seen...
Alan> [Alan Lloyd] Yes, and we enforce that risk by saying LDAP is
Alan> the way to go. :-)
How so? I've never heard of a protocol that's immune to denial of
service attack. Why would replacing LDAP by HDAP help?
paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27812 for ietf-pkix-bks; Wed, 28 Oct 1998 15:54:44 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27808 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:54:36 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PJD>; Thu, 29 Oct 1998 10:52:23 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4BC@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:52:22 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
But why do this - this is yet more configuration and operational cost to
large systems - and it means relating certificates and CAs to DNS when
they are in fact (from an OO perspective) just attributes of
objects/functions in real life. Ie a Car might have a key and
certificate issued by a traffic controller or toll plaza - to deal with
acqisition, identification and charging of the vehicle through Toll
sections on a freeway. Where does DNS fit here? The "DNS SRV configure
everything" route just seems to denegrate the , real life OO principles
of directories - which are there so that we can get away from these
machine level plumbing issues.
I think of CAs as functions and certs that are applied to real life
entities which are represented as attributes of objects in a business
level directory system.
Bashing DNS records into certs and CA operations and validation paths
just complicates life with a higher operational costs and does not use
the utility of distributed information infrastructures. Its like
configuring every phone with every one elses phone number. When in fact
we use the distributed telephone network and its directory system to
avoid that.
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Thursday, 29 October 1998 6:02
> To: Russ Housley; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> Russ,
>
> You are right of course! Note that the scheme I propose allows a
> certificate repository whose naming scheme is PKIX compatible to also
> be
> advertised. We might have:
>
> __pkix._http._tcp.arius.com
> __pkix._ldap._tcp.arius.com
> __pkix._finger._tcp.arius.com
>
> or even!
>
> __pkix._verynewprotocol.arius.com
>
> And since an SRV record is simply an MX record on steroids each
> can define server priorities and preferences.
>
> What would then be required is a draft describing the naming
> conventions such a server would conform to and how clients should
> interpret the scope of the statement. __pkix._http._tcp.arius.com
> is essentially saying "look at the corresponding server where you
> will find a PKIX repository whose scope includes (all?) certificates
> issued which are bound to DNS names within the scope 'arius.com'."
>
> Alan will have a directory there (we presume) as I would expect
> would most enterprises. There might be a move in favour of an HTTP
> service acting as a border directory and an LDAP server providing
> a more flexible, searchable service inside the enterprise.
>
> Phill
>
> > -----Original Message-----
> > From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On
> Behalf
> > Of Russ Housley
> > Sent: Wednesday, October 28, 1998 1:29 PM
> > To: Alan Lloyd
> > Cc: ietf-pkix@imc.org
> > Subject: Scale (and the SRV record)
> >
> >
> > Alan asks:
> >
> > > I need to be enlightened - How does one deploy a large scale
> distributed
> > > PKI without a large scale object oriented distributed (and
> protected by
> > > ACI, etc) directory system?
> >
> > Directory is the preferred certificate repository, but it is not the
> only
> > repository that will scale. People have used FTP, Finger, HTTP, and
> other
> > mechanisms to distribute certificates.
> >
> > The PKI is not dependent on the deployment of a Directory, as these
> other
> > mechanism can be used until the Directory become widely available.
> >
> > Further, a trusted repository is not a requirement. Since
> > certificates and
> > CRLs are signed, the repository cannot make undetected modification
> to the
> > data structures. Denial of service is allways an issue; it is a
> > concern in
> > all of the possible repository alternatives.
> >
> > Russ
> >
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27669 for ietf-pkix-bks; Wed, 28 Oct 1998 15:22:52 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27665 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:22:49 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P20>; Thu, 29 Oct 1998 10:20:36 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4BA@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Sean Turner'" <turners@ieca.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:20:36 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sean, I agree. But there are windows - ie, if a master gets a CRL when
one does not already exist and it has not propagated to the replicas -
then there is a window in which a cert could be deemed valid when it
isnt. ie. We can chose to accept replication delays or we can get higher
trust by requesting cert path objects from the master DSA (using DAP).
Its just a timing hole that system designers with LDAP should watch out
for.
regards alan
> -----Original Message-----
> From: Sean Turner [SMTP:turners@ieca.com]
> Sent: Thursday, 29 October 1998 10:10
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: Re: Scale (and the SRV record)
>
> Alan Lloyd wrote:
> >
> > > -----Original Message-----
> > > From: salzr@certco.com [SMTP:salzr@certco.com]
> > > Sent: Thursday, 29 October 1998 5:56
> > > To: 'Russ Housley'; Alan Lloyd
> > > Cc: ietf-pkix@imc.org
> > > Subject: RE: Scale (and the SRV record)
> > >
> > > >Denial of service is allways an issue; it is a concern in
> > > >all of the possible repository alternatives.
> > >
> > > At the risk of stating the obvious, a denial of service that
> > > prevents you from getting revocation information (such as a
> > > CRL) can be Very Bad, given the implementation quality of most
> > > network services that I've seen...
> > [Alan Lloyd]
> > Yes, and we enforce that risk by saying LDAP is the way to
> go.
> > :-)
> > "Dont Use Copy" - see X.511 (DAP) and knowing master DSAs
> is
> > good.
> >
> > regards
>
> Alan,
>
> You can use a shadowed copy of a CRL or a master copy it doesn't
> matter it's a signed object.
>
> spt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27618 for ietf-pkix-bks; Wed, 28 Oct 1998 15:18:18 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27614 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:18:09 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P27>; Thu, 29 Oct 1998 10:15:56 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B9@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>
Cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 29 Oct 1998 10:15:55 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Agree Lynn. We (OpenDirectory) are obviously directory centric and its
that view that sees the issues you describe. Most organisations have
high cost information islands for all sorts of reasons - and as they try
to reduce operating costs and optimise information management then the
directory approach works well. In fact its designed exactly for that.
One cannot add to information islands supporting service delivery a PKI
unless one wants more costs and more risk. So its "consolidate (into OO)
and then authenticate" is the way to go.
We see directories as the new wave in distributed OO engineering for all
forms of business information infrastructures. I think there has been a
view that directories are about email address books, white pages and
DNS. And this of course is just a limited subset of the directory
capability.
regards alan
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Thursday, 29 October 1998 3:28
> To: Alan Lloyd
> Cc: 'Phillip M Hallam-Baker'; Al Arsenault; Stephen Kent;
> ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> small note ... from business standpoint ... it might be better
> explained
> that no directories no authentication infrastructure (which is the
> business
> process/requirement) ... a PKI is then a method of implementing that
> infrastructure. Part of the problem with starting with PKI as a
> solution
> and then asking what the problem is .... one might might be led into
> presuming that some of the existing PKIs deployed for independent
> pilots
> are the structure one would automatically use as an integrated
> business
> solution.
>
> directories actually have other business needs independent of the
> authentication infrastructure. in past life, looked at one customer
> that
> had on the order of 6000 RDBMS where 90% of the data was common.
> schema
> integration directory was needed just so that simple things like
> changing
> the name on an account is consistently done thruout the business (side
> problem was wide variety of different terms that were used in schemas
> for
> common things like name).
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27548 for ietf-pkix-bks; Wed, 28 Oct 1998 15:12:22 -0800 (PST)
Received: from hq.vni.net (hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27544 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:12:20 -0800 (PST)
Received: from ieca.com (nova-aaa-016.vni.net [205.177.115.16]) by hq.vni.net (8.8.8/8.8.5) with ESMTP id SAA00993; Wed, 28 Oct 1998 18:13:44 -0500 (EST)
Message-ID: <3637A43D.933C47D4@ieca.com>
Date: Wed, 28 Oct 1998 18:09:50 -0500
From: Sean Turner <turners@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
CC: ietf-pkix@imc.org
Subject: Re: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC05D4B6@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan Lloyd wrote:
>
> > -----Original Message-----
> > From: salzr@certco.com [SMTP:salzr@certco.com]
> > Sent: Thursday, 29 October 1998 5:56
> > To: 'Russ Housley'; Alan Lloyd
> > Cc: ietf-pkix@imc.org
> > Subject: RE: Scale (and the SRV record)
> >
> > >Denial of service is allways an issue; it is a concern in
> > >all of the possible repository alternatives.
> >
> > At the risk of stating the obvious, a denial of service that
> > prevents you from getting revocation information (such as a
> > CRL) can be Very Bad, given the implementation quality of most
> > network services that I've seen...
> [Alan Lloyd]
> Yes, and we enforce that risk by saying LDAP is the way to go.
> :-)
> "Dont Use Copy" - see X.511 (DAP) and knowing master DSAs is
> good.
>
> regards
Alan,
You can use a shadowed copy of a CRL or a master copy it doesn't
matter it's a signed object.
spt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27194 for ietf-pkix-bks; Wed, 28 Oct 1998 14:38:13 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27188 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:38:02 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2V>; Thu, 29 Oct 1998 09:35:45 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B8@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 09:35:45 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill - you have missed the point I think. Its not a DNS issue or an SSL
issue or a certificate structure issue.
PKI from many people's perspective is about applying cryptographic
techniques to current business information systems. These information
systems support services to the masses over a wider environment. ie the
generic business model is to authenticate uses at a number of levels,
allow service profiles to be applied to those users and verify
transactions by those users at the originating and the recipient end of
the business. And this must occur across a multi domain environment. The
foundation of all this is information sets related to Users and Services
and because these need to be globally named, distributed and protected
(and evolving to OO paradigms) then the directory serves this
requirement. PKIs are applied to this evolution. They DONT create it.
ie. DNS is about host / domain names for computers to relate IP
addresses .ie machiney level things. Its not OO in my book.
X.500 is about OO application to real life entities such as ships,
people, workflow applications, library books, Media content, Users, etc.
real named items with real life attributes with real life privileges.
X.500 is being deployed in masses....with PKIs and a lot faster than
PKIs on their own - reason already stated.
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Thursday, 29 October 1998 3:37
> To: Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan issued the following challenge,
>
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
>
> Seems like a good question, it occured to me that now is a good time
> to
> raise it.
>
> Look at the one already deployed and work it out. The SSL secured part
> of
> the Web does not stop working if directory.verisign.com goes down.
>
> I have had this arguement before with the hypertext establishment.
> They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were
> completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L
> to
> give the keynote!
>
> The greater the scale the less weight a base information system can
> carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of
> consistency
> across transactions. Finally at global scale it is not practical to
> deal in
> data, we must deal in names instead, names in this case being of
> Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live)
> to
> make the DNS sytem tractable, precisely because they have Sebok's
> 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
>
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
>
> Making PKI scale to global reach is no more than a matter of naming.
> Bind
> the network level directory infrastructures to the internet naming
> system
> which is and will continue to be DNS.
>
> There is already a DNS resource record defined for the purpose - SRV.
> If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
>
> Email client is to send to fred@arius.com, there is no cert in the
> address
> book:
>
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> _ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> _ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> _ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest
> priority
> number which offers a directory protocol that is understood,
> in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> fred@arius.com
> 5) The client retrieves the certificates for the entry, there are
> three
> of which one is a currently valid one for fred@arius.com
> 6) The client encrypts the email
> 7) The client sends the email
>
>
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
>
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
>
>
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
>
>
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
>
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
>
> __pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> __pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> __pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
>
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
>
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
>
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have
> deployed.
>
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
>
>
> Phill
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27036 for ietf-pkix-bks; Wed, 28 Oct 1998 14:24:35 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27032 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:24:32 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2T>; Thu, 29 Oct 1998 09:22:20 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B7@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>
Cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 29 Oct 1998 09:22:17 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Perhaps one of the approaches here is to put public information into
"Border" or Public DSAs that serve the external interactions of an
organisation - as Read Only systems.
These DSAs are used to protect aggregation threats and possibly
name/semantic dissemination. Some systems being designed explicitly
state such devices with trusted oneway/mapping replication unctions from
the core internal systems.
regards alan
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Thursday, 29 October 1998 4:21
> To: Alan Lloyd
> Cc: 'Phillip M Hallam-Baker'; Al Arsenault; Stephen Kent;
> ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> ... and the other serious problem that is starting to show up is the
> privacy issues related to information that might be in a directory
> ....
> even a name field might represent a privacy concern.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26999 for ietf-pkix-bks; Wed, 28 Oct 1998 14:21:27 -0800 (PST)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26995 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:21:26 -0800 (PST)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id RAA22220; Wed, 28 Oct 1998 17:20:04 -0500
Message-Id: <3.0.5.32.19981028172103.03924b80@csmes.ncsl.nist.gov>
X-Sender: burr@csmes.ncsl.nist.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Oct 1998 17:21:03 -0500
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>, "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
From: Bill Burr <william.burr@nist.gov>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <001501be02a5$77fd4920$c807a8c0@pbaker-pc.verisign.com>
References: <4.1.19981028132138.009c32b0@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill,
I'm in a bit over my head here now (arguably I have been all along),
because I don't understand SRVs very well, and I had the impression that
they're more a proposal than a reality. Would we be betting on the come
here? Or is support SRVs really in DNS servers and resolvers now?
Regards,
Bill Burr
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26975 for ietf-pkix-bks; Wed, 28 Oct 1998 14:19:41 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26971 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:19:39 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2S>; Thu, 29 Oct 1998 09:17:26 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B6@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'salzr@certco.com'" <salzr@certco.com>, "'Russ Housley'" <housley@spyrus.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 09:17:25 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> -----Original Message-----
> From: salzr@certco.com [SMTP:salzr@certco.com]
> Sent: Thursday, 29 October 1998 5:56
> To: 'Russ Housley'; Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> >Denial of service is allways an issue; it is a concern in
> >all of the possible repository alternatives.
>
> At the risk of stating the obvious, a denial of service that
> prevents you from getting revocation information (such as a
> CRL) can be Very Bad, given the implementation quality of most
> network services that I've seen...
[Alan Lloyd]
Yes, and we enforce that risk by saying LDAP is the way to go.
:-)
"Dont Use Copy" - see X.511 (DAP) and knowing master DSAs is
good.
regards
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26953 for ietf-pkix-bks; Wed, 28 Oct 1998 14:17:35 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26949 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:17:32 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2R>; Thu, 29 Oct 1998 09:15:16 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B5@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Russ Housley'" <housley@spyrus.com>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 09:15:15 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> -----Original Message-----
> From: Russ Housley [SMTP:housley@spyrus.com]
> Sent: Thursday, 29 October 1998 5:29
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan asks:
>
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
>
> Directory is the preferred certificate repository, but it is not the
> only
> repository that will scale. People have used FTP, Finger, HTTP, and
> other
> mechanisms to distribute certificates.
[Alan Lloyd]
Distribution of certificates is not the issue.
How as a recipient of signed messages follow multiplecertificate
paths - without a directory?.
> The PKI is not dependent on the deployment of a Directory, as these
> other
> mechanism can be used until the Directory become widely available.
[Alan Lloyd] But as I have said, they are bespoke, do not tie
well to business and customer management/ service delivery models or
distributed , transaction based information systems over a wide scale -
efficiently.
> Further, a trusted repository is not a requirement. Since
> certificates and
> CRLs are signed, the repository cannot make undetected modification to
> the
> data structures. Denial of service is allways an issue; it is a
> concern in
> all of the possible repository alternatives.
[Alan Lloyd] Agree
> Russ
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25206 for ietf-pkix-bks; Wed, 28 Oct 1998 10:59:50 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25202 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:59:49 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA21485; Wed, 28 Oct 1998 10:59:15 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA00840; Wed, 28 Oct 1998 11:01:27 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 14:02:11 -0500
Message-ID: <001501be02a5$77fd4920$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <4.1.19981028132138.009c32b0@mail.spyrus.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Russ,
You are right of course! Note that the scheme I propose allows a
certificate repository whose naming scheme is PKIX compatible to also be
advertised. We might have:
__pkix._http._tcp.arius.com
__pkix._ldap._tcp.arius.com
__pkix._finger._tcp.arius.com
or even!
__pkix._verynewprotocol.arius.com
And since an SRV record is simply an MX record on steroids each
can define server priorities and preferences.
What would then be required is a draft describing the naming
conventions such a server would conform to and how clients should
interpret the scope of the statement. __pkix._http._tcp.arius.com
is essentially saying "look at the corresponding server where you
will find a PKIX repository whose scope includes (all?) certificates
issued which are bound to DNS names within the scope 'arius.com'."
Alan will have a directory there (we presume) as I would expect
would most enterprises. There might be a move in favour of an HTTP
service acting as a border directory and an LDAP server providing
a more flexible, searchable service inside the enterprise.
Phill
> -----Original Message-----
> From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On Behalf
> Of Russ Housley
> Sent: Wednesday, October 28, 1998 1:29 PM
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
>
> Alan asks:
>
> > I need to be enlightened - How does one deploy a large scale distributed
> > PKI without a large scale object oriented distributed (and protected by
> > ACI, etc) directory system?
>
> Directory is the preferred certificate repository, but it is not the only
> repository that will scale. People have used FTP, Finger, HTTP, and other
> mechanisms to distribute certificates.
>
> The PKI is not dependent on the deployment of a Directory, as these other
> mechanism can be used until the Directory become widely available.
>
> Further, a trusted repository is not a requirement. Since
> certificates and
> CRLs are signed, the repository cannot make undetected modification to the
> data structures. Denial of service is allways an issue; it is a
> concern in
> all of the possible repository alternatives.
>
> Russ
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25184 for ietf-pkix-bks; Wed, 28 Oct 1998 10:57:34 -0800 (PST)
Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25180 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:57:33 -0800 (PST)
Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA00269; Wed, 28 Oct 1998 13:59:19 -0500 (EST)
Message-Id: <199810281859.NAA00269@jekyll.piermont.com>
To: WHenry <WHenry@pec.com>
cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Wed, 28 Oct 1998 12:42:33 EST." <3C7EABA3F6F1D1118FD90008C7F450FDA65C16@exchang-fairfax.pec.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 28 Oct 1998 13:59:19 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
WHenry writes:
> The problem with this remark is that 9/10 of all SSL sites are using SSLv2,
> and there is no "real" authentication happening here.
>
> Example... just because Verisign's cert is posted in my browser doesn't
> mean:
> 1. I should trust that this embedded cert is valid, and
> 2. I should trust an online vendor that he/she is who they say they
> are.
>
> Verisign's own Certification Practice Statement (CPS) says it all: Versign
> is not liable for verifying the identity of certificate users.
Reminds me of four different talks given at the Usenix E.C. conference
a couple of months ago, all of which were of the substance "third
party certificates with liability disclaimers are worthless..."
.pm
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25166 for ietf-pkix-bks; Wed, 28 Oct 1998 10:54:42 -0800 (PST)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25162 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:54:41 -0800 (PST)
From: salzr@certco.com
Received: (from uucp@localhost) by fwma1.certco.com (8.8.8/8.8.8) id NAA01272; Wed, 28 Oct 1998 13:56:38 -0500 (EST)
Received: from smtp.ma.certco.com(10.200.200.11) by fwma1.certco.com via smap (V2.1) id xma001267; Wed, 28 Oct 98 13:56:24 -0500
Received: from stig (stig.ma.certco.com [10.200.200.45]) by smtp.ma.certco.com (8.8.5/8.8.5) with SMTP id NAA04846; Wed, 28 Oct 1998 13:56:24 -0500 (EST)
To: "'Russ Housley'" <housley@spyrus.com>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 13:56:23 -0500
Message-ID: <29E0A6D39ABED111A36000A0C99609CA18D2E5@macertco-srv1.ma.certco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <4.1.19981028132138.009c32b0@mail.spyrus.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>Denial of service is allways an issue; it is a concern in
>all of the possible repository alternatives.
At the risk of stating the obvious, a denial of service that
prevents you from getting revocation information (such as a
CRL) can be Very Bad, given the implementation quality of most
network services that I've seen...
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25035 for ietf-pkix-bks; Wed, 28 Oct 1998 10:34:56 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25031 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:34:55 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.66.65.231]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA10033; Wed, 28 Oct 1998 10:36:26 -0800 (PST)
Message-Id: <4.1.19981028132138.009c32b0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 28 Oct 1998 13:28:48 -0500
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
From: Russ Housley <housley@spyrus.com>
Subject: Scale (and the SRV record)
Cc: ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan asks:
> I need to be enlightened - How does one deploy a large scale distributed
> PKI without a large scale object oriented distributed (and protected by
> ACI, etc) directory system?
Directory is the preferred certificate repository, but it is not the only
repository that will scale. People have used FTP, Finger, HTTP, and other
mechanisms to distribute certificates.
The PKI is not dependent on the deployment of a Directory, as these other
mechanism can be used until the Directory become widely available.
Further, a trusted repository is not a requirement. Since certificates and
CRLs are signed, the repository cannot make undetected modification to the
data structures. Denial of service is allways an issue; it is a concern in
all of the possible repository alternatives.
Russ
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24886 for ietf-pkix-bks; Wed, 28 Oct 1998 10:13:11 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24882 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:13:09 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id NAA19358; Wed, 28 Oct 1998 13:15:19 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA14076; Wed, 28 Oct 1998 13:15:15 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AB.0063ED3E ; Wed, 28 Oct 1998 13:11:27 -0500
X-Lotus-FromDomain: FDC
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>
cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Stephen Kent" <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566AB.0062D617.00@lnsunr02.firstdata.com>
Date: Wed, 28 Oct 1998 10:13:23 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
spent a lot of time on the SSL portion of the web ... 94/95 working out how
to do/deploy electronic commerce operations. Current SSL infrastructure
uses server certificate for key exchange ... not for authentication. To the
extent that there is authentication done ... it consists of checking the
certificate issuer against a list that has typically pre-installed in the
browser (not checking on the certificate owner). It is one of the reasons
that I coined the term certificate manufactoring .... to highlight
manufactoring and distributing certificates is typically only a small part
of what has become to be considered part of a PKI infrastructure.
I got possibly the first mutual authentication SSL deployed ... before it
was called SSL3. Again authentication was limited to verifying the
certificate issuer. The server certificate was essentially a comfort device
for all the clients ... the client certificates started out essentially
being "relying party" certificates .... but to do more than simple
certificate issuer authenitcation ... i had to check the certificate owner
information against an account database. At that point it became evident
that even relying party certificates were superfulous in the transaction
since I needed to reference the account record (which already had copy of
the public key, lots of attribute binding ... as well as up-to-date
real-time status).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24626 for ietf-pkix-bks; Wed, 28 Oct 1998 09:39:31 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24622 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 09:39:30 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP (peer crosschecked as: [204.254.216.13]) id QQfnbq26760; Wed, 28 Oct 1998 12:41:05 -0500 (EST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <VL2FG9LQ>; Wed, 28 Oct 1998 12:42:34 -0500
Message-ID: <3C7EABA3F6F1D1118FD90008C7F450FDA65C16@exchang-fairfax.pec.com>
From: WHenry <WHenry@pec.com>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 12:42:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phillip,
The problem with this remark is that 9/10 of all SSL sites are using SSLv2,
and there is no "real" authentication happening here.
Example... just because Verisign's cert is posted in my browser doesn't
mean:
1. I should trust that this embedded cert is valid, and
2. I should trust an online vendor that he/she is who they say they
are.
Verisign's own Certification Practice Statement (CPS) says it all: Versign
is not liable for verifying the identity of certificate users.
Bill Henry
Fairfax, VA
"Look at the one already deployed and work it out. The SSL secured
part of
the Web does not stop working if directory.verisign.com goes down."
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Wednesday, October 28, 1998 11:37 AM
> To: Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan issued the following challenge,
>
> > I need to be enlightened - How does one deploy a large scale distributed
> > PKI without a large scale object oriented distributed (and protected by
> > ACI, etc) directory system?
>
> Seems like a good question, it occured to me that now is a good time to
> raise it.
>
> Look at the one already deployed and work it out. The SSL secured part of
> the Web does not stop working if directory.verisign.com goes down.
>
> I have had this arguement before with the hypertext establishment. They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L to
> give the keynote!
>
> The greater the scale the less weight a base information system can carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of consistency
> across transactions. Finally at global scale it is not practical to deal
> in
> data, we must deal in names instead, names in this case being of Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live) to
> make the DNS sytem tractable, precisely because they have Sebok's 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
>
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
>
> Making PKI scale to global reach is no more than a matter of naming. Bind
> the network level directory infrastructures to the internet naming system
> which is and will continue to be DNS.
>
> There is already a DNS resource record defined for the purpose - SRV. If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
>
> Email client is to send to fred@arius.com, there is no cert in the address
> book:
>
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> _ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> _ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> _ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest priority
> number which offers a directory protocol that is understood,
> in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> fred@arius.com
> 5) The client retrieves the certificates for the entry, there are three
> of which one is a currently valid one for fred@arius.com
> 6) The client encrypts the email
> 7) The client sends the email
>
>
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
>
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
>
>
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
>
>
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
>
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
>
> __pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> __pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> __pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
>
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
>
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
>
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have deployed.
>
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
>
>
> Phill
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24476 for ietf-pkix-bks; Wed, 28 Oct 1998 09:20:23 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24472 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 09:20:22 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id MAA05229; Wed, 28 Oct 1998 12:22:33 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id MAA11968; Wed, 28 Oct 1998 12:22:32 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AB.005F19F8 ; Wed, 28 Oct 1998 12:18:45 -0500
X-Lotus-FromDomain: FDC
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566AB.005F4647.00@lnsunr02.firstdata.com>
Date: Wed, 28 Oct 1998 09:20:39 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
... and the other serious problem that is starting to show up is the
privacy issues related to information that might be in a directory ....
even a name field might represent a privacy concern.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24187 for ietf-pkix-bks; Wed, 28 Oct 1998 08:35:03 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24183 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 08:35:03 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA17572; Wed, 28 Oct 1998 08:34:27 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA19175; Wed, 28 Oct 1998 08:36:41 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>
Subject: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 11:37:21 -0500
Message-ID: <000401be0291$3c8dec00$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan issued the following challenge,
> I need to be enlightened - How does one deploy a large scale distributed
> PKI without a large scale object oriented distributed (and protected by
> ACI, etc) directory system?
Seems like a good question, it occured to me that now is a good time to
raise it.
Look at the one already deployed and work it out. The SSL secured part of
the Web does not stop working if directory.verisign.com goes down.
I have had this arguement before with the hypertext establishment. They
could never figure out how it was possible to have global network hypertext
without an 'object oriented distributed' database. They were completely
wrong but that did not stop them from rejecting every conference paper
on the Web, until the time came when they were clamouring for Tim B-L to
give the keynote!
The greater the scale the less weight a base information system can carry.
A transactional database can scale to tens of hosts at best - and even then
this requires carefull choice of the transactions allowed. A directory
system
scales further because it guarantees so much less in terms of consistency
across transactions. Finally at global scale it is not practical to deal in
data, we must deal in names instead, names in this case being of Pierce's
'thirdness' quality and whose persistence can defined (Time To Live) to
make the DNS sytem tractable, precisely because they have Sebok's 'Name'
property - the relationship between the symbol and the designatum is
purely conventional.
Compare this approach to what we do with PKI, we use public key to
establish a trust framework we then leverage with private key. Or as
an analogy consider the task of throwing a heavy rope across a chasm,
starting with a thin, light piece of string and working up.
Making PKI scale to global reach is no more than a matter of naming. Bind
the network level directory infrastructures to the internet naming system
which is and will continue to be DNS.
There is already a DNS resource record defined for the purpose - SRV. If
we assume that every enterprise has deployed a border LDAP directory
populated with the certificates of its employees we can send encrypted
S/MIME messages to any certificate holder as follows:
Email client is to send to fred@arius.com, there is no cert in the address
book:
1) The client obtains the DNS RR's for arius.com
2) The client examines the SRV records, there are three
_ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
_ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
_ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
3) The client attempts to connect to the server with the lowest priority
number which offers a directory protocol that is understood,
in this case directory.arius.com offers LDAP over TCP/IP
4) The client does a search for an entry with a mail atribute of
fred@arius.com
5) The client retrieves the certificates for the entry, there are three
of which one is a currently valid one for fred@arius.com
6) The client encrypts the email
7) The client sends the email
Note that we have only one large scale infrastructure and it is DNS. I
don't know if that meets the definition of 'object oriented' or not.
Note also that this could equally well be achieved using some other
type of server since as far as the client is concerned it is making
an unambiguous query to a server. The question of the ideal server
to server protocol is irrelevant to the client.
The question of whether the certificate returned is one that can be
trusted is orthogonal. Note that it is not one which in this case
may be made by the server since it is most unlikely the client will
in the general case be willing to share its trust criteria with an
untrusted service.
There is just one minor change we might want to make to the current
SRV proposal. It would be useful to have a means of differentiating
directories on the basis of the information held. Specifically it
would be useful to be able to differentiate a directory acting as a
PKIX repository for a particular domain.
I would suggest that we ask that the SRV naming convention be extended
a single level to provide a 'category' modifier, in this case PKIX.
The above RRs would therefore be :-
__pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
__pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
__pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
The same convention could be reused in other areas, for example
there is an urgent need for the universities to have some kind of
protocol for discovery of journal articles, pre-publications and
such. Say a working group sets up a set of conventions and a schema
for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
and __LIBRY._http._tcp SRVs defined. And of course there would be
__ocsp._http._tcp.
The point here is that we can leverage a widely deployed
infrastructure. Paul Vixie modified the bind code three years ago and
the upgrade has largely percollated.
We can either spend time arguing what a global X.500 infrastructure
will do fo us when it arrives or we can build on what we have deployed.
So before proposing a change to the DNS/namedroppers folk what is the
PKIX list view?
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24122 for ietf-pkix-bks; Wed, 28 Oct 1998 08:28:42 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24118 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 08:28:40 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id LAA18146; Wed, 28 Oct 1998 11:30:43 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id LAA09296; Wed, 28 Oct 1998 11:30:41 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AB.005A5650 ; Wed, 28 Oct 1998 11:26:43 -0500
X-Lotus-FromDomain: FDC
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566AB.005A6EB8.00@lnsunr02.firstdata.com>
Date: Wed, 28 Oct 1998 08:27:45 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
small note ... from business standpoint ... it might be better explained
that no directories no authentication infrastructure (which is the business
process/requirement) ... a PKI is then a method of implementing that
infrastructure. Part of the problem with starting with PKI as a solution
and then asking what the problem is .... one might might be led into
presuming that some of the existing PKIs deployed for independent pilots
are the structure one would automatically use as an integrated business
solution.
directories actually have other business needs independent of the
authentication infrastructure. in past life, looked at one customer that
had on the order of 6000 RDBMS where 90% of the data was common. schema
integration directory was needed just so that simple things like changing
the name on an account is consistently done thruout the business (side
problem was wide variety of different terms that were used in schemas for
common things like name).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24022 for ietf-pkix-bks; Wed, 28 Oct 1998 08:06:21 -0800 (PST)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24018 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 08:06:19 -0800 (PST)
Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by maila.telia.com (8.8.8/8.8.8) with SMTP id RAA09568 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 17:08:13 +0100 (CET)
Message-Id: <3.0.32.19981028170254.00a11db0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 28 Oct 1998 17:04:40 +0100
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: Internet draft for Qualified Certificates.
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA24019
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Anders,
An unmistakable name doesn't have to be static. It is unmitakable as long
as the relying party can use the name to identiy the subject for as long as
the certificate is valid and not revoked.
It is at this moment outside the scope of this I-D to make any requirements
on how static a name should be. This is up to the CA to decide and up to
the relying party to accept.
/Stefan
At 04:17 PM 10/28/98 +0100, Anders Rundgren wrote:
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Stefan, I still have some serious problems with the definitions and
interpretations.
>
>>>How does a certificate-relying party know what fields form
>>>an unmistakable name of the subject?
>>>
>>>Unmistakable is different from static identity I guess?
>>>
>>>Anders
>
>>An unmistakable name of the subject SHALL be obtained by combining the
value of the subjects
>>registered name attributes or pseudonym attributes, with the values of
the following attribute
>>types;
>>countryName
>>civicRegistrationNumber
>>serialNumber
>>organizationName
>>organizationalUnitName
>>postalAddress
>
>To me a Swedish EID forms an unmistakable subject identity (99.999%) by just
>using civicRegistrationNumber.
>
>By using the other (non-static) attributes you loose unmistakable. You
just have to change
>employer to break it!
>
>I would also like to see the *static* identity possibility covered by the
draft. I.e. it should
>be clear for a certificate-relaying party if is unmistakable in the way
you use that
>word in other contexts.
>
>Anders
>
>
>
>----------------- SEIS mailing list (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA28145 for ietf-pkix-bks; Tue, 27 Oct 1998 16:52:56 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA28140 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 16:52:46 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P1P>; Wed, 28 Oct 1998 11:50:28 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Lynn.Wheeler@firstdata.com
Cc: Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Wed, 28 Oct 1998 11:50:27 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill - again you promote a separation - in an abstract way. But I
question why would one implement 509 without X.500? What is the
separation in terms of distributed information system engineering and
what is your solution of dealing with the need to have single logon on
to distributed services and single information entities representing
customers, staff and assets - that have certificates applied.?
Many organisations have many customer databases - islands of "may be
replicated" information. This equals high operational costs, high risks
to business because of inconsistency, inability to scale, long service
provisioning times - ie. a high cost mess. Directory technologies
provide a damn good vehicle to consolidate these information systems.
It seems you are proposing to put PKIs over a fragmented and legacy
information pradigm. Wont this add to the mess?
Your words
"In other words you do not want to have a directory
intermediating
between the PKI and your application."
Can you tell us how you do this? given that the application has to chase
across the planet in a standard way for an object that represents the a
certficate user (or CA)- and that such an object will have other
business details and attributes, will have to exist somewhere in a
distributed environment - and for the sake of efficiency and cost and
the integrity of service provisioning (by large corporates) should exist
in one place -- by NAME.
I need to be enlightened - How does one deploy a large scale distributed
PKI without a large scale object oriented distributed (and protected by
ACI, etc) directory system?
Isnt this a bit like deploying secure telephones (with customised wires)
without a telephone network?
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Tuesday, 27 October 1998 8:25
> To: Lynn.Wheeler@firstdata.com
> Cc: Alan Lloyd; Al Arsenault; Stephen Kent; ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
>
>
> > there are business operations with account-based systems with
> >100million
> > entries and raw
> > data in tens of terabytes. for business process that have to access
> the
> > account record to complete the transaction, splitting responsibility
> for
> > the transaction between an account infrastructure and a PKI
> infrastructure
> > ... doesn't improve availability ... it actually lowers it since now
> there
> > has to be two things that are operational for transaction completion
>
> I would not propose such a split. In fact I think it argues to my
> point.
>
> Perhaps I have been unclear, the functional division I see as
> essential
> is at a somewhat abstract level. I want to avoid bluring the
> distinctions
> between PKI functions and information distribution functions precisely
> so that applications such as Lynn's can be supported.
>
>
> You want the authentication information from the PKI to directly mesh
> into the authorization information supplied by your application.
>
> In other words you do not want to have a directory intermediating
> between the PKI and your application.
>
> The question to ask is 'what box (program etc.) have I just added
> that can break?'
>
> If there is a per-transaction protocol connection required for PKI
> use, it will as you said reduce your availability. But PKI is not
> inherently protocol oriented. Nor is it necessarily a 'box to
> break'. It would be more accurate to view being 'PKI aware' as being
> a quality of systems rather than "THE PKI" being a discrete system
> in its own right that can be pointed out in the control room and
> thumped with a hammer when it breaks:-)
>
> In other words the PKI should not mandate a 'coherent directory
> infrastructure' since the PKI abstraction should not care how the
> bits arrived so long as they are properly signed. But what the PKI
> suite of standards MUST do is to state how to link to a directory
> to obtain such information in the case where one is available.
>
>
> To permit scale your PKI protocol infrastructure needs to be entirely
> integrated within your transaction protocol infrastructure - at least
> for that *particular* application. That does not mean however that
> there is no 'PKI' component or indeed that every piece of the
> infrastructure must be integrated at that level - certificate
> issue could well be independent.
>
> A good reason to be ruthless when insisting on separation of function!
> It is very easy to propose tweaks that look very good in a limited
> context but fail in a larger one.
>
> Phill
>
>
> [PS OK I'll admit that it is much the same once you get up to
> Terabytes
> of data but I was talking about input bandwidth, not just static
> storage :-) I think that you Steve and myself are essentially arguing
> the same point though.]
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27798 for ietf-pkix-bks; Tue, 27 Oct 1998 16:35:05 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27794 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 16:35:01 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P1N>; Wed, 28 Oct 1998 11:32:45 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4A5@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>, Phillip M Hallam-Baker <pbaker@verisign.com>
Cc: Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Wed, 28 Oct 1998 11:32:44 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Totally agree.
PKI is not a God on High, it is a security function that is applied to
a business (with various levels of trust) commensurate and in line with
the service provisioning and investments (of IT systems) of that
business. And first and foremost in that application process, the PKI
and the business information concepts and models have to integrate. Ie.
if databases integrate with the directory systems (or become them), the
PKI functions can be applied.
A key system is there to protect the delivery of IT services - and the
investments in the implementation, delivery and management those
services in a global market will probably be 20 times that of any PKI
expenditure. And generally experience is showing that the PKI function
is applied to existing services. Not the other way round.
regards alan
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Tuesday, 27 October 1998 6:16
> To: Phillip M Hallam-Baker
> Cc: Alan Lloyd; Al Arsenault; Stephen Kent; ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> there are business operations with account-based systems with
> >100million
> entries and raw
> data in tens of terabytes. for business process that have to access
> the
> account record to complete the transaction, splitting responsibility
> for
> the transaction between an account infrastructure and a PKI
> infrastructure
> ... doesn't improve availability ... it actually lowers it since now
> there
> has to be two things that are operational for transaction completion
> i.e.
> availability to complete is the product of the availability of the two
> infrastructures; for availability to improve, transaction would have
> to be
> able to complete even if the whole PKI infrastructure or the whole
> account
> infrastructure was not operational (and since the original premise was
> that
> at least the account infrastructure has to be operational for the
> transaction to complete; adding a PKI infrastructure can't improve the
> availibitliy)
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27747 for ietf-pkix-bks; Tue, 27 Oct 1998 16:26:28 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27743 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 16:26:11 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P1L>; Wed, 28 Oct 1998 11:22:54 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4A4@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Lynn.Wheeler@firstdata.com, Al Arsenault <aarsenault@spyrus.com>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Wed, 28 Oct 1998 11:22:53 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
You may disagree Phill - but do you have an alternative
information/services solution for organisations who want to represent
and manage their customers, 10s if not 100's of millions of customers in
a distributed way across this planet.
The bottom line is that a "PKI" technologies on their own with
customised databases and odd validation protocols do not scale well.
Also a free standing PKI does not represent a complete service
provisioning system for dealing with customers over a distributed
environment. Also PKI on its own does not provide a consistent approach
the business or operational issues which usually dominate real, large
scale information systems.
Please note, that when I say a coherent directory strategy is needed, I
dont mean that there is one directory for the whole world or for a
complete organisation. There will be directory system (s) aligned to
specific vertical markets (WP, retail, defence, transport, libraries,
etc), there will also be WEB systems, there will also be databases, etc.
and there will be integration between these information functions
through tools, etc. And companies will apply directory technology to
support a service over a sphere of influence. eg. Customer
authentication and access.
My comment is that, one cannot put, IMHO, attributes such as
certificates, that relate to objects (X.500 style) into a serviceable
environment without a directory system - if you want to add business
related information to such objects and you want scaleability (ie.
distribution - with distributed acccess and administration).
The other way of doing this is via a dedicated database and bespoke
validation protocols onto bespoke information models. ie. no
scaleability and and one cannot add business information. Where would
such a system be used? Well only limited, very complex enclaves with
"small" (10k) numbers of users with limited services.
The world is moving toward a directory infrastructure - ie. the
evolution is from customised databases--> WEB based for browsing
text---> and additionally distributed object texhnologies (directories).
The DEN initiative and many vendors "directory enabling" their
applications prove this - eg. see SAP and Peoplesoft announcements re
directory enabling...
I think that PKIX wont go far without considering the fundamental issues
of being directory enabled or supported.
And to date - all I hear is that PKI can happen without
directories...Well I travel the planet and work with big organisations
and in my book, no directories = no PKI.
So perhaps there is a market for small dedicated PKIs but what is the
PKIX list's view in providing a PKI for the Internet - ie. 100m users? a
customised central database?
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Tuesday, 27 October 1998 4:01
> To: Alan Lloyd; Lynn.Wheeler@firstdata.com; Al Arsenault
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> > ie. The direction today is to consolidate business information
> models in
> > line with current systems be it "internal" for Staff and "external"
> > Customers with X.500 directory systems ....
>
> I disagree.
>
> The idea that there is one 'direction' that is appropriate for the
> market as a whole is simply ridiculous. There are directions that
> will be more appropriate for some applications than others.
>
> There are many organizations in which the deployment of a PKI will
> never happen if the precondition is the deployment of a coherent
> directory strategy. The 'consolidated approach' to information
> systems has been tried and the current CIO got where he did by
> dismantling it.
>
>
> As Steve said, been there, done that.
>
> Having built systems which by anyone's definition are 'extreeme'
> scale-wise (anyone else here commissioned machines dealing with
> 6Tb/sec raw data?) the major lesson I have drawn from this
> experience is the need to insist on tight compartmentalization
> of functionality. The interdependencies between complex
> infrastructure must be ruthlessly pruned to the bare minimum.
>
> The 'directory-centric' PKI that Alan is promoting is simply
> a further step in a direction that is already causing severe
> scaling problems. Directory dependent PKI can only scale as
> far as the directory. Where is the global X.500 directory?
>
> A PKI should be able to take advantage of a directory if it is
> there (call it directory linkable?) - but collapse in a quivering
> heap if the directory has a bad day? - NEVER!
>
>
> Until someone can show me a directory system with 100 million
> users that is deployed the 'directories scale hypothesis' is
> unproven in my view.
>
> More seriously however the ability of directories to scale
> rests upon a very tightly circumscribed set of duties which
> they respond to. After all the difference between a directory
> and a database is simply that the transaction coherency
> requirements which are costly to implement in conjunction
> with replication are not supported by a directory.
>
> In other words a directory might scale to 100 million users,
> but not if we start tampering with the assumptions on which
> that scalability depends. The scaling of Web servers became
> much more difficult once they became stateful.
>
>
> Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27986 for ietf-pkix-bks; Mon, 26 Oct 1998 16:12:41 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27979 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 16:12:38 -0800 (PST)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id BAA25663 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 01:14:36 +0100 (CET)
Received: from stefans (t3o68p32.telia.com [62.20.139.32]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id BAA04897 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 01:14:28 +0100 (CET)
Message-Id: <3.0.32.19981027005928.00979400@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 27 Oct 1998 01:10:51 +0100
To: ietf-pkix@imc.org
From: Stefan Santesson <stefan@accurata.se>
Subject: Draft for Qualified Certificates
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA27980
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
As a result from the Chicago meeting I have formed a first preliminary
version of an Internet draft for Qualified Certificates.
The ambition is that this draft shall be developed as a PKIX work item and
finally go the standards track.
The need for this specification is called for by the legal and technical
debate concerning digital signatures which are considered legally
compatible with handwritten signatures.
I will just very shortly give a condensed outline of the preliminary
results and last I copy the complete draft.
Condensed outline:
------------------
The draft is based on PKIX part 1, which in the draft is referred to as
RFCxxxx
The draft focus on a harmonized definition on names (issuer and subject).
It also mandate some extensions to be present and critical.
Issuer name:
Issuer name shall form an unmistakable name of the issuer by examining the
present values of the following attributes:
countryName
stateOrProvinceName
organizationName
commonName
Subject name:
Subject name can be based on a registered name or a pseudonym.
A registered name shall be hold in the attributes surname and givenName
Pseudonyms shall be hold in a newly defined pseudonym attribute
In addition to this the present pseudonym or registered name may be
reflected in the commonName attribute. This represent the subjects name in
a preferred presentation format.
An umistakable name shall be formed by the pseudonym or registered names in
combination with the present values of the following attributes:
countryName (defines the context of other attributes)
civicRegistrationNumber (newly defined)
serialNumber (added to the preferredAttributes list)
organizationName
organizationalUnitName
postalAddress
Other:
Some useful additional attributes are defined (countryOfCitizenship and
countryOfResidence )
The policy extension shall be present and marked critical. The purpose of
the certificate should be defined directly or indirectly by the policy
(including conformance to this profile).
Key usage shall exclusively be marked for non-repudiation.
Key identifier extension shall be present but shall NOT be marked critical.
--------------------------------------------------------
Below follows the complete draft (preliminary version)
All comments are highly appreciated.
/Stefan
PKIX Working group S.Santesson (SEIS)
Internet Draft
October 26, 1998
Expires six in months
Internet X.509 Public Key Infrastructure
Qualified Certificates
<draft-ietf-santesson-qc-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet- Drafts as reference material or to cite
them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This Internet-Draft forms a certificate profile for Qualified Certificates,
based on RFCxxxx, for use in the Internet. In this document the term
Qualified Certificate is used to describe a certificate which is aimed to
support digital signatures in a context which is considered functionally
equivalent to the use of handwritten signatures.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Please send comments on this document to the ietf-pkix@imc.org mail list.
1 Introduction
This standard is one part of a family of standards for the X.509 Public Key
Infrastructure (PKI) for the Internet. The standard is based on RFC xxxx,
which defines underlying certificate formats and semantics needed for full
implementation of this standard.
The standard profiles the format and semantics for a specific type of
certificates named Qualified Certificates. The term Qualified Certificates,
its functional relations to legal frameworks and the assumptions that
affects the scope of this document are defined in section 2.
Section 3 defines requirements on information content in Qualified
Certificates.
In Appendix A some security considerations are discussed in order to
clarify the security context in which Qualified Certificates are assumed to
be utilized.
Finally Appendix B contains all relevant ASN.1 structures which are not
already defined in RFCxxxx.
2 Requirements and assumptions
The term Qualified Certificates is defined in this section with the only
purpose to clarify the scope of this standard. The actual mechanisms that
will decide whether a certificate should or should not be considered
qualified to meet this definition or whether this definition is relevant
for a particular certificate or service, are outside the scope of this
standard.
In this context the term Qualified Certificate defines a certificate which
has the properties defined in section 2.1, fall within the legal
assumptions in section 2.2, and have the primary purpose of identifying a
person with high level of assurance in non-repudiation services, which may
protect considerable values.
Harmonization in the field of Qualified Certificates is essential within
several aspects that falls outside the scope of RFCxxxx. The most important
aspects that affects the scope of this specification are:
- Definition of names and identity information in order to
identify the associated subject in a uniform way.
- Definition of information which identifies the jurisdiction under
which the CA operates when issuing a particular certificate.
- Definition of key usage extension usage for Qualified Certificates.
- Requirements for critical extensions.
2.1 Properties
A Qualified Certificate as defined in this standard is assumed to have the
following properties:
- Issued by a CA that makes a public statement that the certificate serves
the purpose of a Qualified Certificate, as discussed in section 2.3
- Indicate a certificate policy consistent with liabilities, practices and
procedures undertaken by the CA, as discussed in 2.4
- Be issued to a natural person (living human being).
- Contain an unmistakable name of the subject or an unmistakable
pseudonym identified as such.
- Exclusively indicates non-repudiation key usage for the certified public
key.
- Fully complies with the certificate profile defined in RFCxxxx
2.2 Legal framework
The evidence value and thereby the expected legal status of a digital
signature is highly dependent on the quality of the signers certificate as
well as the properties of the signature service used to create and verify
the signature.
Current national laws in general covers the area of agreements and
signatures, regardless of whether they appear in a physical or digital
context. There is however a great uncertainty how traditional law will be
applied to the relatively new digital techniques. According to the UNCITRAL
Model law on Electronic Commerce, a key factor for the legal status of
digital signatures is whether they are used in a context where they are to
be considered "functionally equivalent" to handwritten signatures.
A common characteristic for emerging legal frameworks regarding digital
signatures is thus to identify some minimum requirements on certificates
which are qualified to support digital signatures in a context which is
considered to be "functional equivalent" with handwritten signatures. These
requirements may emphasize different aspects of certificate issuance and
maintenance such as the routines for identifying the key holder, revocation
routines, liabilities of key holders and CA:s, accreditation of CA:s and
information content in certificates.
2.3 Statement of purpose
For a certificate to serve the purpose of supporting digital signatures
that are legally compatible with handwritten signatures, it is assumed that
the CA will have to make a public statement which states this purpose,
presumably published in a CPS.
The shape of this statement may depend on the governing law under which the
CA is operating but in general it is assumed that the CA at least will have
to include in its statement that the certificate:
- is aimed to be used for verification of digital signatures in a context
where they are considered "functional equivalent" to hand written
signatures and;
- meets all requirements, according to the law under which the CA is
operating, necessary to support this "functional equivalence".
The legal effects of this statement will be dependent on the applicable
governing law under which the CA is operating. Within states with no
specific regulations concerning digital signatures, the statement will only
be a declaration of the suitable area of use of the certificate. In states
where regulations are extensive and specific the statement will be a
declaration that the certificate complies with all these regulations.
The function of the statement is thus to assist any concerned entity in
evaluating the risk associated with creating or accepting signatures based
on a particular certificate.
2.4 Policy issues
Certain policy aspects defines the context in which the profile is to be
understood and used. It is however outside the scope of this profile to
specify any policies or legal aspects that will govern services that issues
or utilizes certificates according to this profile.
It is however assumed that the issuing CA will undertake to follow a
publicly available certificate policy which is consistent with its
liabilities, practices and procedures.
3. Certificate and Certificate Extensions Profile
This section defines a profile for Qualified Certificates. The profile is
based on the Internet certificate profile RFCxxxx which in turn is based on
the X.509 version 3 format. For full implementation of this section
implementers are REQUIRED to consult the underlying formats and semantics
defined in RFCxxxx.
ASN.1 definitions relevant for this section are supplied by RFCxxxx except
for definition of SupportedAttributes which is extended in this standard.
Definition of the extended SupportedAttributes and definitions of the added
attribute types are supplied in Appendix B.
3.1 Basic Certificate Fields
3.1.1 Issuer
The issuer field SHALL contain an unmistakable name of the issuer which at
least SHALL identify the organization liable for the certificate. The
unmistakable name of the issuer MUST be obtained by examining the present
values of the following attribute types;
countryName
stateOrProvinceName
organizationName
commonName
Additional attributes MAY be present but they SHALL NOT be necessary to
identify the issuer.
The attributes organizationName and countryName are mandatory. All other
attributes are OPTIONAL with the exception concerning stateOrProvinceName
as stated below.
The geographical information SHALL be consistent with the legal
jurisdiction under which the CA is operating. The geographical information
SHALL be contained in the mandatory countryName attribute value and if
necessary the stateOrProvinceName attribute. If the stateOrProvince
attribute value is relevant for the legal jurisdiction this attribute is
also mandatory.
3.1.2 Subject
The subject field SHALL contain an unmistakable name of the subject.
Subject name includes the complete set of attributes describing the
identity and other related attributes and privileges of the subject. In
this profile the attributes used to form the subject name are divided into
four groups:
- Registered name attributes; holding the value of the subject's officially
registered name.
- Pseudonym attributes; holding the value of the subjects pseudonym.
- Additional identifying attributes; holding the value of attributes which
in combination with the real name attributes or the pseudonym attributes
forms an unmistakable identifier of the subject.
- Specific attributes; holding the value of attributes and privileges of the
subject which has a purpose other than to identify the subject.
If the Pseudonym attribute is used the additional identity attributes
SHOULD be considered to be part of the pseudonym identity, thus not
representing any officially registered identity attributes of the subject.
3.1.2.1 Registered Name Attributes
If the registered name values of a subject are present in a certificate the
surname attribute type SHALL be used to store surnames and the givenName
attribute type SHALL be used to store given names.
The real name of a subject SHALL be represented by names which are
officially registered within the country given by the value of the
mandatory countyName attribute.
If the real name is carried in the givenName and surename attributes the
commonName attribute type SHALL, when present, be used to store the
subjects name in a preferred presentation format commonly used by the
subject. Nicknames and names with spelling other than defined by the
registered name MAY be used.
3.1.2.2 Pseudonym attributes
If a pseudonym name of a subject is present in a certificate the pseudonym
values SHALL be stored using the pseudonym attribute type.
If a pseudonym is carried in the pseudonym attribute the commonName
attribute type SHALL, if present, be used to store the same pseudonym
value. The rationale for this may be to allow applications to access the
subjects name in its preferred presentation format from the commonName
attribute, regardless of whether the subjects name is a pseudonym or a real
name.
3.1.2.3 Additional identifying attributes
The unmistakable identifier of a subject SHALL be obtained by combining the
value of the subjects registered name attributes or pseudonym attributes,
with the values of the following attribute types;
countryName
civicRegistrationNumber
serialNumber
organizationName
organizationalUnitName
postalAddress
Additional attributes MAY be present but they SHALL NOT be necessary to
identify the subject.
The countryName attribute is mandatory. All other attributes are OPTIONAL
as long as the used set of attributes form an unmistakable name.
The countryName attribute value specifies the context in which other
attributes that forms the unmistakable name are to be understood. The
registration number is thus a registration number within that country and
the organization is an organization or a branch office located in that
country. The country attribute does not necessarily mach the subject's
country of citizenship or country of residence, nor does it have to match
the country of issuance.
The civicRegistrationNumber attribute type SHALL, when present, be used to
store an officially registered civic registration number of the subject,
registered within the specified country. This may be a social security
number or other similar type of civic registration number.
The serialNumber attribute type SHALL, when present, be used to store an
identifier of the subject of any type. This MAY be a number appointed by
the CA but it MAY also be used as an alternative to the
civicRegistrationNumber attribute type to store officially registered values.
The organizationName attribute type and the organizationalUnitName
attribute type SHALL, when present, be used to store the name and relevant
information of an organization with which the subject is associated.
The postalAddress attribute type SHALL, when present, be used to store an
address with which the subject is associated. If an organizationName value
also is present then the postalAdress attribute value SHALL be associated
with the specified organization.
3.1.2.4 Specific attributes
This section specifies some specific attributes which may be useful in
Qualified Certificates.
The following attribute types are defined
countryOfCitizenship
countryOfResidence
The countryOfCitizenship attribute type SHALL, when present, be used to
hold the subjects country of citizenship. If the subject is a citizen of
more than one country, they MAY all be included in the certificate using
this attribute type.
The countryOfResidence attribute type SHALL, when present, hold the value
of the country in which the subject is resident.
3.2 Certificate Extensions
3.2.1 Subject Key identifier
The subject key identifier extension SHALL be present but SHALL NOT be
marked critical.
The keyIdentifier is RECOMMENDED to be composed of a four bit type field
with the value 0100 followed by the least significant 60 bits of the SHA-1
hash of the value of the BIT STRING subjectPublicKey.
3.2.2 Certificate Policies
The certificate policies extension SHALL contain at least one certificate
policy which reflects the practices and procedures undertaken by the CA.
The certificate policy extension SHALL be marked critical.
A statement by the issuer stating the purpose of the certificate as
discussed in 2.3 SHOULD be evident through an indicated policy or through
its associated CPS.
3.2.3 Key usage extension
The key usage extension SHALL be present and SHALL exclusively assert the
key usage nonRepudiation (1). No other key usage values are allowed to be
asserted. The key usage extension SHALL be marked critical.
6 References
RFC 2119
RFC xxxx
X.509 version 3
X.520
Appendix A. Security considerations
A.1 Private key policy
The legal value of a digital signature which is validated with a Qualified
Certificate will be highly dependent upon the policy governing the use of
the associated private key. Both the private key holder as well as the
relying party should make sure that the private key is used only with the
consent of the legitimate key holder and only after the key holders
conscious acceptance of the signed message content.
Appendix B. ASN.1 definitions
SupportedAttributes ATTRIBUTE ::= {
name | commonName | surname | givenName | initials |
generationQualifier | dnQualifier | countryName |
localityName | stateOrProvinceName | organizationName |
organizationalUnitName | title | pkcs9email | serialNumber |
pseudonym | civicRegistrationNumber | countryOfCitizenship |
countryOfResidence }
serialNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX printableStringSyntax (SIZE(1..ub-serial-number))
::= {attributeType 5}
pseudonym ATTRIBUTE
..... To be defined
civicRegistrationNumber ATTRIBUTE
..... To be defined
countryOfCitizenship ATTRIBUTE
..... To be defined
countryOfResidence ATTRIBUTE
..... To be defined
ub-serial-number INTEGER ::= 64
Appendix C. Author addresses:
Stefan Santesson
Accurata Systemsäkerhet AB
Lotsgatan 27d
216 42 Malmö
Sweden
stefan@accurata.se
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27347 for ietf-pkix-bks; Mon, 26 Oct 1998 14:26:48 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27343 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 14:26:47 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id RAA21353; Mon, 26 Oct 1998 17:28:50 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id RAA13148; Mon, 26 Oct 1998 17:28:48 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A9.007B2344 ; Mon, 26 Oct 1998 17:24:59 -0500
X-Lotus-FromDomain: FDC
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>
cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Al Arsenault" <aarsenault@spyrus.com>, "Stephen Kent" <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566A9.007AD734.00@lnsunr02.firstdata.com>
Date: Mon, 26 Oct 1998 14:27:00 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
PKI tends to represent a binding between some set of attributes and a
public key. Accounts have been used for a long time for attribute binding
in business scenerios.
If the PKI attributes start to take on real-time status requirements for
various business processes ... then a certificate approach will tend to
represent stale status ... and something else must be created to provide
real-time status. If business process completion is dependent on obtaining
that real-time status ... and some of the status has been PKI linked ...
and some of the status is core business process, account-record links ...
then availability is impacted (i.e. attribute status like requiring real
time information on whether a certificate is even still valid).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26804 for ietf-pkix-bks; Mon, 26 Oct 1998 13:23:31 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26800 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 13:23:30 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA10705; Mon, 26 Oct 1998 13:22:48 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA00621; Mon, 26 Oct 1998 13:24:57 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: <Lynn.Wheeler@firstdata.com>
Cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Al Arsenault" <aarsenault@spyrus.com>, "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Mon, 26 Oct 1998 16:25:26 -0500
Message-ID: <00ba01be0127$261f7260$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <882566A9.00690680.00@lnsunr02.firstdata.com>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> there are business operations with account-based systems with >100million
> entries and raw
> data in tens of terabytes. for business process that have to access the
> account record to complete the transaction, splitting responsibility for
> the transaction between an account infrastructure and a PKI infrastructure
> ... doesn't improve availability ... it actually lowers it since now there
> has to be two things that are operational for transaction completion
I would not propose such a split. In fact I think it argues to my point.
Perhaps I have been unclear, the functional division I see as essential
is at a somewhat abstract level. I want to avoid bluring the distinctions
between PKI functions and information distribution functions precisely
so that applications such as Lynn's can be supported.
You want the authentication information from the PKI to directly mesh
into the authorization information supplied by your application.
In other words you do not want to have a directory intermediating
between the PKI and your application.
The question to ask is 'what box (program etc.) have I just added
that can break?'
If there is a per-transaction protocol connection required for PKI
use, it will as you said reduce your availability. But PKI is not
inherently protocol oriented. Nor is it necessarily a 'box to
break'. It would be more accurate to view being 'PKI aware' as being
a quality of systems rather than "THE PKI" being a discrete system
in its own right that can be pointed out in the control room and
thumped with a hammer when it breaks:-)
In other words the PKI should not mandate a 'coherent directory
infrastructure' since the PKI abstraction should not care how the
bits arrived so long as they are properly signed. But what the PKI
suite of standards MUST do is to state how to link to a directory
to obtain such information in the case where one is available.
To permit scale your PKI protocol infrastructure needs to be entirely
integrated within your transaction protocol infrastructure - at least
for that *particular* application. That does not mean however that
there is no 'PKI' component or indeed that every piece of the
infrastructure must be integrated at that level - certificate
issue could well be independent.
A good reason to be ruthless when insisting on separation of function!
It is very easy to propose tweaks that look very good in a limited
context but fail in a larger one.
Phill
[PS OK I'll admit that it is much the same once you get up to Terabytes
of data but I was talking about input bandwidth, not just static
storage :-) I think that you Steve and myself are essentially arguing
the same point though.]
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25910 for ietf-pkix-bks; Mon, 26 Oct 1998 11:15:33 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25906 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 11:15:32 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA19143; Mon, 26 Oct 1998 14:17:34 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id OAA04074; Mon, 26 Oct 1998 14:17:32 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A9.0069A034 ; Mon, 26 Oct 1998 14:13:42 -0500
X-Lotus-FromDomain: FDC
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>
cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Al Arsenault" <aarsenault@spyrus.com>, "Stephen Kent" <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566A9.00690680.00@lnsunr02.firstdata.com>
Date: Mon, 26 Oct 1998 11:16:22 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
there are business operations with account-based systems with >100million
entries and raw
data in tens of terabytes. for business process that have to access the
account record to complete the transaction, splitting responsibility for
the transaction between an account infrastructure and a PKI infrastructure
... doesn't improve availability ... it actually lowers it since now there
has to be two things that are operational for transaction completion i.e.
availability to complete is the product of the availability of the two
infrastructures; for availability to improve, transaction would have to be
able to complete even if the whole PKI infrastructure or the whole account
infrastructure was not operational (and since the original premise was that
at least the account infrastructure has to be operational for the
transaction to complete; adding a PKI infrastructure can't improve the
availibitliy)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24664 for ietf-pkix-bks; Mon, 26 Oct 1998 08:59:04 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24660 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 08:59:03 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA03889; Mon, 26 Oct 1998 08:58:20 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA10408; Mon, 26 Oct 1998 09:00:32 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, <Lynn.Wheeler@firstdata.com>, "Al Arsenault" <aarsenault@spyrus.com>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Mon, 26 Oct 1998 12:01:00 -0500
Message-ID: <009301be0102$34ed93a0$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D49D@DSG1>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> ie. The direction today is to consolidate business information models in
> line with current systems be it "internal" for Staff and "external"
> Customers with X.500 directory systems ....
I disagree.
The idea that there is one 'direction' that is appropriate for the
market as a whole is simply ridiculous. There are directions that
will be more appropriate for some applications than others.
There are many organizations in which the deployment of a PKI will
never happen if the precondition is the deployment of a coherent
directory strategy. The 'consolidated approach' to information
systems has been tried and the current CIO got where he did by
dismantling it.
As Steve said, been there, done that.
Having built systems which by anyone's definition are 'extreeme'
scale-wise (anyone else here commissioned machines dealing with
6Tb/sec raw data?) the major lesson I have drawn from this
experience is the need to insist on tight compartmentalization
of functionality. The interdependencies between complex
infrastructure must be ruthlessly pruned to the bare minimum.
The 'directory-centric' PKI that Alan is promoting is simply
a further step in a direction that is already causing severe
scaling problems. Directory dependent PKI can only scale as
far as the directory. Where is the global X.500 directory?
A PKI should be able to take advantage of a directory if it is
there (call it directory linkable?) - but collapse in a quivering
heap if the directory has a bad day? - NEVER!
Until someone can show me a directory system with 100 million
users that is deployed the 'directories scale hypothesis' is
unproven in my view.
More seriously however the ability of directories to scale
rests upon a very tightly circumscribed set of duties which
they respond to. After all the difference between a directory
and a database is simply that the transaction coherency
requirements which are costly to implement in conjunction
with replication are not supported by a directory.
In other words a directory might scale to 100 million users,
but not if we start tampering with the assumptions on which
that scalability depends. The scaling of Web servers became
much more difficult once they became stateful.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA29898 for ietf-pkix-bks; Sun, 25 Oct 1998 18:07:32 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA29894 for <ietf-pkix@imc.org>; Sun, 25 Oct 1998 18:07:31 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id VAA13779; Sun, 25 Oct 1998 21:09:25 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id VAA11239; Sun, 25 Oct 1998 21:09:24 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A9.000B7D2C ; Sun, 25 Oct 1998 21:05:29 -0500
X-Lotus-FromDomain: FDC
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
cc: Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-ID: <882566A9.000B3A1A.00@lnsunr02.firstdata.com>
Date: Sun, 25 Oct 1998 18:08:24 -0800
Subject: aads & x9.59 (was RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
... X9.59 (built on account authority digital signature model) left
financial industiries retail payments committee and on its way for vote as
the industry payment protocol standard.
drafts of x9.59 standard are at ansi-epay@lists.commerce.net mailing list
archive (also my presentation at NISSC a couple weeks ago). url for the
archive and other information on x9.59 and aads is on my personal web site:
http://www.garlic.com/~lynn/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26267 for ietf-pkix-bks; Sun, 25 Oct 1998 15:43:29 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26248 for <ietf-pkix@imc.org>; Sun, 25 Oct 1998 15:43:06 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW33Z1>; Mon, 26 Oct 1998 10:40:28 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D49D@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>, Al Arsenault <aarsenault@spyrus.com>
Cc: Stephen Kent <kent@bbn.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Mon, 26 Oct 1998 10:40:25 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Fantastic... this one has got my vote.
ie. The direction today is to consolidate business information models in
line with current systems be it "internal" for Staff and "external"
Customers with X.500 directory systems (distributed object oriented,
protected, name base transactions, etc) and then apply the security
paradigms necessary to protect a) internal services and; b) customer
authorisation on to the busines's systems used for service delivery.
Importantly and in line with business expansion through customer and
other organisation acquisition strategies - and in line with dealing
with the dynamics of such. It is better to consolidate the information
model (via directories), apply a business strategy re staff and
customers and then apply the security regimes in line with cost, risk
and trust and the business.
I think that trying to shoehorn a PKI onto a company without a directory
system is hard work. In fact very hard work. Simply because there is not
a consolidated information system, no consolidated approach to services
or no consolidated approach to the staff or customers - re the
application of 509.
As said in previous postings, the theory of CAs and 509 has a place.
Buts its application will be (eg.) a telco giving a customer a phone on
which the telco can verify the phone and what services are afforded to
that phone (or attched smartcard).. ie. there is no third party
verification here, just millions of very fast verification actions - via
very large distributed directory services that have directory enabled
validation functions.
Just thoughts - regards alan
PS should we change the subject line?
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Saturday, 24 October 1998 3:45
> To: Al Arsenault
> Cc: Stephen Kent; 'ietf-pkix@imc.org '
> Subject: Re: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> Many of the infrastructures involving authorization ... include many
> factors in addition to strong authentication, some real-time and some
> not.
> Accont-based infrastructures have been a part of business
> infrastructures
> for some time to bind together the necessary information necessary to
> support authorization. The accont authority digital signature model
> attempts to integrate public key registration and digital signature
> authentication into the core business process ... as opposed to
> working on
> ways of figuring out what pieces might be exportable to a certificate,
> then
> realizing that there are real-time requirements ... which means
> real-time
> contact of the CA which is maintaining various critical information.
>
> As the number of attributes are exported into certificates increases
> ...
> and the real-time status of those attributes are required to be
> maintained
> at the CA for authorization ... a CA would eventually begin to migrate
> to
> becoming an accont authority. The current main distinction of a CA is
> that
> it is maybe 20-30% handling cryptography for certificates and 70-80%
> account management. As number of attributes and real-time status
> requirements increase ... the role of cryptography in the CA becomes
> smaller and smaller ... and the account management starts to grow to
> 95+%.
>
> From the financial infrastructure standpoint ... once past toy pilot
> stage,
> it is much more cost effective to start with the most robust
> account-management infrastructure in existance today and retrofit the
> 1-2%
> cryptography necessary to support digital signature authentication ...
> than
> it is to try and upgrade CAs into business-critical, industrial
> strength
> account management support.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19319 for ietf-pkix-bks; Sun, 25 Oct 1998 13:59:43 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19315 for <ietf-pkix@imc.org>; Sun, 25 Oct 1998 13:59:40 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW33YN>; Mon, 26 Oct 1998 08:57:01 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D49C@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Stephen Kent'" <kent@bbn.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 26 Oct 1998 08:56:57 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Stephen, naturally a directory cannot develop key sets, but many of the
customised database being promoted by CAs should be supported by
directory services - otherwise its a proprietary solution with all the
issues of limited scaling all built in. Plus the fact that directories
provide a uniform authentication and access control regime , and
distribution, makes life much mor sensible for those deploying CAs.
As for verification, the engineering approach with CAs re CRLs and
complex clients, etc, etc and domain agile requirements just means that
a wide scale, distributed infrastructure, lightweight client, domain
agile device should be taken.
I accept that single domain, complex clients and bespoke validation
paths may server highly trusted or dedicated enclaves, but there are
other CA areas that need more of an operational and service based
approach.
Adding validation supporting matching rules to directories and/or adding
directory enabled cert validation processes strikes me as the way to go.
I just cannot see how thin, domain agile client software and the system
scaling issues can be dealt with any other way.
But I am open to ideas.
regards alan
> -----Original Message-----
> From: Stephen Kent [SMTP:kent@bbn.com]
> Sent: Tuesday, 20 October 1998 9:15
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: NEW Data type for certificate selection ?
>
> Alan,
>
> I can appreciate the directory perspective of "CA-ness" but I don't
> think
> that captures all of the issues being raised here. CAs exist
> independent
> of directories, so many aspects of a CA may not be captured by by a
> purely
> directory-centric view. Still, to the extent that folks look to
> directories to help with cert selection, it's good to keep in mind
> what
> features a directory can offer to help in addressing this problem.
>
> steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06958 for ietf-pkix-bks; Fri, 23 Oct 1998 10:45:14 -0700 (PDT)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06954 for <ietf-pkix@imc.org>; Fri, 23 Oct 1998 10:45:13 -0700 (PDT)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id NAA02194; Fri, 23 Oct 1998 13:46:55 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA06231; Fri, 23 Oct 1998 13:46:47 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A6.00614980 ; Fri, 23 Oct 1998 13:42:38 -0400
X-Lotus-FromDomain: FDC
To: Al Arsenault <aarsenault@spyrus.com>
cc: Stephen Kent <kent@bbn.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-ID: <882566A6.00618318.00@lnsunr02.firstdata.com>
Date: Fri, 23 Oct 1998 10:45:05 -0700
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Many of the infrastructures involving authorization ... include many
factors in addition to strong authentication, some real-time and some not.
Accont-based infrastructures have been a part of business infrastructures
for some time to bind together the necessary information necessary to
support authorization. The accont authority digital signature model
attempts to integrate public key registration and digital signature
authentication into the core business process ... as opposed to working on
ways of figuring out what pieces might be exportable to a certificate, then
realizing that there are real-time requirements ... which means real-time
contact of the CA which is maintaining various critical information.
As the number of attributes are exported into certificates increases ...
and the real-time status of those attributes are required to be maintained
at the CA for authorization ... a CA would eventually begin to migrate to
becoming an accont authority. The current main distinction of a CA is that
it is maybe 20-30% handling cryptography for certificates and 70-80%
account management. As number of attributes and real-time status
requirements increase ... the role of cryptography in the CA becomes
smaller and smaller ... and the account management starts to grow to 95+%.
>From the financial infrastructure standpoint ... once past toy pilot stage,
it is much more cost effective to start with the most robust
account-management infrastructure in existance today and retrofit the 1-2%
cryptography necessary to support digital signature authentication ... than
it is to try and upgrade CAs into business-critical, industrial strength
account management support.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05824 for ietf-pkix-bks; Fri, 23 Oct 1998 07:53:21 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA05820 for <ietf-pkix@imc.org>; Fri, 23 Oct 1998 07:53:20 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA06571; Fri, 23 Oct 1998 07:54:32 -0700 (PDT)
Message-Id: <3.0.6.32.19981023105001.00920e50@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 23 Oct 1998 10:50:01 -0400
To: Stephen Kent <kent@bbn.com>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
In-Reply-To: <v04011706b253c410d825@[128.33.238.49]>
References: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com> <3627C5B7.2E7800AE@bull.net> <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Steve,
While I agree with many of your points, I think I disagree with your
conclusion.
From the standpoint of PKIX, the question is whether or not somebody
develops a full protocol for "dumb client talking to validation server"
communication, which would be a generalization of the OCSP and DCS
protocols introduced to this point. That's the only thing we could do that
fits within the IETF's bailiwick; other architectural issues I think belong
with some other group (although I'm not sure which one). I'm not willing
to push that protocol right now (or maybe ever), but I was trying find out
whether somebody is planning on introducing it in the future (Michael?
Carlisle? Anybody? :-), since we seem to be heading there one step at a time.
However, I do think that the type of architecture I described has some
applicabiity in the PKI world. Not everywhere, to be sure, but in some
places. What I was trying to do was find out whether I'm out in left field
(again :-) with that belief, or there are some others who are looking in
that direction. There's an issue with exactly how much functionality goes
in the end-entity, but I think that there's definitely a place for a
validation server.
Now, some specific comments:
At 02:51 PM 10/21/98 -0400, Stephen Kent wrote:
>Al,
>
>First I just wanted to point out that your credit card example isn't quite
>complete. In principle, the merchant makes the authorization request to
>the issuing bank (though not directly), equivalent to asking the issuing CA
>about the status of a cert. This is necessary because the request is not
>really authentication, which could be statically validated, but an
>authorization check, which depends on the current credit limit for the
>account, which is know only by the issuing bank.
>
AWA: are PKIs for authentication only, or are they also useful to support
authorization checks? I've always believed that PKIs can be used to
support authorization checks, although this is clearly a much harder
problem than mere authentication.
>Now, in fact, intermediaries have become part of this scheme, and they will
>confer authorization codes, even though they don't have access to all the
>necessary credit data. These "factors" take a piece of the action for this
>service, and are liable for the transaction cost as a result. It is not at
>all clear that this later model is appropriate for the PKI environment, for
>other than financial transactions. For one thing, it may be hard to attach
>a price to many non-financial transactions, which makes it difficult for a
>third party to accept liability. Also, if you look at the CPS for most
>public CAs, they really try to avoid all liability, or limit it
>substantially, which calls into question the real utility of folks who
>would perform this as a public service.
>
AWA: I agree with you on this. It is unfortunate that many of the
"intermediaries" (and a lot of the "public CAs") that exist in the PKI
world today charge a fee for their service but don't really provide
anything of value. I have enough confidence in the marketplace, though, to
believe (or at least hope) that they will either start providing a useful
service or disappear soon enough. (I for one refuse to deal with any
public CAs - or private ones, for that matter - that I believe don't
provide value. If they won't accept liability for their actions, then I'm
stuck with the consequences. If I'm stuck with the consequences, I'm just
going to do the work myself, and the heck with them.) However, I don't
believe that this invalidates the entire model of "validation servers",
particularly when those servers are the CAs themselves.
>If one thinks about the model in a more local context, some of these issues
>change, but then it also seems less likely that one should expect a high
>availability, high security server to be provided in such contexts.
>
AWA: yes, I think that a lot of the concerns about "intermediaries" and
"public CAs" go away. However, the requirements for "high availability,
high security" will be a function of the specific locale, so it will still
be an issue for some. As an example, an organization processing
very-large-dollar transactions may set up its own PKI, separate from the
rest of the world, but still have very stringent security and availability
requirements for certificate validation, because of the risk involved.
>One of the biggest features of a well designed PKI is that it embodies a
>distributed security model that scales through simple replication of static
>data, a problem we know how to solve. It also has the property that to
>spoof the identity of an end entity, one ought to have to subvert the CA
>that issued the cert to that entity, although sloppy cross certification
>and bad choices for PKI structure can make this situation worse.
>
AWA: agreed, it should be a required property of a PKI that the only ways
to spoof the identity of an end-entity should be (1) defeating the CA (by
taking over the CA's machine & private key; by tricking the CA into issuing
the certificate improperly; etc.); and (2) defeating the end user (by
stealing his private key & the ability to use it without detection).
>The notion of cert validation servers is thus very disturbing. It might be
>quite helpful for a server to collect certs and CRLs on behalf of users,
>caching them locally, to facilitate cert path validation, so long as the
>relying party does the validation. The reduced commiunication overhead
>would be a good side effect, and fancy heuristics for figuring out where to
>look to find the right certs could be centralized. However, once one has a
>candidate cert path, and matching CRLs/OCSP responses, the validation
>process isn't all that bad and is well within the capabilities of cert
>clients.
AWA: in principle, I agree. Sometimes the notion of a 'thin client' is
stretched so much that I think it should really be called a 'dumb
terminal'. Personally, I want the software on my machine to do the cert
path validation. However, there are some folks who seem to be willing to
let the security of their system depend on the actions of a validation
server. If, understanding all of the risks, they really want to do that, I
won't try to stop them.
>
>Pushing validation off to a third party, especially in a public context,
>further complicates the murky "trust model" problems we already face in the
>PKI arena, e.g., because organizations that are authoritative for data are
>failing to act as CAs (or at least RAs). In a country where few people can
>program VCRs, the notion of complex certification hierarchies is
>unrealistic, whether distributed or centralized processing is performed;
>moving cert validation to servers will not fix this problem and it
>certainly has the potential to create significant new vulnerabilities for
>PKI implementations.
>
>My view has been that OCSP is an appropriate mechanism IF the responder is
>operated by the cognizant CA or an explicit delegee thereof. Once one
>moves in the direction of having other than the issuer of a cert vouch for
>its validity, one is heading down the slippery slope you descibed. At the
>bottom of this slope is a swamp, which explains why the slope is slippery,
>i.e., slime has been tracked onto the slope by those trying to escape the
>swamp :-).
>
>Steve
AWA: the model I described can't work unless the validation server is
either the CA or someone explicitly designated by her - otherwise, the
revocation information won't necessarily be correct; the operator of the
validation server won't accept liability and thus there's no value added;
and the risks are increased too much. (When we looked at this, we first
thought of having our CA - which did its assigned job very well - be the
validation server. We weren't sure it was up to the performance
requirements, and we didn't want to risk the security of our CA
implementation by throwing on a bunch of extraneous tasks.)
Re your last sentence: yes this can add significant new vulnerabilities,
but it also provides an opportunity to concentrate the hard problem of
dealing with complex certification hierarchies into a few places, and you
may have a better chance of getting it right. It comes down to how much
trust you're willing to place in the client<-->validation server connections.
Al Arsenault
-- you all know the disclaimer about my opinions by now. As if any
employer would actually admit to sharing them!!
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA06782 for ietf-pkix-bks; Thu, 22 Oct 1998 05:49:42 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA06778 for <ietf-pkix@imc.org>; Thu, 22 Oct 1998 05:49:35 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05X7F>; Thu, 22 Oct 1998 22:46:50 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC08311A@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Stephen Kent '" <kent@bbn.com>
Cc: "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 22 Oct 1998 22:46:48 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line.
snip - disagree with some but:
I don't want to debate LDAP issues; this is a PKI list. Your e-mail
address
suggests that you may work for a company that believes directories are
the
solution to lots of problems. Personally, I don't share that belief,
but
the more central issues is that I'd like us to not confuse the current
definition of directory services, as defined in X.500 and LDAP, with
some
possible future set of cert validation services. About 5 years ago we
developed such a service as part of a DARPA program; it validated certs
that a client could not validate because of algorithm incompatability or
similar constraints. Been there, done that. However, the better use of
the service was to collect certs and CRLs for the client and deliver
them
in a form to simplify client cert path validation. That's not an
unreasonable service, but it's a far cry fro asking a third party to do
the
validation for you.
I have answered some of this in another email.. But why is it that there
is little discussion about trust that includes cert validation services,
stability of software or formal information models for PKIs (not just
object definitions and usage? Or discussion that deals with the fact
that trust is derived from sound scaleable system design and
implementation qualitative features (not theoretical objects in an
abstract system)... and that from the real world perspective we must
operationally deal with multiple CA domains and domain agile devices,
etc, etc from different vendors. In addition the "scale" issues do not
get discussed. ie we seem to ignore the issues re 100s of millions of
users that work under dozens of business domains with many certficates
each....
IMHO the only way of dealing with this validation and scaling issue from
a system and information perspective is through a distributed directory
service THAT provides the User and Service information ON WHICH
certficates are placed. AND that CAs and validation functions are
processes that are supported by such distributed object oriented, name
based transaction systems and infrastructure.
Labeling things as third party in this model is also incorrect, the
validation service which is directory attached can be ownwd and trusted
by the CA itself. ie is a third party "label" applied mabove a
functional label or an operational label or an implementation quality
label?
In not sharing my belief re directories are the distributed information
systems for supporting global services - can you enlighten me on how you
would deploy a multi domain CA infrastructure in todays world that
enable single point of authentication (information) for users, simple
client software, and how one can deal with such information over a
distributed global area for 100s of Ms of Users, etc.
By not putting the correct perspective on directories in support of
distributed information functions like CAs - all one is doing is
building islands of mechanisms.
eg its like developing lots of customised PABXs.
Is "trust" relying that a service works and is globally scaleable (eg.
the phone system) eg. The Internet is slow .. I will ring the ISP on the
phone system because I know that always works.
or is trust some theory about abstract objects placed in an abstract
security policy on a yet to be defined unscaleable implementation.?
just views and regards alan
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06545 for ietf-pkix-bks; Thu, 22 Oct 1998 04:51:30 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06541 for <ietf-pkix@imc.org>; Thu, 22 Oct 1998 04:51:10 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05X68>; Thu, 22 Oct 1998 21:48:12 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC083114@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Al Arsenault '" <aarsenault@spyrus.com>, "'Stephen Kent '" <kent@bbn.com>
Cc: "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 22 Oct 1998 21:48:11 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line. Agree with some of the comments - but like to add.
----------
From: Stephen Kent
To: Al Arsenault
Cc: 'ietf-pkix@imc.org '
Sent: 10/22/98 4:51:41 AM
Subject: Re: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
snip
One of the biggest features of a well designed PKI is that it embodies a
distributed security model that scales through simple replication of
static
data, a problem we know how to solve.
Alan: However a major weakness in any system occurs when one replicates
data - particularly when that data forms a linkages to a point of trust
- and in the path there are other objects that may or may not exist (eg
CRLs) that could be placed in these paths in non uniform ways...
EG LDAP - one of the major deficiencies cannot ask for master data from
a CA directory ie. If a CRL has been placed in the master but not yet
propagated to replicas, then a client could consider the cert being
validated - valid if it (without its knowlege - accesses the replica).
(ie. why talk of trust and how one achieves trust in a distributed and
replicated information system and then use a protocol that has so many
untrusted deficiencies???? eg. LDAP.
It also has the property that to
spoof the identity of an end entity, one ought to have to subvert the CA
that issued the cert to that entity, although sloppy cross certification
and bad choices for PKI structure can make this situation worse.
Alan: Bad PKI designs come from weaknesses and complexities in the CA
and the related client information model and service interaction
software - as one adds complexity the components that work with an ill
defined and variable information model, then all things get into a mess.
EG LDAP - no system service model, add and extension here there and
everywhere. Outcome - LDAP is not universal anymore - an operational
mess.
Limited scale systems, complex clients and weak/variable CA information
models is what we have. Its better to have consistency in service and
place trust in the implementation of that service. There is no point in
discussing trust in theoretical Objects and certificates and the
processes that might happen in someones CA or "cert server".
The notion of cert validation servers is thus very disturbing.
Alan:
If a client goes to a CAs directory to get a cert in the path and the
directory provides the wrong one and therefore user to user transaction
is invalidated - then denial of service happens.
Something - somewhere in the system has to be trusted. And in my book
its the implementation that is trusted not theoretical models.
eg. I can build a highy trusted directory system that does cert
matching, has bullet proof access controls, has trusted processes that
generate valid flags from processing CRLs...for the client.
OR I could write sloppy, bug ridden, fragile process that serves no
purpose in terms of trust.
OR I could promote a protocol to a server without any distributed,
directory relevant CA information model and say that solves the problem.
In the above the following observations MUST be made.
Using good directory technology, with sound information services to
support CA functions provide scaleability and measureable trust models.
Using bad anything .. provides no trust
Having a protocol to a server without any notion of the CA function and
the directory support that CAs need or any notion of scaling or how it
deals with multiple CA domains or the complexity of the client, only
generates problems.
IE.
IMHO Talking of trust in the CA/X.509/directory environment without any
reference to implemtation and system design qualitative characteristics
becomes an endless debate - without resolution.
regards alan
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12042 for ietf-pkix-bks; Wed, 21 Oct 1998 14:50:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12038 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 14:50:58 -0700 (PDT)
Received: from [128.33.238.121] (TC121.BBN.COM [128.33.238.121]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id RAA09883; Wed, 21 Oct 1998 17:52:20 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04011706b253c410d825@[128.33.238.49]>
In-Reply-To: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com>
References: <3627C5B7.2E7800AE@bull.net> <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Date: Wed, 21 Oct 1998 14:51:41 -0400
To: Al Arsenault <aarsenault@spyrus.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al,
First I just wanted to point out that your credit card example isn't quite
complete. In principle, the merchant makes the authorization request to
the issuing bank (though not directly), equivalent to asking the issuing CA
about the status of a cert. This is necessary because the request is not
really authentication, which could be statically validated, but an
authorization check, which depends on the current credit limit for the
account, which is know only by the issuing bank.
Now, in fact, intermediaries have become part of this scheme, and they will
confer authorization codes, even though they don't have access to all the
necessary credit data. These "factors" take a piece of the action for this
service, and are liable for the transaction cost as a result. It is not at
all clear that this later model is appropriate for the PKI environment, for
other than financial transactions. For one thing, it may be hard to attach
a price to many non-financial transactions, which makes it difficult for a
third party to accept liability. Also, if you look at the CPS for most
public CAs, they really try to avoid all liability, or limit it
substantially, which calls into question the real utility of folks who
would perform this as a public service.
If one thinks about the model in a more local context, some of these issues
change, but then it also seems less likely that one should expect a high
availability, high security server to be provided in such contexts.
One of the biggest features of a well designed PKI is that it embodies a
distributed security model that scales through simple replication of static
data, a problem we know how to solve. It also has the property that to
spoof the identity of an end entity, one ought to have to subvert the CA
that issued the cert to that entity, although sloppy cross certification
and bad choices for PKI structure can make this situation worse.
The notion of cert validation servers is thus very disturbing. It might be
quite helpful for a server to collect certs and CRLs on behalf of users,
caching them locally, to facilitate cert path validation, so long as the
relying party does the validation. The reduced commiunication overhead
would be a good side effect, and fancy heuristics for figuring out where to
look to find the right certs could be centralized. However, once one has a
candidate cert path, and matching CRLs/OCSP responses, the validation
process isn't all that bad and is well within the capabilities of cert
clients.
Pushing validation off to a third party, especially in a public context,
further complicates the murky "trust model" problems we already face in the
PKI arena, e.g., because organizations that are authoritative for data are
failing to act as CAs (or at least RAs). In a country where few people can
program VCRs, the notion of complex certification hierarchies is
unrealistic, whether distributed or centralized processing is performed;
moving cert validation to servers will not fix this problem and it
certainly has the potential to create significant new vulnerabilities for
PKI implementations.
My view has been that OCSP is an appropriate mechanism IF the responder is
operated by the cognizant CA or an explicit delegee thereof. Once one
moves in the direction of having other than the issuer of a cert vouch for
its validity, one is heading down the slippery slope you descibed. At the
bottom of this slope is a swamp, which explains why the slope is slippery,
i.e., slime has been tracked onto the slope by those trying to escape the
swamp :-).
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA11974 for ietf-pkix-bks; Wed, 21 Oct 1998 14:43:48 -0700 (PDT)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11970 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 14:43:47 -0700 (PDT)
Received: from bah.com ([156.80.128.196]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.01) with ESMTP id AAA24884 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 17:45:12 -0400
Message-ID: <362E55ED.2289C800@bah.com>
Date: Wed, 21 Oct 1998 17:45:17 -0400
From: "Simonetti David" <simonetti_david@bah.com>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: IETF-PKIX <ietf-pkix@imc.org>
Subject: Announcing ISO CD-15782-1 Review and Ballot
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dear PKIX,
ISO CD-15782-1, Banking-Certificate Management Part 1: Public Key
Certificates, has recently been distributed for international review and
ballot. This draft standard had previously been released for ballot and
received sufficient approvals. However, due to the number of comments
incorporated, the working group has decided to send the document through
the ballot process once again. If you are interested in this standard,
please contact your national standards body. In the United States, this
group is ANSI Accredited Standards Committee X9.F.1.
An American national review and discussion session will be held at the
National Institute for Standards and Technology in Gaithersburg,
Maryland, on Friday, November 6. The session will be held at NIST
North, room 618, starting at 0900. Directions can be found at
<http://csrc.nist.gov/pki/twg/twg1998.htm#nist>. Those interested are
welcome to attend.
Copies of the draft standard may only be distributed to members of the
respective national standards bodies. However, copies will be available
at the review session held at NIST.
--
David Simonetti, Booz·Allen & Hamilton Inc.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08902 for ietf-pkix-bks; Wed, 21 Oct 1998 08:34:18 -0700 (PDT)
Received: from slack.lne.com (NoBody@slack.lne.com [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA08898 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 08:34:16 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id IAA25076; Wed, 21 Oct 1998 08:35:20 -0700
From: Eric Murray <ericm@lne.com>
Message-Id: <199810211535.IAA25076@slack.lne.com>
Subject: Re: A different architecture? (was Re: certificate path services
To: aarsenault@spyrus.com (Al Arsenault)
Date: Wed, 21 Oct 1998 08:35:19 -0700 (PDT)
Cc: Denis.Pinkas@bull.net, sgupta@cygnacom.com, Alan.Lloyd@OpenDirectory.com.au, ietf-pkix@imc.org
In-Reply-To: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com> from "Al Arsenault" at Oct 20, 98 09:29:30 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al Arsenault writes:
>
>
> The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
> DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
> an architecture that I've looked at in the past. I'm curious as to
> whether that's where some people really want to go.
>
> The architecture in question is modeled after what many people believe is
> the way the credit card system works. That is, I go into a store to
> purchase an item. I hand my credit card to the clerk to pay for the item.
> The clerk contacts an account authority, and asks the question "is this
> user (i.e., the credit card number) valid for this transaction (giving the
> dollar amount in question)?". The system responds with one of a variety of
> possible answers:
[deletia]
The account authority model is very useful for systems which
require authentication of messages from end-entity by a central
authority. As you point out, it's not as useful for key exchange
between end entities. But there are a lot of systems where
there isn't a key exchange but is authentication of end entities
by an authority.
The ANSI X9.59 electronic payment protocol (from the X9A10 working group)
is based on the account authority model. It integrates well with
systems like credit-card processing.
X9.59's model for account-authority authentication is based on
Lynn Wheeler's AADS work. See http://www.garlic.com/~lynn/.
--
Eric Murray N*Able Technologies www.nabletech.com
(email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA04942 for ietf-pkix-bks; Wed, 21 Oct 1998 02:37:06 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA04938; Wed, 21 Oct 1998 02:36:59 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA19932; Wed, 21 Oct 1998 11:37:20 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA14484; Wed, 21 Oct 1998 11:39:38 +0200 (DFT)
Message-ID: <362E2A67.B916557B@bull.net>
Date: Wed, 21 Oct 1998 11:39:38 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <ietf-pkix@imc.org>, S-MIME / IETF <ietf-smime@imc.org>
Subject: Cert. identifiers in OCSP and ESS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Certificate identifiers are used both the OCSP specification from the PKIX WG
and in the ESS specification from the S/MIME WG. This is the reason why this
mail is posted to both the S/MIME and PKIX WGs.
A recent proposal made by Jim Schaad has been to change the "CertID
"definition from the S/MIME WG to "ESSCertID" because we had two different
ASN1 definitions for the same name. :-(
I would prefer to call the later "SigningCert", since the Certificates are
signed attributes and thus remove the ESS co-notation. We would then have :
SigningCertificates ::= SEQUENCE {
certs SEQUENCE OF SigningCert,
(stuff deleted)
This is (only) a naming issue. :-)
A much more important concern is how to use the CertID content from ESS and
the CertID from the OCSP protocol altogether.
The current definition of CertID in ESS-08 is as follows:
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF CertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
CertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
The current definition of CertID in OCSP-07 is as follows:
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuer's public key
serialNumber CertificateSerialNumber }
One of the problems is that the current definition places limitations when
using both specifications.
A receiver of a signed message will be able to extract directly the
issuerSerial from the received message either from the CertID field or from
the issuerAndSerialNumber field contained in SignerInfo. It would be nice if
he would then immediately be able to ask to an OCSP server whether the
certificate is revoked or not. However, it can't.
He needs to obtain first the right issuerKeyHash, i.e. the hash of the
issuer's public key. For this he needs to fetch the certificate BEFORE making
the OCSP request AND to get the issuer public key. This can take long.
The goal is to be able to perform the operations in parallel or in whatever
order.
For this, what should be changed ? In which specification ?
I could end up the mail here. However, I will attempt to make a proposal which
is certainly not the single way to solve this issue. So other proposals
reaching the same goal are welcomed.
The idea is to optimise the cases where there is no name collisions for the
DNs of the CAs, without sacrifying any security. In case of name collision,
i.e. the same OCSP server supports two CAs with the same DN - which will be
very scarce in practice - performance will be much lower.
Let us redefine CertID in OCSP-07 is as follows:
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING OPTIONAL,
-- Hash of Issuer's public key
serialNumber CertificateSerialNumber }
i.e. let us make the issuerKeyHash OPTIONAL in the OCSP request. This means
that the receiver can immediately construct its OCSP request and send it to
the OCSP server while fetching after or in parallel the certificate and the
issuer public key.
In order to make sure that the right issuer was indeed selected, the OCSP
server will have to include in its response the issuerKeyHash. Thus "after the
fact", i.e. after fetching the certificate and the issuer public key, the
receiver can check that he got the right response from the OCSP server. If
not, he will have to query again the OCSP server using the issuerKeyHash in
its request.
I would thus propose that we modify OCSP to make issuerKeyHash optional and
this we add some text to explain that issuerKeyHash is optional for the
request but mandatory for the response.
I would also propose that we use the term "SigningCert" in the ESS document.
Denis
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA03868 for ietf-pkix-bks; Wed, 21 Oct 1998 02:10:18 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA03861 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 02:10:15 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Wed, 21 Oct 1998 10:10:56 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: versed@elvis.ru (Pavel Krylov)
cc: ietf-pkix@imc.org
Subject: Re: ASN1 question
In-reply-to: Your message of "Wed, 21 Oct 1998 11:40:22 +0400." <199810210740.LAA28045@relay2.elvis.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 Oct 1998 10:10:47 +0100
Message-ID: <28208.908961047@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Pavel Krylov writes:
>I have a question about INTEGER encoding in <draft-ietf-pkix-ipki-part1
-10.txt
>>.
>If You saw in <D.3 End-Entity Certificate Using RSA> section of this
draft,
>You saw RSAPublicKey encoded as BIT STRING. Please, see in inner
structure
>of RSAPublicKey. By specification it is:
>
> RSAPublicKey ::= SEQUENCE {
> modulus INTEGER, -- n
> publicExponent INTEGER -- e -- }
>
>In draft it looked so:
>
>0319 03 6b 107: . . . BIT STRING
> : 00 (0 unused bits)
> : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
^^ this zero
> : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
> : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
> : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
> : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
> : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
> : 56 15 c6 1c 8b 02 03 01 00 01
>
>Question: Why is there 0 ( zero ) in first INTEGER ( -- n )? By ASN1 if
>encoded integer value consists of more then one octet string, than
first
>octet shall not be 0xff or 0x00.
Pavel,
That zero is there to ensure that the INTEGER n is treated as a positive
number; note that the top bit of the next octet ('be') is set. If this
'00' were not present, the value would be regarded as negative.
You have not quoted the encoding rules correctly; it's the first NINE
bits (first OCTET and bit 8 of the next OCTET) which must not be
all 0 or 1. The above encoding conforms to this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA28443 for ietf-pkix-bks; Wed, 21 Oct 1998 00:39:08 -0700 (PDT)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA28424 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 00:38:56 -0700 (PDT)
Received: by relay2.elvis.ru (8.8.5/1.30) id LAA28045; Wed, 21 Oct 1998 11:40:22 +0400 (MSK DST)
Date: Wed, 21 Oct 1998 11:40:22 +0400 (MSK DST)
From: versed@elvis.ru (Pavel Krylov)
Message-Id: <199810210740.LAA28045@relay2.elvis.ru>
To: ietf-pkix@imc.org
Subject: ASN1 question
X-Sun-Charset: US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi All!
I have a question about INTEGER encoding in <draft-ietf-pkix-ipki-part1-10.txt>.
If You saw in <D.3 End-Entity Certificate Using RSA> section of this draft,
You saw RSAPublicKey encoded as BIT STRING. Please, see in inner structure
of RSAPublicKey. By specification it is:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e -- }
In draft it looked so:
0319 03 6b 107: . . . BIT STRING
: 00 (0 unused bits)
: 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
: b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
: 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
: 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
: 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
: 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
: 56 15 c6 1c 8b 02 03 01 00 01
Question: Why is there 0 ( zero ) in first INTEGER ( -- n )? By ASN1 if
encoded integer value consists of more then one octet string, than first
octet shall not be 0xff or 0x00.
___________________________________________________
Krylov Pavel Pavel.Krylov@trustworks.com
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA07704 for ietf-pkix-bks; Tue, 20 Oct 1998 18:56:53 -0700 (PDT)
Received: from gracilis.interspect.com (gracilis.interspect.com [199.175.156.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA07700 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 18:56:51 -0700 (PDT)
Received: from andrew-ii.gt.ca (161.255.16.172.admin.gt.ca [172.16.255.161]) by gracilis.interspect.com (8.6.10/8.6.9) with SMTP id SAA07604; Tue, 20 Oct 1998 18:45:36 -0700
Message-ID: <001d01bdfc96$99501c20$a1ff10ac@andrew-ii.gt.ca>
From: "Andrew Csinger" <csinger@interspect.com>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>, "Sarbari Gupta" <sgupta@cygnacom.com>, "Al Arsenault" <aarsenault@spyrus.com>
Cc: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, <ietf-pkix@imc.org>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Tue, 20 Oct 1998 18:59:37 -0700
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 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
This is more or less what I've been trying to sell for years :) In other
words, I think it's the right model, but so far, the market hasn't been
aggressively demanding the concept. It's an extremely simple model that
lends itself to a wide range of applications, from basic web access control
to a variety of on-line payment protocols. You might call it Connected-Mode
PKI (I do).
The strongest counter-argument has always been the contention that it would
be difficult, if not impossible, to guarantee reliability, availability and
performance. The best defense to this counter-argument is still the
"dial-tone argument," which is why I now work at a telecommunications
company :) Our approach involves a replicated, geographically distributed
directory server built for vendor-independent PKI. Available for sale or
lease :)
If PKIX were to head off on this road, I would be happy to help pave it.
Andrew
--------------------------------------------------------------
Andrew Csinger, VP Electronic Commerce GT Group Telecom
840 Howe Street, 3rd Floor tel: 604-688-3010
Vancouver, B.C., Canada V6Z 2L2 fax: 604-688-3011
http://www.gt.ca email: csinger@gt.ca
**** Information is Power. Plug in. ****
--------------------------------------------------------------
-----Original Message-----
From: Al Arsenault <aarsenault@spyrus.com>
To: Denis Pinkas <Denis.Pinkas@bull.net>; Sarbari Gupta
<sgupta@cygnacom.com>
Cc: 'Alan Lloyd' <Alan.Lloyd@OpenDirectory.com.au>; 'ietf-pkix@imc.org '
<ietf-pkix@imc.org>
Date: October 20, 1998 6:50 AM
Subject: A different architecture? (was Re: certificate path services [ was
RE: NEW Data type for certificate selection ? ])
>
>The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
>DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
>an architecture that I've looked at in the past. I'm curious as to
>whether that's where some people really want to go.
>
>The architecture in question is modeled after what many people believe is
>the way the credit card system works. That is, I go into a store to
>purchase an item. I hand my credit card to the clerk to pay for the item.
>The clerk contacts an account authority, and asks the question "is this
>user (i.e., the credit card number) valid for this transaction (giving the
>dollar amount in question)?". The system responds with one of a variety of
>possible answers:
>
> - reject the transaction because:
> - the credit card has been reported stolen (i.e., the "private key" has
>been compromised)
> - the credit card has expired
> - this transaction exceeds the available credit on the card
> - ...
>
> - accept the transaction; here's the authorization code.
>
>(Obviously, this is generally done electronically - the clerk or the
>customer swipes the card and the data are fed to a computer which provides
>the answer; the human clerk doesn't talk to another human unless there's
>some problem.)
>
>The clerk's next action depends on the account authority's response: write
>down the authorization code if approved; return the card with explanation
>if expired; keep card and call police if stolen; etc.
>
>
>To replicate this in the world of certificates, one would do something
like:
>
> - establish an account authority or transaction server to do all of the
>certificate path construction and validation; policy checking; etc. (You'd
>probably have more than one, depending on overall system load, reliability
>requirements, etc.)
> - configure each end-entity with the name and certificate of the
>transaction server to trust (again, you'd probably configure each one with
>a primary and one or more back-ups, but that could be worked on a
>case-by-case basis).
> - when an end-entity receives something to be validated (e.g., a signed
>S/MIME message; a request for SSL session set-up) it sends that information
>to the transaction server; basically, it's asking "right now, to the best
>of your knowledge, is this valid for what the sender wants to do?"
> - the transaction server receives the request, crunches through all of the
>signature validation, cert path construction and validation, policy
>processing, etc., and determines an answer which it sends to the requesting
>end-entity
> - the end-entity accepts or rejects the initial request based on the
>response it gets.
>
>We actually looked at this for a while in the MISSI effort (well, at least
>some of us did :-). There were a number of potential customers who wanted
>something like this because of some perceived advantages:
>
> 1 - it seems to fit the 'thin client' model that was all the rage a year
>or so ago. All the end-entity has to know is how to contact a transaction
>server; it doesn't have to have all of the cert path construction and
>validation logic. This makes the software with the most copies deployed be
>as small, simple, and cheap as possible.
>
> 2 - it doesn't force any user interactions at the end-entity. At worst,
>the user is told "accepted; authorization code = .." or "rejected:
reason...".
>
> 3 - it results in all of the information needed for non-repudiation (e.g.,
>certificates, cert paths, CRLs, etc.) being stored at one or a few central
>places, rather than having it scattered at various workstations all over
>the net. Further, since it was envisioned that the transaction servers
>would be high-end machines located in data centers, it would be easier to
>establish the procedures and processes necessary to protect and store the
>non-repudiation information.
>
> 4 - it seems to provide the most timely revocation notification of the
>system designs presented so far. Particularly if the transaction server is
>also the CA who issued the certificate in the first place, revocation
>notification can be distributed almost instantly upon the revocation
>decision being made.
>
>On the other hand, it does have a number of potential "issues" (to be
>polite). Some of them were:
>
> 1 - as Steve Kent has pointed out, it makes the transaction server an
>attractive target. I can derive great benefit from taking it over, and I
>can probably derive some benefit just from crashing the thing. (Military
>folk tend not to like designs with single points of failure; it's too
>darned easy to just drop a bomb on the thing.)As Denis Pinkas pointed out,
>you can alleviate some of this, but there's a cost attached.
>
> 2 - without worrying about attacks, it's likely that the transaction
>server will have major reliability & communications bandwidth requirements,
>especially if we're dealing with approvals required prior to the
>establishment of real-time connections. This will cause it to be a very
>expensive suite of hardware & software, compared with the rest of the
>system.
>
> 3 - it's relatively straightforward to handle signed messages. Encryption
>is worse, though - if you want the transaction server to handle encrypting
>and decrypting of data, you've turned your environment into something that
>looks a lot like what's described in Dean & Ottaway's
><draft-ietf-smime-domsec-00.txt>. You lose the ability to have data
>encrypted from end-user to end-user; you can only encrypt it from end-user
>to server or even server to server. Then, the data pass in the clear
>between end-user and server, or have to be separately encrypted for that
>link. That's not necessarily bad, but it may not be something that
>everybody wants to do. (If you want to have the transaction server handle
>signature but not encryption, you lose much of the benefit, because the
>end-entity will have to do all of the certificate path construction and
>validation just to encrypt & decrpyt data.)
>
>
>None of these "issues" is necessarily unsolvable in general, but they may
>be too hard in any particular environment, and taken together they can
>cause a lot of pain. (Ultimately, we didn't implement anything like this,
>because it was going to take a lot of time and money to solve the "issues",
>and it wasn't clear that all of them were readily solvable given our
>particular constraints.)
>
>Now, the reason for this long-winded message: with OCSP, PKIX took the
>first step toward this architecture, by setting up a server to basically
>check CRLs for the end-user. With DCS, it looks like we're taking the
>second step, with the cs and cpkc transaction types. So: will PKIX
>eventually move toward supporting the full architecture? If that's
>anybody's goal, should we be starting to look now at the entire set of
>things necessary to get there, rather than taking it piece by piece?
>
>Or, is it the case that nobody thinks that the architecture I described is
>ever in the plans, and all we're looking at is incremental service
>enhancements?
>
> Al Arsenault
>
>- my opinions are my own, yada, yada, yada
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21237 for ietf-pkix-bks; Tue, 20 Oct 1998 09:06:25 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA21233 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 09:06:23 -0700 (PDT)
Received: (qmail 32407 invoked from network); 20 Oct 1998 16:07:54 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 20 Oct 1998 16:07:54 -0000
Received: (qmail 1279 invoked from network); 20 Oct 1998 16:07:53 -0000
Received: from swilson.eris.dera.gov.uk (HELO eris.dera.gov.uk) (128.98.10.29) by mail-relay.eris.dera.gov.uk with SMTP; 20 Oct 1998 16:07:53 -0000
Message-ID: <362CB5B1.63F51523@eris.dera.gov.uk>
Date: Tue, 20 Oct 1998 17:09:21 +0100
From: "Stephen P. Wilson" <s.wilson@eris.dera.gov.uk>
Organization: Defence Evaluation & Research Agency.
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <aarsenault@spyrus.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: A different architecture? (was Re: certificate path services[ was RE: NEW Data type for certificate selection ? ])
References: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER> <3.0.6.32.19981020092930.0091b340@mail.spyrus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al Arsenault wrote:
>
> 3 - it's relatively straightforward to handle signed messages.
> Encryption is worse, though - if you want the transaction server to
> handle encrypting and decrypting of data, you've turned your
> environment into something that looks a lot like what's described in
> Dean & Ottaway's <draft-ietf-smime-domsec-00.txt>. You lose the
> ability to have data encrypted from end-user to end-user; you can only
> encrypt it from end-user to server or even server to server.
Just to clarify - the domsec draft doesn't prevent end to end user
encryption.
Steve.
--
Stephen Wilson. BSc (hons), AMIEE. S.Wilson@eris.dera.gov.uk
The views and statements contained in this message are entirely those
of the author and should not be considered as the opinion or policy
of any other person or organisation.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA20090 for ietf-pkix-bks; Tue, 20 Oct 1998 06:33:55 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA20086 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 06:33:54 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA22074; Tue, 20 Oct 1998 06:33:49 -0700 (PDT)
Message-Id: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 20 Oct 1998 09:29:30 -0400
To: Denis Pinkas <Denis.Pinkas@bull.net>, Sarbari Gupta <sgupta@cygnacom.com>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
In-Reply-To: <3627C5B7.2E7800AE@bull.net>
References: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
an architecture that I've looked at in the past. I'm curious as to
whether that's where some people really want to go.
The architecture in question is modeled after what many people believe is
the way the credit card system works. That is, I go into a store to
purchase an item. I hand my credit card to the clerk to pay for the item.
The clerk contacts an account authority, and asks the question "is this
user (i.e., the credit card number) valid for this transaction (giving the
dollar amount in question)?". The system responds with one of a variety of
possible answers:
- reject the transaction because:
- the credit card has been reported stolen (i.e., the "private key" has
been compromised)
- the credit card has expired
- this transaction exceeds the available credit on the card
- ...
- accept the transaction; here's the authorization code.
(Obviously, this is generally done electronically - the clerk or the
customer swipes the card and the data are fed to a computer which provides
the answer; the human clerk doesn't talk to another human unless there's
some problem.)
The clerk's next action depends on the account authority's response: write
down the authorization code if approved; return the card with explanation
if expired; keep card and call police if stolen; etc.
To replicate this in the world of certificates, one would do something like:
- establish an account authority or transaction server to do all of the
certificate path construction and validation; policy checking; etc. (You'd
probably have more than one, depending on overall system load, reliability
requirements, etc.)
- configure each end-entity with the name and certificate of the
transaction server to trust (again, you'd probably configure each one with
a primary and one or more back-ups, but that could be worked on a
case-by-case basis).
- when an end-entity receives something to be validated (e.g., a signed
S/MIME message; a request for SSL session set-up) it sends that information
to the transaction server; basically, it's asking "right now, to the best
of your knowledge, is this valid for what the sender wants to do?"
- the transaction server receives the request, crunches through all of the
signature validation, cert path construction and validation, policy
processing, etc., and determines an answer which it sends to the requesting
end-entity
- the end-entity accepts or rejects the initial request based on the
response it gets.
We actually looked at this for a while in the MISSI effort (well, at least
some of us did :-). There were a number of potential customers who wanted
something like this because of some perceived advantages:
1 - it seems to fit the 'thin client' model that was all the rage a year
or so ago. All the end-entity has to know is how to contact a transaction
server; it doesn't have to have all of the cert path construction and
validation logic. This makes the software with the most copies deployed be
as small, simple, and cheap as possible.
2 - it doesn't force any user interactions at the end-entity. At worst,
the user is told "accepted; authorization code = .." or "rejected: reason...".
3 - it results in all of the information needed for non-repudiation (e.g.,
certificates, cert paths, CRLs, etc.) being stored at one or a few central
places, rather than having it scattered at various workstations all over
the net. Further, since it was envisioned that the transaction servers
would be high-end machines located in data centers, it would be easier to
establish the procedures and processes necessary to protect and store the
non-repudiation information.
4 - it seems to provide the most timely revocation notification of the
system designs presented so far. Particularly if the transaction server is
also the CA who issued the certificate in the first place, revocation
notification can be distributed almost instantly upon the revocation
decision being made.
On the other hand, it does have a number of potential "issues" (to be
polite). Some of them were:
1 - as Steve Kent has pointed out, it makes the transaction server an
attractive target. I can derive great benefit from taking it over, and I
can probably derive some benefit just from crashing the thing. (Military
folk tend not to like designs with single points of failure; it's too
darned easy to just drop a bomb on the thing.)As Denis Pinkas pointed out,
you can alleviate some of this, but there's a cost attached.
2 - without worrying about attacks, it's likely that the transaction
server will have major reliability & communications bandwidth requirements,
especially if we're dealing with approvals required prior to the
establishment of real-time connections. This will cause it to be a very
expensive suite of hardware & software, compared with the rest of the
system.
3 - it's relatively straightforward to handle signed messages. Encryption
is worse, though - if you want the transaction server to handle encrypting
and decrypting of data, you've turned your environment into something that
looks a lot like what's described in Dean & Ottaway's
<draft-ietf-smime-domsec-00.txt>. You lose the ability to have data
encrypted from end-user to end-user; you can only encrypt it from end-user
to server or even server to server. Then, the data pass in the clear
between end-user and server, or have to be separately encrypted for that
link. That's not necessarily bad, but it may not be something that
everybody wants to do. (If you want to have the transaction server handle
signature but not encryption, you lose much of the benefit, because the
end-entity will have to do all of the certificate path construction and
validation just to encrypt & decrpyt data.)
None of these "issues" is necessarily unsolvable in general, but they may
be too hard in any particular environment, and taken together they can
cause a lot of pain. (Ultimately, we didn't implement anything like this,
because it was going to take a lot of time and money to solve the "issues",
and it wasn't clear that all of them were readily solvable given our
particular constraints.)
Now, the reason for this long-winded message: with OCSP, PKIX took the
first step toward this architecture, by setting up a server to basically
check CRLs for the end-user. With DCS, it looks like we're taking the
second step, with the cs and cpkc transaction types. So: will PKIX
eventually move toward supporting the full architecture? If that's
anybody's goal, should we be starting to look now at the entire set of
things necessary to get there, rather than taking it piece by piece?
Or, is it the case that nobody thinks that the architecture I described is
ever in the plans, and all we're looking at is incremental service
enhancements?
Al Arsenault
- my opinions are my own, yada, yada, yada
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA14311 for ietf-pkix-bks; Mon, 19 Oct 1998 20:19:22 -0700 (PDT)
Received: from heidegger.uol.com.br (smtp.uol.com.br [200.230.198.76]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA14307 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 20:19:15 -0700 (PDT)
Received: from csclientwin95-2 ([200.231.73.18]) by heidegger.uol.com.br (8.9.1/8.9.1) with SMTP id BAA02541 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 01:21:15 -0200 (EDT)
Message-ID: <001f01bdfbf1$c5ea5200$8044e7c8@csclientwin95-2>
Reply-To: "Ramirez" <marcio_ramirez@uol.com.br>
From: "Ramirez" <marcio_ramirez@uol.com.br>
To: <ietf-pkix@imc.org>
Subject: DigitalID for MS-Outlook Express ?
Date: Tue, 20 Oct 1998 04:18:12 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01BDFBE0.A6ADDC60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_001A_01BDFBE0.A6ADDC60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I need some help for building Digital ID for Microsoft Explorer.
I build with some extensions, but I think wich fault anything.
The my Client certificate is:
-----BEGIN CERTIFICATE-----
MIIBsQYJKoZIhvcNAQcCoIIBojCCAZ4CAQExADAPBgkqhkiG9w0BBwGgAgQAoIIB
gjCCAX4wgegCAXAwDQYJKoZIhvcNAQEEBQAwPDEYMBYGA1UEChMPQ29uc3VsdFNv
ZnR3YXJlMSAwHgYDVQQDExdDb25zdWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODEw
MTgxOTM4MjZaFw05OTEwMTgxOTM4MjZaMBkxFzAVBgNVBAMTDm1hcmNpb19yYW1p
cmV6MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAeWq6iOwb5NDfJxhNhW17R7cnRrST
D9dE3XmIiwhioSFO3lva3q89G/yvf878IwsoGO4j4ae3s0Qi3ndxZuZm9QIDAQAB
MA0GCSqGSIb3DQEBBAUAA4GBANIdRuYLsmgAfh6IWrstNxBr8mDewAb6fXJ1OOcM
sPgINwmeWPk7t25h6237mxUN9+X/By+na9sabzfvOjcFwqDdEjuHjOQmm1Qkz+mo
RzPjuF7ux3UdHJdT0916TS1M7GqcpP8QW0RLYMNxY0YDxOm6z+AV2zzG3GoPcVx1
6WPFMQA=3D
-----END CERTIFICATE-----
Version=3D1 (yet set with 2 to)
The extensions includes are:
SubjectAltName: email (RFC822)
ext: oid =3D "2.5.29.17"
critial =3D false
understood =3D false
gnames: parsed =3D true
KeyUsage: digitalSiganture =3D true
nonRepudiation =3D true;
keyEncipherment =3D true;
dataEncipherment =3D false;
keyAgreement =3D false;
keyCertSign =3D false;
cRLSign =3D false;
encipherOnly =3D false;
decipherOnly =3D false;
ext: oid =3D "2.5.29.15"
critial =3D true
understood =3D false
KeyExtensionUsage: oid(int) =3D EMAIL_PROT;
oid(char) =3D "1.3.6.1.5.5.7.3.4";
ext: oid =3D "2.5.29.37"
critial =3D false
understood =3D false
And my CA certificate is:
-----BEGIN CERTIFICATE-----
MIIBuDCCASGgAwIBAQIBIDANBgkqhkiG9w0BAQQFADAiMSAwHgYDVQQDExdDb25z
dWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODEwMTgxNTQ0MjdaFw05OTEwMTgxNTQ0
MjdaMCIxIDAeBgNVBAMTF0NvbnN1bHRTb2Z0d2FyZSBDbGFzcyAxMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQD491Bjirg7jKgnamn15yaoo9Rs+FUb+w3PXLnJ
6RvKGWA5B+53K+NjHYtVg8DG1O8rZbWS+8C5E/ZU16TpAATkpfj3dWgOL1HAtmu4
gWiNKZ0+UIzISMt7aI26RpQHeLyM+dc5pTFP5nDEtD/Q//xalfihHp7VWQXXd5g0
u1D8qwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBADZXLvOMXUjjcPrzld17c5qxOYCv
m89Uh6u+r+GUukU4UuIDjQfm6jBtHnDKhsgxjXaz1pv5IX0YIUmsXnuqNZkBNlUp
RhV/2wO58XBI013DO4tU5HbQbe0mN+Cj0Oz+LRVfJgR7pvnKOwYzExN5G2EA1rrf
trmslxtHhYJx3bqc
-----END CERTIFICATE-----
Version=3D2
The extensions includes are:
BasicConstraints:
ca =3D true;
ext:
oid(int) =3D BASIC_CONSTRAINTS;
oid(char) =3D "2.5.29.19";
critical =3D true;
understood =3D false;
The client certificate is load succesfully into clientAuthority, but, =
don't load in DigitalID's MS-Outlook Express accounts.
What I need ?
Thanks
------=_NextPart_000_001A_01BDFBE0.A6ADDC60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2><BR>I need some help for building =
Digital ID for=20
Microsoft Explorer.<BR>I build with some extensions, but I think wich =
fault=20
anything.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The my Client certificate =
is:<BR>-----BEGIN=20
CERTIFICATE-----<BR>MIIBsQYJKoZIhvcNAQcCoIIBojCCAZ4CAQExADAPBgkqhkiG9w0BB=
wGgAgQAoIIB<BR>gjCCAX4wgegCAXAwDQYJKoZIhvcNAQEEBQAwPDEYMBYGA1UEChMPQ29uc3=
VsdFNv<BR>ZnR3YXJlMSAwHgYDVQQDExdDb25zdWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODE=
w<BR>MTgxOTM4MjZaFw05OTEwMTgxOTM4MjZaMBkxFzAVBgNVBAMTDm1hcmNpb19yYW1p<BR>=
cmV6MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAeWq6iOwb5NDfJxhNhW17R7cnRrST<BR>D9dE3=
XmIiwhioSFO3lva3q89G/yvf878IwsoGO4j4ae3s0Qi3ndxZuZm9QIDAQAB<BR>MA0GCSqGSI=
b3DQEBBAUAA4GBANIdRuYLsmgAfh6IWrstNxBr8mDewAb6fXJ1OOcM<BR>sPgINwmeWPk7t25=
h6237mxUN9+X/By+na9sabzfvOjcFwqDdEjuHjOQmm1Qkz+mo<BR>RzPjuF7ux3UdHJdT0916=
TS1M7GqcpP8QW0RLYMNxY0YDxOm6z+AV2zzG3GoPcVx1<BR>6WPFMQA=3D<BR>-----END=20
CERTIFICATE-----</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Version=3D1 (yet set with 2 =
to)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The extensions includes =
are:<BR>SubjectAltName:=20
email (RFC822)<BR> ext: oid =3D =
"2.5.29.17"<BR> critial=20
=3D false<BR> understood =3D false</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> gnames: parsed =3D =
true</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyUsage: digitalSiganture =3D =
true<BR> nonRepudiation =3D true;<BR> keyEncipherment =3D=20
true;<BR> dataEncipherment =3D false;<BR> keyAgreement =3D=20
false;<BR> keyCertSign =3D false;<BR> cRLSign =3D =
false;<BR> =20
encipherOnly =3D false;<BR> decipherOnly =3D false;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> ext: oid =3D=20
"2.5.29.15"<BR> critial =3D true<BR> understood =
=3D=20
false</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyExtensionUsage: oid(int) =3D=20
EMAIL_PROT;<BR> oid(char) =3D=20
"1.3.6.1.5.5.7.3.4";</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> ext: oid =3D=20
"2.5.29.37"<BR> critial =3D false<BR> understood =
=3D=20
false</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2><BR>And my CA certificate =
is:<BR>-----BEGIN=20
CERTIFICATE-----<BR>MIIBuDCCASGgAwIBAQIBIDANBgkqhkiG9w0BAQQFADAiMSAwHgYDV=
QQDExdDb25z<BR>dWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODEwMTgxNTQ0MjdaFw05OTEwMT=
gxNTQ0<BR>MjdaMCIxIDAeBgNVBAMTF0NvbnN1bHRTb2Z0d2FyZSBDbGFzcyAxMIGfMA0GCSq=
G<BR>SIb3DQEBAQUAA4GNADCBiQKBgQD491Bjirg7jKgnamn15yaoo9Rs+FUb+w3PXLnJ<BR>=
6RvKGWA5B+53K+NjHYtVg8DG1O8rZbWS+8C5E/ZU16TpAATkpfj3dWgOL1HAtmu4<BR>gWiNK=
Z0+UIzISMt7aI26RpQHeLyM+dc5pTFP5nDEtD/Q//xalfihHp7VWQXXd5g0<BR>u1D8qwIDAQ=
ABMA0GCSqGSIb3DQEBBAUAA4GBADZXLvOMXUjjcPrzld17c5qxOYCv<BR>m89Uh6u+r+GUukU=
4UuIDjQfm6jBtHnDKhsgxjXaz1pv5IX0YIUmsXnuqNZkBNlUp<BR>RhV/2wO58XBI013DO4tU=
5HbQbe0mN+Cj0Oz+LRVfJgR7pvnKOwYzExN5G2EA1rrf<BR>trmslxtHhYJx3bqc<BR>-----=
END=20
CERTIFICATE-----</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Version=3D2</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The extensions includes=20
are:<BR>BasicConstraints:<BR> ca =3D true;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> ext:<BR> oid(int) =3D=20
BASIC_CONSTRAINTS;<BR> oid(char) =3D =
"2.5.29.19";<BR> =20
critical =3D true;<BR> understood =3D false;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The client certificate is load =
succesfully into=20
clientAuthority, but, don't load in DigitalID's MS-Outlook Express=20
accounts.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>What I need ?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 =
size=3D2><BR>Thanks</FONT></DIV></BODY></HTML>
------=_NextPart_000_001A_01BDFBE0.A6ADDC60--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA12815 for ietf-pkix-bks; Mon, 19 Oct 1998 17:10:00 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA12811 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 17:09:59 -0700 (PDT)
Received: from [128.33.238.135] (TC135.BBN.COM [128.33.238.135]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id UAA19959; Mon, 19 Oct 1998 20:11:12 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011709b2517e919c08@[128.33.238.135]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D492@DSG1>
Date: Mon, 19 Oct 1998 19:55:01 -0400
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
>> Yes, one can imagine offloading this processing, but a fundamental
>> assumption underlying certificates is that one does not need to rely
>> on
>> other parties for such processing and storage. Thus directories are
>> untrusted repositories, which can do not worse than store bad data.
> [Alan Lloyd]
> That is why a certficate is signed so that in can be stored and
>transferred with and between "cryptographically" untrusted repositories.
The issue here is not the storage of signed data in directories, it is the
notion that the directory would perform a search for a user to collect
certs and CRLs, process them, and tell the user whether the cert was valid
or not. This abrogation of responsibility by the user, to a third party,
is dangerous.
>> I
>> would not want to confuse this long term existing model of what a
>> directory
>> does with the notion you;re suggesting, of a component/system that
>> performs
>> lots of processing that we currently envision being done by a
>> certificate
>> consuming system. I'm not saying we ought not consider such
>> alternative
>> models, but le's not confuse folks by calling them directories,
>> trusted
>> directories, etc.
> [Alan Lloyd] There is no confusion with the systems I work
>with. There are two approaches.
>
> 1. Where the CA's information model re root paths and cross
>certs and CRLs etc are sensibly designed and organised and matching
>rules applied from standard directory access (Search Ops) that can
>return a result. In this case the "processing" is placed on the
>directory to "validate" the certificate path issues.. all the clent
>needs to do is offer the cert require validation without prior knowledge
>of the information designs or the operational relationships that a
>directory enabled CA function might have.
I believe that we do fundamentally disagree here. Directories are
repositories that can return data stored in them, e.g., in response to
searches. Validation of cert paths is something a directory does for its
own use when employing certs for authentication in support of directory
access control. It is the relying party in such circumstances and thus is
doing what any such party ought to do as part of cert validation.
> 2. The second approach - which still promotes a validation -
>service based model is to have directory attached, directory enabled
>processes.. This is a nicer approach because these can scale easier -
>eg. we (the third rock from the sun) need to deal with global services
>that have 100m + users with at least 10 certs each -- and simple,
>business domain agile clients.
I don't know what this is saying.
>> >Phone systems are good - my telephone does not have software in it
>> to
>> >prove the telephone company can provide it with its phone number !
>> :-)
>>
>> I don't really see the relevance of this last analogy.
> [Alan Lloyd] This quite straight forward. I do not see the
>sense behind writing complex clients that when validating a certificate,
>the client goes has to know all the relationships of a CA, eg roots and
>cross certs, what extensions are used in CA certs, what may or may not
>be valid, etc for all the subjects (the cert subject) it deals with in
>the many domains of business they might work in.
> CAs may wish to improve their information models and objects
>over time that deal with cross certs and multiple roots - at any time.
>Why should such a change invalidate all the client software that deals
>with validation?.
It should not invalidate client software, because such software should be
just as capable of validating the resvied PKI structure as it was of
validating certs under the previous structure. We have standards for cert
processing procisely so that clients can do this correctly, in a standard
fashion.
> As said the PKI /CA design at present has not dealt with (IMHO
>)very well the way large scale directory systems are needed for wider
>use of X.509 and EC or the operational and service based issues of
>validation - with the emphasis of making client software as portable and
>as simple as possible. The designs at the moment are "technically
>orchestrated" re a CA information functional and information
>relationship design and certainly too complex - because the designs of
>the CA with all its mystery points is enforced on the client process.
Sorry. These are vague complaints.
> This is similar situation why LDAP is in a mess.
>
> If one designs a system with (distributed) functions (like the
>phone system or a directory SERVICE) and then one designs the access
>protocol, the system services actually constrains what is in the access
>protocol is and the software in the client that uses the access
>protocol ca actually do. ie. the system services and operations
>constrain any shift in what upgrades can occur on the access interface.
>
> LDAP approach - make the directory system as vague as possible,
>add protocol features that have an effect in the client and the server
>in a random way, ie make the processing of the protocol elements affect
>how the system and the clients evolve to a point where any new feature
>affects the wider interoperability of clients and servers/services. ie
>many features in LDAP MAY work OK with a single server address book (and
>need a lot of human effort), but if LDAP is used with a real distributed
>directory service (eg. X.500) then many of the funny features of LDAP
>cannot be used. - in addition , different knowledge, referral,
>replication, authentication, password and certficate management issues
>apply depending on what type of service supports the "LDAP" interface.
>
> A system model re services (such as cert validation) would
>strike me as the only way to start.
I don't want to debate LDAP issues; this is a PKI list. Your e-mail address
suggests that you may work for a company that believes directories are the
solution to lots of problems. Personally, I don't share that belief, but
the more central issues is that I'd like us to not confuse the current
definition of directory services, as defined in X.500 and LDAP, with some
possible future set of cert validation services. About 5 years ago we
developed such a service as part of a DARPA program; it validated certs
that a client could not validate because of algorithm incompatability or
similar constraints. Been there, done that. However, the better use of
the service was to collect certs and CRLs for the client and deliver them
in a form to simplify client cert path validation. That's not an
unreasonable service, but it's a far cry fro asking a third party to do the
validation for you.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA12804 for ietf-pkix-bks; Mon, 19 Oct 1998 17:09:36 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA12800 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 17:09:35 -0700 (PDT)
Received: from [128.33.238.135] (TC135.BBN.COM [128.33.238.135]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id UAA19923; Mon, 19 Oct 1998 20:10:46 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011704b25177b5ff58@[128.33.238.135]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D48E@DSG1>
Date: Mon, 19 Oct 1998 19:15:22 -0400
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: ietf-pkix@imc.org
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
I can appreciate the directory perspective of "CA-ness" but I don't think
that captures all of the issues being raised here. CAs exist independent
of directories, so many aspects of a CA may not be captured by by a purely
directory-centric view. Still, to the extent that folks look to
directories to help with cert selection, it's good to keep in mind what
features a directory can offer to help in addressing this problem.
steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07367 for ietf-pkix-bks; Mon, 19 Oct 1998 06:37:49 -0700 (PDT)
Received: from TYO203.gate.nec.co.jp (TYO203.gate.nec.co.jp [202.32.8.211]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07363 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 06:37:48 -0700 (PDT)
Received: from mailsv.nec.co.jp (mailsv-le1 [192.168.1.90]) by TYO203.gate.nec.co.jp (8.9.1a/3.7W98092815) with ESMTP id WAA14846 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:38:33 +0900 (JST)
Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.2.2]) by mailsv.nec.co.jp (8.9.1a/3.7W-MAILSV-NEC) with ESMTP id WAA00426 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:38:32 +0900 (JST)
Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.8.8+2.7Wbeta7/3.3W9-GW_CCS) with ESMTP id WAA19137 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:33:45 +0900 (JST)
Received: from sple243.ccs.mt.nec.co.jp (sple243.ccs.mt.nec.co.jp [172.16.5.41]) by mail.ccs.mt.nec.co.jp (8.9.1a/3.6W-CCS_Master) with ESMTP id WAA02733 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:38:32 +0900 (JST)
Received: from ccs.mt.nec.co.jp by sple243.ccs.mt.nec.co.jp (8.8.5+2.7Wbeta4/6.4J.6-slave-1.0) id WAA29988; Mon, 19 Oct 1998 22:38:29 +0900 (JST)
Message-Id: <199810191338.WAA29988@sple243.ccs.mt.nec.co.jp>
To: ietf-pkix@imc.org
Subject: Root CA key Update in CMP
X-Mailer: Mew version 1.70 on Emacs 19.28.6 / Mule 2.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 19 Oct 1998 22:38:28 +0900
From: Mine Sakurai <m-sakura@ccs.mt.nec.co.jp>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi,
I'm trying to experiment a Root CA key update according to the CMP
description.
I have some questions about the "OldwithNew" and the "NewwithOld"
certificates.
1. Should both the certificates have entirely the same Subject with
the "OldwithOld" or the "NewwithNew" certificate ?
I would like to put the string "OldwithNew" somewhere in the
Subject of the "OldwithNew" certificate to avoid confusion.
(the string "NewwithOld" in the Subject of the "NewwithOld",
similary)
Is it wrong?
2. Is there any reason the "OldwithNew" certificate is issued prior to the
"NewwithOld"?
I think it is natural that the "NewwithOld" certificate is first
issued with the old private key and then the "OldwithNew" and the
"NewwithNew" is issued with the new private key.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mine Sakurai E-mail: m-sakura@ccs.mt.nec.co.jp
Platform Technology Laboratory,
Internet Technology Laboratories, NEC Corp., Tokyo, JAPAN
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA28719 for ietf-pkix-bks; Sun, 18 Oct 1998 23:45:51 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA28705 for <ietf-pkix@imc.org>; Sun, 18 Oct 1998 23:45:42 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05XRZ>; Mon, 19 Oct 1998 16:42:28 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D497@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Carlisle Adams'" <carlisle.adams@entrust.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Sarbari Gupta'" <sgupta@cygnacom.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: certificate path services [ was RE: NEW Data type for certifi cate selection ? ]
Date: Mon, 19 Oct 1998 16:42:25 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
IMHO This issue is not solved with YAP - yet another protocol, .....As
these create yet more complexity, scaling issues, knowledge and
addressing issues when building a system ..
Why is OCSP and yet another being promoted - as they seem to solve
nothing. - and what they do is add yet more implementation problems.
The issue of CA info/ client validation is one of (object - directory
style) information, information management, system knowledge and dealing
with a name based distributed environment. The protocol , semantics and
syntax of the information transfer and testing of all this can all be
dealt with quite naturally by directory services.
So unless OCSP or cert server protocol specs can define the information
model (in named distributed objects) for CAs, multiple paths, and the
validation process that clients need .. then what to they solve.
regards alan
> -----Original Message-----
> From: Carlisle Adams [SMTP:carlisle.adams@entrust.com]
> Sent: Friday, 16 October 1998 1:50
> To: 'Alan Lloyd'; 'Sarbari Gupta'
> Cc: 'ietf-pkix@imc.org '
> Subject: RE: certificate path services [ was RE: NEW Data type
> for certificate selection ? ]
>
> Hi Sarbari,
>
> > ----------
> > From: Sarbari Gupta[SMTP:sgupta@cygnacom.com]
> > Sent: Thursday, October 15, 1998 10:46 AM
> > To: 'Alan Lloyd'
> > Cc: 'ietf-pkix@imc.org '
> > Subject: certificate path services [ was RE: NEW Data type for
> > certificate selection ? ]
> >
> > I seem to agree with Alan that there are certain situations where it
> > would be very beneficial to have third-party services available to
> > assist with certificate path development and/or validation.
> >
> > If (and when) large scale PKIs become widely deployed, it could
> become
> > a
> > real problem for each end entity to look up and then validate the
> > certificate path to its peer's certificate. It requires a large
> amount
> > of processing power as well as complicated path processing software
> to
> > do this task. Additionally, it requires repeated interactions with a
> > remote Directory Server to build the certificate path.
> >
> > There are (at least) two ways to resolve this issue:
> >
> > 1) We introduce the concept of a trusted service, let's call it
> > "Certificate Path Validation Service (CPVS)" which could take in
> > requests for validation (comprising the end entity certificate and
> > possibly a trusted root, policy IDs, etc.) and return an YES/NO
> > answer.
> > The CPVS could be hosted on a high-end server that caches recent
> > requests and has the capability to interface with
> > Directories/Repositories over the internet to quickly obtain an
> answer
> > for the subscriber, thus relieving the end entity system from the
> > overhead of certificate path processing. The CPVS would also support
> > revocation models. The CPVS would be particularly useful in an
> > organizational environment, where a single dedicated system runs the
> > CPVS for that organization and services path validation requests for
> > other users within the organization. To support the notion of a CPVS
> > service, a new service interface needs to be defined and
> standardized.
> >
> >
> This is precisely one of the services specified in the Data
> Certification Server protocol. Please take a look at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt
> (recently re-introduced into the PKIX Working Group) and let me know
> if
> this meets the functionality you had in mind.
>
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> cadams@entrust.com
> --------------------------------------------
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA13633 for ietf-pkix-bks; Sun, 18 Oct 1998 19:16:45 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA13629 for <ietf-pkix@imc.org>; Sun, 18 Oct 1998 19:16:37 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05XQ0>; Mon, 19 Oct 1998 12:13:35 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D492@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Stephen Kent'" <kent@bbn.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 19 Oct 1998 12:13:33 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line....
> -----Original Message-----
> From: Stephen Kent [SMTP:kent@bbn.com]
> Sent: Thursday, 15 October 1998 23:40
> To: Alan Lloyd
> Cc: 'ietf-pkix@imc.org '
> Subject: RE: NEW Data type for certificate selection ?
>
> Alan,
>
> >Yes the problem is a path issue. where CAs may have multiple paths to
> >their roots or other CAs, multiple approaches to revokation, Users
> have
> >multiple certficates, clients might be root and domain agile, etc.
> >
> >I have views on this which says we should not complicate the
> certificate
> >any more- so the client gets even more complex and untrusted, we
> should
> >use some simpler methods of validation with the assistance of the
> >directory service.
>
> Yes, one can imagine offloading this processing, but a fundamental
> assumption underlying certificates is that one does not need to rely
> on
> other parties for such processing and storage. Thus directories are
> untrusted repositories, which can do not worse than store bad data.
[Alan Lloyd]
That is why a certficate is signed so that in can be stored and
transferred with and between "cryptographically" untrusted repositories.
> I
> would not want to confuse this long term existing model of what a
> directory
> does with the notion you;re suggesting, of a component/system that
> performs
> lots of processing that we currently envision being done by a
> certificate
> consuming system. I'm not saying we ought not consider such
> alternative
> models, but le's not confuse folks by calling them directories,
> trusted
> directories, etc.
[Alan Lloyd] There is no confusion with the systems I work
with. There are two approaches.
1. Where the CA's information model re root paths and cross
certs and CRLs etc are sensibly designed and organised and matching
rules applied from standard directory access (Search Ops) that can
return a result. In this case the "processing" is placed on the
directory to "validate" the certificate path issues.. all the clent
needs to do is offer the cert require validation without prior knowledge
of the information designs or the operational relationships that a
directory enabled CA function might have.
2. The second approach - which still promotes a validation -
service based model is to have directory attached, directory enabled
processes.. This is a nicer approach because these can scale easier -
eg. we (the third rock from the sun) need to deal with global services
that have 100m + users with at least 10 certs each -- and simple,
business domain agile clients.
> >Phone systems are good - my telephone does not have software in it
> to
> >prove the telephone company can provide it with its phone number !
> :-)
>
> I don't really see the relevance of this last analogy.
[Alan Lloyd] This quite straight forward. I do not see the
sense behind writing complex clients that when validating a certificate,
the client goes has to know all the relationships of a CA, eg roots and
cross certs, what extensions are used in CA certs, what may or may not
be valid, etc for all the subjects (the cert subject) it deals with in
the many domains of business they might work in.
CAs may wish to improve their information models and objects
over time that deal with cross certs and multiple roots - at any time.
Why should such a change invalidate all the client software that deals
with validation?.
As said the PKI /CA design at present has not dealt with (IMHO
)very well the way large scale directory systems are needed for wider
use of X.509 and EC or the operational and service based issues of
validation - with the emphasis of making client software as portable and
as simple as possible. The designs at the moment are "technically
orchestrated" re a CA information functional and information
relationship design and certainly too complex - because the designs of
the CA with all its mystery points is enforced on the client process.
This is similar situation why LDAP is in a mess.
If one designs a system with (distributed) functions (like the
phone system or a directory SERVICE) and then one designs the access
protocol, the system services actually constrains what is in the access
protocol is and the software in the client that uses the access
protocol ca actually do. ie. the system services and operations
constrain any shift in what upgrades can occur on the access interface.
LDAP approach - make the directory system as vague as possible,
add protocol features that have an effect in the client and the server
in a random way, ie make the processing of the protocol elements affect
how the system and the clients evolve to a point where any new feature
affects the wider interoperability of clients and servers/services. ie
many features in LDAP MAY work OK with a single server address book (and
need a lot of human effort), but if LDAP is used with a real distributed
directory service (eg. X.500) then many of the funny features of LDAP
cannot be used. - in addition , different knowledge, referral,
replication, authentication, password and certficate management issues
apply depending on what type of service supports the "LDAP" interface.
A system model re services (such as cert validation) would
strike me as the only way to start.
regards alan
> Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA13279 for ietf-pkix-bks; Sun, 18 Oct 1998 17:59:21 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA13275 for <ietf-pkix@imc.org>; Sun, 18 Oct 1998 17:59:17 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05XQV>; Mon, 19 Oct 1998 10:56:08 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D48E@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Sarbari Gupta'" <sgupta@cygnacom.com>, "'Dwight Arthur'" <dwightarthur@mindspring.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 19 Oct 1998 10:56:07 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line
> -----Original Message-----
> From: Sarbari Gupta [SMTP:sgupta@cygnacom.com]
> Sent: Tuesday, 13 October 1998 1:29
> To: 'Dwight Arthur'
> Cc: ietf-pkix@imc.org
> Subject: RE: NEW Data type for certificate selection ?
>
> I have been following this thread with great interest. Since the
> thread
> was rekindled, I wanted to offer another usage model that needs a
> slightly different selection criterion. I was not sure whether this
> model was discussed before on this list.
>
> One of the certificate selection mechanisms in use today is based on
> matching the issuer name. SSL implementations allow this form of
> selection. There is another variant of this model that may also be
> useful. In this variant, the certificate selection is based on a
> prefix
> of the issuer name. For example, the selection may be done based only
> on
> the country name and the organization name components of the issuer
> DN.
> Thus, if a large organization has multiple CAs, the selection criteria
> may logically be "a certificate issued by the organization" instead of
> the more restrictive "a certificate issued by a particular CA within
> the
> organization".
[Alan Lloyd] Being a directory oriented person. I think that
there seems to be a confused line between a function called a CA which
is represented by a directory object (that has certificates),etc and how
CA functions are represented in a directory system.
An organisation can in fact be a CA simply by adding a CA V2 aux
class to the OC definition of the "organisation" or org untit concerned.
In fact any directory object can take on the role of a CA
function by adding the aux OC to the entry eg a CA can be a Org person,
a device, an application, a ship, a tank or a kerbside kiosk or
automated ticket machine in a railway station.
Its the question of how such objects apply a directory
information model (CRLs, root paths, validity indications, etc) and how
the respective client software validates certificates against such
variances and differing application requirements is the issue..
Perhaps the help of directory services and matching rules may
this work?
regards alan
Do the X.500 matching rules support this kind of selection?
This model
> may be useful for SSL connections.
>
[Alan Lloyd] snip
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21532 for ietf-pkix-bks; Fri, 16 Oct 1998 06:15:34 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21521 for <ietf-pkix@imc.org>; Fri, 16 Oct 1998 06:14:51 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id PAA14063; Fri, 16 Oct 1998 15:14:35 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id PAA17538; Fri, 16 Oct 1998 15:16:22 +0200 (DFT)
Message-ID: <3627C5B7.2E7800AE@bull.net>
Date: Fri, 16 Oct 1998 15:16:25 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Sarbari Gupta <sgupta@cygnacom.com>
CC: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: certificate path services [ was RE: NEW Data type for certificate selection ? ]
References: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari,
It is nice to hear from you on the PKIX list now.
I will take the occasion of this new thread to comment about the CDS draft
and place this requirement in a broader perspective. This means a rather
long E-mail. :-(
> I seem to agree with Alan that there are certain situations where it
> would be very beneficial to have third-party services available to
> assist with certificate path development and/or validation.
>
> If (and when) large scale PKIs become widely deployed, it could become a
> real problem for each end entity to look up and then validate the
> certificate path to its peer's certificate. It requires a large amount
> of processing power as well as complicated path processing software to
> do this task. Additionally, it requires repeated interactions with a
> remote Directory Server to build the certificate path.
Agreed.
> There are (at least) two ways to resolve this issue:
>
> 1) We introduce the concept of a trusted service, let's call it
> "Certificate Path Validation Service (CPVS)" which could take in
> requests for validation (comprising the end entity certificate and
> possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
> The CPVS could be hosted on a high-end server that caches recent
> requests and has the capability to interface with
> Directories/Repositories over the internet to quickly obtain an answer
> for the subscriber, thus relieving the end entity system from the
> overhead of certificate path processing. The CPVS would also support
> revocation models. The CPVS would be particularly useful in an
> organizational environment, where a single dedicated system runs the
> CPVS for that organization and services path validation requests for
> other users within the organization. To support the notion of a CPVS
> service, a new service interface needs to be defined and standardized.
This can be seen as one of the services a "Data Validation Service (DVS)"
(see later for the justification of this new name) would provide.
The comments are relative to the document: Internet X.509 Public Key
Infrastructure. Data Certification Server Protocols
<draft-ietf-pkix-dcs-00.txt>. The various facets of the DCS functionality
need to be looked at very carefully before looking at the protocols (i.e. I
will not deal with the protocols).
The abstract says:
"Useful Data Certification Server responsibilities in a PKI are to validate
signatures and to provide up-to-date information regarding the status of
public key certificates".
This addresses two items:
a) validation of signatures,
b) up-to-date information regarding the status of public key certificates.
Let us address the validation of signatures first.
When a signer signs something this is in accordance with a security policy.
That policy may specify one OR MORE trusted points but also the allowed
certification paths that can be used. That policy may be implicit for a
given application/context or may be extracted from the data itself, e.g.
when you receive a signed contract that contains the policy.
The policy does not specify only the trusted points. It may also specify
other conditions, like which TSAs (Time Stamping Authorities) need to be
involved, the grace time period for a user to ask for the revocation of its
certificate in case of a private key compromise, ...
The implication is that nominating one or more trusted points is not enough
in the general case and only a security policy is able to encompass all the
checks that need to be made.
Degenerated cases may consider only one or more trusted point, but saying
that the signature is *valid* is insufficient unless we say against what
(see later the various cases that may be considered).
Considering a "certification path validity checking" would thus be more
appropriate but still restrictive.
An intermediate conclusion is thus to consider in addition to the validity
of a signature, the validity of a certification path. What means performing
a checking against trusted points ? This includes the certification path
that may be used. One way (but not the single one) to define them, is to use
self-signed certificates that include naming constraints. The key point is
to remember that it is not because a certificate exists in a Repository that
it should be used.
When trust points are used instead of security policies, it would be needed
to refer to ONE OR MORE self-signed certificates. In order to make sure that
the path used for the verification is correct, it should be given back
(including CRLs or OCSP responses and ARLs) to the requester so that either
it can check that it is OK and/or that it can be rechecked in the same way
by another DVS.
Let us then address the second item: up-to-date information regarding the
status of public key certificates.
The *status* of public key certificates is already being addressed by OCSP,
so we should not duplicate the work here. It is NOT addressed for an old
status, but it is not evident that it should (see arguments later on, why it
should not).
It would be better to consider "up-to-date information regarding the
*validity* of public key certificates".
Since both items would be about validity/validation, a better name would be
a Data Validation Server (DVS) instead of DCS where the word "Certification"
(from Data Certification server) may be confusing with the function of a CA.
As an example of this kind of problem the actual text speaks about: "When
certifying a public key certificate, the DCS verifies ..." A CA
(Certification Authority) does such a certification, not a DCS.
In the introduction (section 1) three functions are introduced:
1) validity and correctness of an entity's claim to possess data,
2) validity and revocation status of an entity's public key certificate,
3) validity and correctness of another entity's signature.
For the item 1, the TSA (Time Stamping Authority) already allows to prove
that the requester possessed the data in the request at the time indicated
by the DVS.
Is it thus needed in addition to consider the case where a single entity
(the DVS) both proves that the requester possessed the data in the request
and a valid signature key at the time indicated by the DVS ?
It would be better to keep the two functionality independent. The TSA
signature is always for later use, while the DVS signature is not (see
additional arguments later on). If needed, the same entity can support both
protocols. Since the last case (3) is about any entity's signature, it would
be easier to consider only that case and use the TSA, in addition, when
needed.
In the item 2, if validity is checked, by implication the revocation status
is also checked.
Note: It is not clear to understand what "correctness" means in addition to
validity in the items 1) and 3).
This let me to conclude that the various facets to consider for a DVS would
then be along the following:
1) validity of an entity's public key certificate.
2) validity of a certification path.
3) validity of an entity's signature.
The validity may be checked against:
a) a security policy.
b) one or more self-signed certificates.
c) one or more certification paths.
d) one or more trusted points (provided that the path being used is
returned).
The next question is what kind of information should be given to the DVS ?
There is not a single answer to this question, but it would be better to
restrict some of the possibilities when verifications "in the past" occur.
When something is signed, it seems natural that the verifier makes sure
that, at the first time it makes the verification, it gets everything back
that he will need later on to prove that the signature was valid (according
to a non repudiation policy).
If he (or someone else) wants to make the verification later on, it seems
then natural that he provides what he got at that time. This has two
important implications:
1) This means that the DVS does not have to fetch, e.g. back 3 years old
CRLs or ARLs.
2) This also means that the DVS should return all what is needed for later
proof. That stuff may then be used by any DVS to make the verification,
without the need for anyone to trust the first DVS for its good faith. This
would be a nice way to support the IDUP APIs where such a functionality
exists.
CRLS, OCSP responses and ARLs may then be part of the data that is given or
returned to the DVS. Time Stamp tokens may also be part of it.
All the functions listed above can be used in the context where the DVS is a
server trusted only by its requester and not necessarily by all the other
users. This minimizes the problem of a single point of attack as mentioned
by Steve.
> 2) We extend the services offered by a Directory Server to allow the
> retrieval of an entire certificate path is one call. Thus, the end
> system would issue a single LDAP call to the Directory Server (providing
> as inputs, the end entity certificate, trust anchors, etc.) to retrieve
> an entire certificate path. The actual path validation would be done on
> the end system itself. In this case, there is no need to trust the
> Directory since the actual path validation is done locally. The
> Directory Service is extended to support path development - also
> implying an extension to the LDAP interfaces.
>From my previous remarks, this second option would not be workable since we
would need a very intelligent Directory to do so. Anyway a protocol
different from LDAP would be needed and would not provide all the
flexibility that is needed.
> I think it would be beneficial to offer viable alternatives to
> developers of PKI-based systems/products to unburden them from
> complicated path processing functions. I am curious to hear others'
> opinions on these ideas.
Regards,
Denis
> - Sarbari Gupta
> =============================
> Sarbari Gupta
> CygnaCom Solutions
> (703)848-0883 ext 217
> sgupta@cygnacom.com
> =============================
>
> > -----Original Message-----
> > From: Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au]
> > Sent: Wednesday, October 14, 1998 6:06 PM
> > To: 'Sarbari Gupta '
> > Cc: ''David Boyce' '; 'ietf-pkix@imc.org '
> > Subject: RE: NEW Data type for certificate selection ?
> >
> > Yes the problem is a path issue. where CAs may have multiple paths to
> > their roots or other CAs, multiple approaches to revokation, Users
> > have
> > multiple certficates, clients might be root and domain agile, etc.
> >
> > I have views on this which says we should not complicate the
> > certificate
> > any more- so the client gets even more complex and untrusted, we
> > should
> > use some simpler methods of validation with the assistance of the
> > directory service.
> >
> > Phone systems are good - my telephone does not have software in it to
> > prove the telephone company can provide it with its phone number ! :-)
> >
> > see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
> > right direction - but I am biased of course :-)
> > regards alan
> >
> > ----------
> > From: David Boyce
> > To: Sarbari Gupta
> > Cc: 'David Boyce'; ietf-pkix@imc.org
> > Sent: 10/14/98 12:48:24 AM
> > Subject: Re: NEW Data type for certificate selection ?
> >
> > Sarbari Gupta writes (quoting David Boyce):
> > >>(I don't believe specifying 'prefix of Name' is adequate, since it
> > may
> > >>not be acceptable to match an Issuer at some greater depth than
> > >>intended. Both SubtreeSpecification and NameConstraintsSyntax
> > permit
> > >>limits to be placed on the depth of the matching, and also permit
> > the
> > >>explicit exclusion of Names which would otherwise match.)
> > >
> > >In the context of discussing a mechanism for "selecting" end entity
> > >certificates for use, I do not understand why the 'prefix of name'
> > >criterion is inadequate.
> >
> > Let me see if I can clarify what I mean. As I understand it, a
> > matching rule which supported 'prefix of Issuer' (without further
> > qualification) would be adequate for the specific purpose you
> > described ONLY if ANY Issuer whose name contained the prefix specified
> > would satisfy the intended purpose of the selection. I think there
> > might be other scenarios for which this would not be sufficient.
> >
> > For example, consider an environment in which an organization has a
> > mixture of 'high-trust' CAs at one level, subordinate to the
> > organization, and other 'Low-trust' CAs subordinate to them. All
> > these CAs would satisfy a selection criterion of 'prefix of Issuer'
> > with a value corresponding to the organization's name; clearly if the
> > intention was to select only 'high-trust' CAs, "prefix of Issuer" is
> > inadequate; some other discriminator would have to be used,
> > e.g. policyIds.
> >
> > A Certificate Matching rule which used NameConstraintsSyntax against
> > the Issuer name would permit successful discrimination in this case on
> > the basis of Issuer name alone, as specifying a permittedSubtrees.base
> > of the organisation name, with a permittedSubtrees.minimum of 1 and
> > permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
> > considered.
> >
> > In general, once a shortcoming in the present mechanism has been
> > identified, it's worth trying to think about what other constraints a
> > certificate selector might wish to specify with regard to the Issuer
> > name. (Of course, this whole discussion also has application to
> > Subject name and their respective altName extenstions.)
> >
> > You have indicated a need for 'prefix of Issuer'; by suggesting
> > e.g. NameConstraintsSyntax, I'm trying to address that need, and at
> > the same time think about what other aspects of the same problem might
> > need to be addressed. "prefix of Issuer" matching may well be
> > adequate for your own environment; but it may not be for other
> > environments.
> >
> > > On the other hand, if we were discussing
> > >certificate path validation, I would agree with you completely; for
> > CA
> > >certificates in the path to be validated, the NameConstraints
> > extension
> > >with the permitted and excluded subtrees would be absolutely
> > relevant.
> >
> > We're not discussing certificate path validation (although clearly
> > certificate selection has a bearing on subsequent certificate path
> > validation).
> >
> > In the above discussion, I'm suggesting extending/adapting the current
> > NameConstraintsSyntax definition so that it becomes a basis for a
> > matching rule for Issuer name.
> >
> > >Apparently, what is needed to support "selection of a certificate for
> > >use" by secure applications is the ability to draw upon the richness
> > >that is already present in the X.509 v3 certificate syntax.
> >
> > I am beginning to realise there is a more general problem here: how to
> > select a Certificate Path (end user certificate plus zero or more CA
> > certs) which will permit authentication. So far we have just been
> > discussing the selection of an end-user certificate while assuming
> > that the Cert path follows automatically ... it might make sense to
> > use X.509 certificatePairMatch for this.
> >
> > David.
> >
> > --
> > David Boyce
> >
> > Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
> > Email: d.boyce@isode.com Isode's WWW:
> > http://www.isode.com/
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA23344 for ietf-pkix-bks; Thu, 15 Oct 1998 16:37:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA23340 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 16:37:21 -0700 (PDT)
Received: from [128.33.238.34] (TC128.BBN.COM [128.33.238.128]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id TAA25800; Thu, 15 Oct 1998 19:38:10 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v0401170ab24c36bab792@[128.33.238.34]>
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Date: Thu, 15 Oct 1998 19:35:19 -0400
To: Sarbari Gupta <sgupta@cygnacom.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: certificate path services [ was RE: NEW Data type for certificate selection ? ]
Cc: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari,
>There are (at least) two ways to resolve this issue:
>
>1) We introduce the concept of a trusted service, let's call it
>"Certificate Path Validation Service (CPVS)" which could take in
>requests for validation (comprising the end entity certificate and
>possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
>The CPVS could be hosted on a high-end server that caches recent
>requests and has the capability to interface with
>Directories/Repositories over the internet to quickly obtain an answer
>for the subscriber, thus relieving the end entity system from the
>overhead of certificate path processing. The CPVS would also support
>revocation models. The CPVS would be particularly useful in an
>organizational environment, where a single dedicated system runs the
>CPVS for that organization and services path validation requests for
>other users within the organization. To support the notion of a CPVS
>service, a new service interface needs to be defined and standardized.
Well, this certainly makes it clear which single, online system to attack
if one wants to be able to spoof all users in an enterprise environemnt.
>2) We extend the services offered by a Directory Server to allow the
>retrieval of an entire certificate path is one call. Thus, the end
>system would issue a single LDAP call to the Directory Server (providing
>as inputs, the end entity certificate, trust anchors, etc.) to retrieve
>an entire certificate path. The actual path validation would be done on
>the end system itself. In this case, there is no need to trust the
>Directory since the actual path validation is done locally. The
>Directory Service is extended to support path development - also
>implying an extension to the LDAP interfaces.
This is a lot better than option 1, if I have to choose bewteen the two.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19261 for ietf-pkix-bks; Thu, 15 Oct 1998 08:56:44 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA19257 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:56:43 -0700 (PDT)
Received: id LAA24051; Thu, 15 Oct 1998 11:54:16 -0400
Received: by gateway id <4CGY0QJJ>; Thu, 15 Oct 1998 11:51:58 -0400
Message-ID: <D789F71F24B4D111955D00A0C99B4F5001789108@sothmxs01.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'Sarbari Gupta'" <sgupta@cygnacom.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: certificate path services [ was RE: NEW Data type for certifi cate selection ? ]
Date: Thu, 15 Oct 1998 11:50:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Sarbari,
> ----------
> From: Sarbari Gupta[SMTP:sgupta@cygnacom.com]
> Sent: Thursday, October 15, 1998 10:46 AM
> To: 'Alan Lloyd'
> Cc: 'ietf-pkix@imc.org '
> Subject: certificate path services [ was RE: NEW Data type for
> certificate selection ? ]
>
> I seem to agree with Alan that there are certain situations where it
> would be very beneficial to have third-party services available to
> assist with certificate path development and/or validation.
>
> If (and when) large scale PKIs become widely deployed, it could become
> a
> real problem for each end entity to look up and then validate the
> certificate path to its peer's certificate. It requires a large amount
> of processing power as well as complicated path processing software to
> do this task. Additionally, it requires repeated interactions with a
> remote Directory Server to build the certificate path.
>
> There are (at least) two ways to resolve this issue:
>
> 1) We introduce the concept of a trusted service, let's call it
> "Certificate Path Validation Service (CPVS)" which could take in
> requests for validation (comprising the end entity certificate and
> possibly a trusted root, policy IDs, etc.) and return an YES/NO
> answer.
> The CPVS could be hosted on a high-end server that caches recent
> requests and has the capability to interface with
> Directories/Repositories over the internet to quickly obtain an answer
> for the subscriber, thus relieving the end entity system from the
> overhead of certificate path processing. The CPVS would also support
> revocation models. The CPVS would be particularly useful in an
> organizational environment, where a single dedicated system runs the
> CPVS for that organization and services path validation requests for
> other users within the organization. To support the notion of a CPVS
> service, a new service interface needs to be defined and standardized.
>
>
This is precisely one of the services specified in the Data
Certification Server protocol. Please take a look at
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt
(recently re-introduced into the PKIX Working Group) and let me know if
this meets the functionality you had in mind.
--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18927 for ietf-pkix-bks; Thu, 15 Oct 1998 08:05:59 -0700 (PDT)
Received: from procert.cert.dfn.de (kelm@procert.cert.dfn.de [134.100.14.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18923 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:05:55 -0700 (PDT)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id RAA21625 for ietf-pkix@imc.org; Thu, 15 Oct 1998 17:05:04 +0200 (MET DST)
Date: Thu, 15 Oct 1998 17:05:04 +0200 (MET DST)
From: Stefan Kelm <kelm@pca.dfn.de>
Message-Id: <199810151505.RAA21625@procert.cert.dfn.de>
To: ietf-pkix@imc.org
Subject: Typo
Reply-To: ietf-pkix@imc.org
X-Sun-Charset: US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Folks,
I'm getting nitpicky here...
there are three tiny typos in both draft-ietf-pkix-ipki-part1-11.txt
and draft-ietf-pkix-crmf-01.txt where it says "posession" instead of
"possession".
Also, there are still references to ietf-pkix@tandem.com in some of
the PKIX drafts.
Cheers,
Stefan.
______________________________________________________________________________
Stefan Kelm PGP key: "finger kelm@www.cert.dfn.de" or via key server
DFN-CERT, University of Hamburg <kelm@cert.dfn.de>
Vogt-Koelln-Str. 30 http://www.cert.dfn.de/~kelm/
22527 Hamburg (Germany) Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18774 for ietf-pkix-bks; Thu, 15 Oct 1998 07:46:57 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18770 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 07:46:55 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDZCZ>; Thu, 15 Oct 1998 10:46:32 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
From: Sarbari Gupta <sgupta@cygnacom.com>
To: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: certificate path services [ was RE: NEW Data type for certificate selection ? ]
Date: Thu, 15 Oct 1998 10:46:29 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I seem to agree with Alan that there are certain situations where it
would be very beneficial to have third-party services available to
assist with certificate path development and/or validation.
If (and when) large scale PKIs become widely deployed, it could become a
real problem for each end entity to look up and then validate the
certificate path to its peer's certificate. It requires a large amount
of processing power as well as complicated path processing software to
do this task. Additionally, it requires repeated interactions with a
remote Directory Server to build the certificate path.
There are (at least) two ways to resolve this issue:
1) We introduce the concept of a trusted service, let's call it
"Certificate Path Validation Service (CPVS)" which could take in
requests for validation (comprising the end entity certificate and
possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
The CPVS could be hosted on a high-end server that caches recent
requests and has the capability to interface with
Directories/Repositories over the internet to quickly obtain an answer
for the subscriber, thus relieving the end entity system from the
overhead of certificate path processing. The CPVS would also support
revocation models. The CPVS would be particularly useful in an
organizational environment, where a single dedicated system runs the
CPVS for that organization and services path validation requests for
other users within the organization. To support the notion of a CPVS
service, a new service interface needs to be defined and standardized.
2) We extend the services offered by a Directory Server to allow the
retrieval of an entire certificate path is one call. Thus, the end
system would issue a single LDAP call to the Directory Server (providing
as inputs, the end entity certificate, trust anchors, etc.) to retrieve
an entire certificate path. The actual path validation would be done on
the end system itself. In this case, there is no need to trust the
Directory since the actual path validation is done locally. The
Directory Service is extended to support path development - also
implying an extension to the LDAP interfaces.
I think it would be beneficial to offer viable alternatives to
developers of PKI-based systems/products to unburden them from
complicated path processing functions. I am curious to hear others'
opinions on these ideas.
- Sarbari Gupta
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================
> -----Original Message-----
> From: Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au]
> Sent: Wednesday, October 14, 1998 6:06 PM
> To: 'Sarbari Gupta '
> Cc: ''David Boyce' '; 'ietf-pkix@imc.org '
> Subject: RE: NEW Data type for certificate selection ?
>
> Yes the problem is a path issue. where CAs may have multiple paths to
> their roots or other CAs, multiple approaches to revokation, Users
> have
> multiple certficates, clients might be root and domain agile, etc.
>
> I have views on this which says we should not complicate the
> certificate
> any more- so the client gets even more complex and untrusted, we
> should
> use some simpler methods of validation with the assistance of the
> directory service.
>
> Phone systems are good - my telephone does not have software in it to
> prove the telephone company can provide it with its phone number ! :-)
>
> see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
> right direction - but I am biased of course :-)
> regards alan
>
> ----------
> From: David Boyce
> To: Sarbari Gupta
> Cc: 'David Boyce'; ietf-pkix@imc.org
> Sent: 10/14/98 12:48:24 AM
> Subject: Re: NEW Data type for certificate selection ?
>
> Sarbari Gupta writes (quoting David Boyce):
> >>(I don't believe specifying 'prefix of Name' is adequate, since it
> may
> >>not be acceptable to match an Issuer at some greater depth than
> >>intended. Both SubtreeSpecification and NameConstraintsSyntax
> permit
> >>limits to be placed on the depth of the matching, and also permit
> the
> >>explicit exclusion of Names which would otherwise match.)
> >
> >In the context of discussing a mechanism for "selecting" end entity
> >certificates for use, I do not understand why the 'prefix of name'
> >criterion is inadequate.
>
> Let me see if I can clarify what I mean. As I understand it, a
> matching rule which supported 'prefix of Issuer' (without further
> qualification) would be adequate for the specific purpose you
> described ONLY if ANY Issuer whose name contained the prefix specified
> would satisfy the intended purpose of the selection. I think there
> might be other scenarios for which this would not be sufficient.
>
> For example, consider an environment in which an organization has a
> mixture of 'high-trust' CAs at one level, subordinate to the
> organization, and other 'Low-trust' CAs subordinate to them. All
> these CAs would satisfy a selection criterion of 'prefix of Issuer'
> with a value corresponding to the organization's name; clearly if the
> intention was to select only 'high-trust' CAs, "prefix of Issuer" is
> inadequate; some other discriminator would have to be used,
> e.g. policyIds.
>
> A Certificate Matching rule which used NameConstraintsSyntax against
> the Issuer name would permit successful discrimination in this case on
> the basis of Issuer name alone, as specifying a permittedSubtrees.base
> of the organisation name, with a permittedSubtrees.minimum of 1 and
> permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
> considered.
>
> In general, once a shortcoming in the present mechanism has been
> identified, it's worth trying to think about what other constraints a
> certificate selector might wish to specify with regard to the Issuer
> name. (Of course, this whole discussion also has application to
> Subject name and their respective altName extenstions.)
>
> You have indicated a need for 'prefix of Issuer'; by suggesting
> e.g. NameConstraintsSyntax, I'm trying to address that need, and at
> the same time think about what other aspects of the same problem might
> need to be addressed. "prefix of Issuer" matching may well be
> adequate for your own environment; but it may not be for other
> environments.
>
> > On the other hand, if we were discussing
> >certificate path validation, I would agree with you completely; for
> CA
> >certificates in the path to be validated, the NameConstraints
> extension
> >with the permitted and excluded subtrees would be absolutely
> relevant.
>
> We're not discussing certificate path validation (although clearly
> certificate selection has a bearing on subsequent certificate path
> validation).
>
> In the above discussion, I'm suggesting extending/adapting the current
> NameConstraintsSyntax definition so that it becomes a basis for a
> matching rule for Issuer name.
>
> >Apparently, what is needed to support "selection of a certificate for
> >use" by secure applications is the ability to draw upon the richness
> >that is already present in the X.509 v3 certificate syntax.
>
> I am beginning to realise there is a more general problem here: how to
> select a Certificate Path (end user certificate plus zero or more CA
> certs) which will permit authentication. So far we have just been
> discussing the selection of an end-user certificate while assuming
> that the Cert path follows automatically ... it might make sense to
> use X.509 certificatePairMatch for this.
>
> David.
>
> --
> David Boyce
>
> Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
> Email: d.boyce@isode.com Isode's WWW:
> http://www.isode.com/
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18270 for ietf-pkix-bks; Thu, 15 Oct 1998 06:53:38 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA18266 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 06:53:37 -0700 (PDT)
Received: from [128.33.238.148] (TC148.BBN.COM [128.33.238.148]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA22838; Thu, 15 Oct 1998 09:54:27 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011705b24baa7ed026@[128.33.238.141]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC08309A@DSG1>
Date: Thu, 15 Oct 1998 09:40:26 -0400
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '"<ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
>Yes the problem is a path issue. where CAs may have multiple paths to
>their roots or other CAs, multiple approaches to revokation, Users have
>multiple certficates, clients might be root and domain agile, etc.
>
>I have views on this which says we should not complicate the certificate
>any more- so the client gets even more complex and untrusted, we should
>use some simpler methods of validation with the assistance of the
>directory service.
Yes, one can imagine offloading this processing, but a fundamental
assumption underlying certificates is that one does not need to rely on
other parties for such processing and storage. Thus directories are
untrusted repositories, which can do not worse than store bad data. I
would not want to confuse this long term existing model of what a directory
does with the notion you;re suggesting, of a component/system that performs
lots of processing that we currently envision being done by a certificate
consuming system. I'm not saying we ought not consider such alternative
models, but le's not confuse folks by calling them directories, trusted
directories, etc.
>Phone systems are good - my telephone does not have software in it to
>prove the telephone company can provide it with its phone number ! :-)
I don't really see the relevance of this last analogy.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA17822 for ietf-pkix-bks; Thu, 15 Oct 1998 05:40:51 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA17818 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 05:40:49 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA23737 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:41:50 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA23731 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:41:49 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA06468 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:40:57 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000312602@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:36:28 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BDF816.E8B7A3C0@avenger.missi.ncsc.mil>; Thu, 15 Oct 1998 08:36:31 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981015123630Z-15230@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'David Boyce'" <D.Boyce@isode.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Clarification on matching rules
Date: Thu, 15 Oct 1998 08:36:30 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Those of us who were at the ISO meeting back in 1995 are trying to
reconstruct all of the steps that led to the matching rule definitions.
In the interim, I forward this general recollection...
>> >Stefan Santesson writes:
>> >>CertificateAssertion ::= SEQUENCE {
>> > ...
>> >> policy [9] CertPolicySet OPTIONAL,
>> > ...
>> >
>> >>CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId
>> >
>> >Can anyone shed light on why this is called a
>> >CertPolicy*Set* when it's>defined as a SEQUENCE OF ?
>> >
>> >The only thing I can think of is that the nature of the data is 'SET
>> >OF', with the name reflecting that nature, but that 'SEQUENCE OF' has
>> >been used in the definition of the type in order to avoid introducing
>> >DER-encoding hassles.
>
>If memory and gut feelings serve, that is the reason: to avoid
>DER problems with encoding SET OF. Semantically, it is a set;
>pragmatically it is a sequence, to make it work.
>
>> >> j) policy matches if all of the policy elements identified
>> >> in one of the presented values are contained in the set of
>> >> policyElementIds in any of the policyInformation values in
>> >> the certificate policies extension in the stored attribute
>> >> value; there is no match if there is no certificate
>policies
>> >> extension in the stored attribute value;
>> >
>> >Is there mismatch between this description and the defined syntax for
>> >CertPolicySet here? The presence of the phrase 'in one of the
>presented
>> >values' seems to indicate a different syntax to the one defined.
>> >
>> >It looks to me as if the author had in mind a definition of
>> >CertPolicySet along the lines of
>> >
>> > CertPolicySet ::= SET (1..MAX) OF CertPolicyPresentedValues
>> >
>> > CertPolicyPresentedValues ::= SET (1..MAX) OF CertPolicyId
>> >
>> >(SET OF being regarded as equivalent to SEQUENCE OF for the
>> purposes of this discussion).
>> >
>> >If not, then surely CertPolicySet would comprise the entire
>> 'presented value', making the phrase 'identified in one of the
>> presented values' misleading.
>
>Yeah, this seems fuzzy to me, too. Perhaps it (j) should read
>
> j) policy matches if all of the policy elements specified as
> presented values are contained in the set of
> policyElementIds in any of the policyInformation values in
> the certificate policies extension in the stored attribute
> value; there is no match if there is no certificate policies
> extension in the stored attribute value;
>
>In other words:
>
>The assertion contains a single set; the assertion matches
>the certificate if and only if all elements of that set are
>contained in the certificate.
Sandi
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22892 for ietf-pkix-bks; Wed, 14 Oct 1998 15:09:46 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA22888 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 15:09:38 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <4WLS6X8Z>; Thu, 15 Oct 1998 08:06:24 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC08309A@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Sarbari Gupta '" <sgupta@cygnacom.com>
Cc: "''David Boyce' '" <D.Boyce@isode.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 15 Oct 1998 08:06:23 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Yes the problem is a path issue. where CAs may have multiple paths to
their roots or other CAs, multiple approaches to revokation, Users have
multiple certficates, clients might be root and domain agile, etc.
I have views on this which says we should not complicate the certificate
any more- so the client gets even more complex and untrusted, we should
use some simpler methods of validation with the assistance of the
directory service.
Phone systems are good - my telephone does not have software in it to
prove the telephone company can provide it with its phone number ! :-)
see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
right direction - but I am biased of course :-)
regards alan
----------
From: David Boyce
To: Sarbari Gupta
Cc: 'David Boyce'; ietf-pkix@imc.org
Sent: 10/14/98 12:48:24 AM
Subject: Re: NEW Data type for certificate selection ?
Sarbari Gupta writes (quoting David Boyce):
>>(I don't believe specifying 'prefix of Name' is adequate, since it may
>>not be acceptable to match an Issuer at some greater depth than
>>intended. Both SubtreeSpecification and NameConstraintsSyntax permit
>>limits to be placed on the depth of the matching, and also permit the
>>explicit exclusion of Names which would otherwise match.)
>
>In the context of discussing a mechanism for "selecting" end entity
>certificates for use, I do not understand why the 'prefix of name'
>criterion is inadequate.
Let me see if I can clarify what I mean. As I understand it, a
matching rule which supported 'prefix of Issuer' (without further
qualification) would be adequate for the specific purpose you
described ONLY if ANY Issuer whose name contained the prefix specified
would satisfy the intended purpose of the selection. I think there
might be other scenarios for which this would not be sufficient.
For example, consider an environment in which an organization has a
mixture of 'high-trust' CAs at one level, subordinate to the
organization, and other 'Low-trust' CAs subordinate to them. All
these CAs would satisfy a selection criterion of 'prefix of Issuer'
with a value corresponding to the organization's name; clearly if the
intention was to select only 'high-trust' CAs, "prefix of Issuer" is
inadequate; some other discriminator would have to be used,
e.g. policyIds.
A Certificate Matching rule which used NameConstraintsSyntax against
the Issuer name would permit successful discrimination in this case on
the basis of Issuer name alone, as specifying a permittedSubtrees.base
of the organisation name, with a permittedSubtrees.minimum of 1 and
permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
considered.
In general, once a shortcoming in the present mechanism has been
identified, it's worth trying to think about what other constraints a
certificate selector might wish to specify with regard to the Issuer
name. (Of course, this whole discussion also has application to
Subject name and their respective altName extenstions.)
You have indicated a need for 'prefix of Issuer'; by suggesting
e.g. NameConstraintsSyntax, I'm trying to address that need, and at
the same time think about what other aspects of the same problem might
need to be addressed. "prefix of Issuer" matching may well be
adequate for your own environment; but it may not be for other
environments.
> On the other hand, if we were discussing
>certificate path validation, I would agree with you completely; for CA
>certificates in the path to be validated, the NameConstraints extension
>with the permitted and excluded subtrees would be absolutely relevant.
We're not discussing certificate path validation (although clearly
certificate selection has a bearing on subsequent certificate path
validation).
In the above discussion, I'm suggesting extending/adapting the current
NameConstraintsSyntax definition so that it becomes a basis for a
matching rule for Issuer name.
>Apparently, what is needed to support "selection of a certificate for
>use" by secure applications is the ability to draw upon the richness
>that is already present in the X.509 v3 certificate syntax.
I am beginning to realise there is a more general problem here: how to
select a Certificate Path (end user certificate plus zero or more CA
certs) which will permit authentication. So far we have just been
discussing the selection of an end-user certificate while assuming
that the Cert path follows automatically ... it might make sense to
use X.509 certificatePairMatch for this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22676 for ietf-pkix-bks; Wed, 14 Oct 1998 14:43:47 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA22672 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 14:43:45 -0700 (PDT)
Received: id RAA21675; Wed, 14 Oct 1998 17:42:39 -0400
Received: by gateway id <4CGY0N97>; Wed, 14 Oct 1998 17:40:25 -0400
Message-ID: <D789F71F24B4D111955D00A0C99B4F5001789100@sothmxs01.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: ietf-pkix@imc.org, "'Stefan_Salzmann/HAM/Lotus@lotus.com'" <Stefan_Salzmann/HAM/Lotus@lotus.com>
Subject: RE: Centralized Scheme versus Basic Authentication Scheme
Date: Wed, 14 Oct 1998 17:38:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA22673
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Stefan,
> ----------
> From:
> Stefan_Salzmann/HAM/Lotus@lotus.com[SMTP:Stefan_Salzmann/HAM/Lotus@lot
> us.com]
> Sent: Tuesday, October 13, 1998 9:39 AM
> To: ietf-pkix@imc.org
> Subject: Centralized Scheme versus Basic Authentication Scheme
>
> Hello once again,
>
> wouldn´t it be better as well as easier to use the centralized scheme
> instead
> using the basic authentication scheme:
>
It may well be easier, but "better" depends upon your environment...
> In Draft draft-ietf-pkix-ipki3cmp-08.txt Certificate Management
> Protocols the
> basic authentication scheme MUST be used. So why not using the easier
> centralized scheme.
>
> Thanks for answering,
> Stefan
>
Many people object to the idea that the CA generates all key pairs (for
a variety of reasons, including the absence of strong non-repudiation
arguments). Therefore, making the centralized scheme the mandatory
scheme was totally unacceptable to a large number of interested parties.
--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA10539 for ietf-pkix-bks; Wed, 14 Oct 1998 00:19:10 -0700 (PDT)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA10533 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 00:19:08 -0700 (PDT)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH18/LBNLMWH11/ESOCF2) with ESMTP id AAA21775 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 00:20:05 -0700 (PDT)
Message-Id: <199810140720.AAA21775@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: We Buy Anything!
In-reply-to: Your message of "Wed, 14 Oct 1998 00:45:52 CDT." <199810140545.AAA24289@mail.hic.net>
Date: Wed, 14 Oct 1998 00:20:05 -0700
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
liquid_32@hotmail.com writes:
>
> We buy anything!!!!!
>
>
> DISTRESSED MERCHANDISE----CLOSE-OUTS------FACTORY RETURNS
Clipper chips?
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA29314 for ietf-pkix-bks; Tue, 13 Oct 1998 21:28:09 -0700 (PDT)
Received: from mail.hic.net (root@mail.hic.net [209.144.4.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA29310; Tue, 13 Oct 1998 21:28:07 -0700 (PDT)
From: liquid_32@hotmail.com
Received: from default (ip121.hamilton2.dialup.canada.psi.net [154.11.101.121]) by mail.hic.net (8.8.5/8.8.5) with SMTP id AAA24289; Wed, 14 Oct 1998 00:45:52 -0500 (CDT)
Date: Wed, 14 Oct 1998 00:45:52 -0500 (CDT)
Message-Id: <199810140545.AAA24289@mail.hic.net>
To: liquid_32@hotmail.com
Subject: We Buy Anything!
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
We buy anything!!!!!
DISTRESSED MERCHANDISE----CLOSE-OUTS------FACTORY RETURNS
We pay top dollar for your merchandise!! GUARANTEED!
Representatives Nationwide ready to pay immediate cash!
PHONE: 818-506-7885
FAX: 818-980-8033
E-MAIL: liquidator@hotmail.com
http://www.ieleads.com/liquidator
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA25613 for ietf-pkix-bks; Tue, 13 Oct 1998 20:46:58 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA25605 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 20:46:57 -0700 (PDT)
Received: from chromatix.com (cc1020663-a.hwrd1.md.home.com [24.3.62.220]) by chromatix.com (8.8.8/8.8.8) with ESMTP id XAA21409; Tue, 13 Oct 1998 23:47:29 -0400 (EDT) (envelope-from dave@chromatix.com)
Message-ID: <3624C9B0.C90F3E09@chromatix.com>
Date: Wed, 14 Oct 1998 11:56:32 -0400
From: David Horvath <dave@chromatix.com>
Organization: @Home Network
X-Mailer: Mozilla 4.05 [en]C-AtHome0404 (Win95; U)
MIME-Version: 1.0
To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
CC: "'Sean Turner'" <turners@ieca.com>, "'PKIX'" <ietf-pkix@imc.org>, "'Ldapext'" <ietf-ldapext@netscape.com>, "'Dave Horvath'" <David.Horvath@chromatix.com>
Subject: Re: CA strong binds
References: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981013192151Z-14363@avenger.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sandi,
I don't believe the OID of the attribute (indicating where the
certificate came from) is included in the certification path as defined
in X.509.
Dave H
Miklos, Sue A. wrote:
>
> Dave,
>
> I believe the discussion may have been related to "which data blob" goes
> into the protocol exchange when performing an operation that calls out
> "userCertificate", if the user is a CA. Does the CA certificate (with a
> different oid) get inserted into the exchange or does this require that
> the CA also maintain a certificate (identical information?) with the oid
> of a userCertificate.
>
> I realize this should be transparent, but wonder if others have
> experiences with this.
>
> Sandi
>
> >----------
> >From: Dave Horvath[SMTP:David.Horvath@chromatix.com]
> >Sent: Tuesday, October 13, 1998 2:44 PM
> >To: Sean Turner; PKIX; Ldapext
> >Subject: Re: CA strong binds
> >
> >
> >Sean,
> >
> > The only requirement that we have for the SafePages LDAP/X.500 products
> >is that the certificate must have the digitalSignature bit asserted in the
> >keyUsage field if it is a Version 3 certificate with the keyUsage extension
> >present. The other bits and the cA flag in the basicConstraints
> >extensions are not consulted.
> >
> > The existence or the location of the certificate in the repository does
> >not play a role for authentication.
> >
> >Dave Horvath
> >
> >-----Original Message-----
> >From: Sean Turner <turners@ieca.com>
> >To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
> >Date: Tuesday, October 13, 1998 1:41 PM
> >Subject: CA strong binds
> >
> >
> >>All,
> >>
> >>Appologies in advance if you get two of this message but I wasn't sure
> >>which list to send the message to.
> >>
> >>Recently some colleagues and I have been arguing whether applications
> >>will choke when looking for CA certificates in
> >>CertificationPath.userCertificate. For example, when a CA binds to an
> >>LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
> >>the CA's certificate will be passed in
> >>certification-path.userCertificate and the CA's superiors certificates
> >>are passed in certication-path.theCACertificates. Will applications
> >>choke when trying to process the CA certificate from a field called
> >>userCertificate or when trying to look for a "user's certificate"
> >>which is in a CA's directory entry?
> >>
> >>I know the name of the field shouldn't be confused with the value that
> >>goes into it, but we were concerned that many of the specifications
> >>were clear on where CA certificates should be put when attempting to
> >>perform strong binds to the directory.
> >>
> >>Any thoughts - implementation experience?
> >>
> >>Thanks,
> >>
> >>spt
> >>
> >>
> >
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA25430 for ietf-pkix-bks; Tue, 13 Oct 1998 20:34:15 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA25426 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 20:34:13 -0700 (PDT)
Received: from chromatix.com (cc1020663-a.hwrd1.md.home.com [24.3.62.220]) by chromatix.com (8.8.8/8.8.8) with ESMTP id XAA21389; Tue, 13 Oct 1998 23:34:44 -0400 (EDT) (envelope-from dave@chromatix.com)
Message-ID: <3624C6B8.A1EC044A@chromatix.com>
Date: Wed, 14 Oct 1998 11:43:52 -0400
From: David Horvath <dave@chromatix.com>
Organization: @Home Network
X-Mailer: Mozilla 4.05 [en]C-AtHome0404 (Win95; U)
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@cygnacom.com>
CC: "'Dave Horvath'" <David.Horvath@chromatix.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, Ldapext <ietf-ldapext@netscape.com>
Subject: Re: CA strong binds
References: <51BF55C30B4FD1118B4900207812701E20B0CD@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Santosh,
Good question. I believe we will reject the signature verification
even if the extension is not marked critical, as long as the ASN.1 is
decoded properly, but I will have to verify.
Dave Horvath
Santosh Chokhani wrote:
>
> Dave:
>
> I assume the digital signature bit is required to be turned only if the
> key usage extension is marked critical.
>
> > -----Original Message-----
> > From: Dave Horvath [SMTP:David.Horvath@chromatix.com]
> > Sent: Tuesday, October 13, 1998 2:44 PM
> > To: Sean Turner; PKIX; Ldapext
> > Subject: Re: CA strong binds
> >
> >
> > Sean,
> >
> > The only requirement that we have for the SafePages LDAP/X.500
> > products
> > is that the certificate must have the digitalSignature bit asserted in
> > the
> > keyUsage field if it is a Version 3 certificate with the keyUsage
> > extension
> > present. The other bits and the cA flag in the basicConstraints
> > extensions are not consulted.
> >
> > The existence or the location of the certificate in the repository
> > does
> > not play a role for authentication.
> >
> > Dave Horvath
> >
> > -----Original Message-----
> > From: Sean Turner <turners@ieca.com>
> > To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
> > Date: Tuesday, October 13, 1998 1:41 PM
> > Subject: CA strong binds
> >
> >
> > >All,
> > >
> > >Appologies in advance if you get two of this message but I wasn't
> > sure
> > >which list to send the message to.
> > >
> > >Recently some colleagues and I have been arguing whether applications
> > >will choke when looking for CA certificates in
> > >CertificationPath.userCertificate. For example, when a CA binds to
> > an
> > >LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
> > >the CA's certificate will be passed in
> > >certification-path.userCertificate and the CA's superiors
> > certificates
> > >are passed in certication-path.theCACertificates. Will applications
> > >choke when trying to process the CA certificate from a field called
> > >userCertificate or when trying to look for a "user's certificate"
> > >which is in a CA's directory entry?
> > >
> > >I know the name of the field shouldn't be confused with the value
> > that
> > >goes into it, but we were concerned that many of the specifications
> > >were clear on where CA certificates should be put when attempting to
> > >perform strong binds to the directory.
> > >
> > >Any thoughts - implementation experience?
> > >
> > >Thanks,
> > >
> > >spt
> > >
> > >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20580 for ietf-pkix-bks; Tue, 13 Oct 1998 12:21:01 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20576 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 12:20:59 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA11735 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:57 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA11720 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:55 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA14095 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:06 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000309932@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:52 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BDF6BD.34766C70@avenger.missi.ncsc.mil>; Tue, 13 Oct 1998 15:21:52 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981013192151Z-14363@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'Sean Turner'" <turners@ieca.com>, "'PKIX'" <ietf-pkix@imc.org>, "'Ldapext'" <ietf-ldapext@netscape.com>, "'Dave Horvath'" <David.Horvath@chromatix.com>
Subject: RE: CA strong binds
Date: Tue, 13 Oct 1998 15:21:51 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dave,
I believe the discussion may have been related to "which data blob" goes
into the protocol exchange when performing an operation that calls out
"userCertificate", if the user is a CA. Does the CA certificate (with a
different oid) get inserted into the exchange or does this require that
the CA also maintain a certificate (identical information?) with the oid
of a userCertificate.
I realize this should be transparent, but wonder if others have
experiences with this.
Sandi
>----------
>From: Dave Horvath[SMTP:David.Horvath@chromatix.com]
>Sent: Tuesday, October 13, 1998 2:44 PM
>To: Sean Turner; PKIX; Ldapext
>Subject: Re: CA strong binds
>
>
>Sean,
>
> The only requirement that we have for the SafePages LDAP/X.500 products
>is that the certificate must have the digitalSignature bit asserted in the
>keyUsage field if it is a Version 3 certificate with the keyUsage extension
>present. The other bits and the cA flag in the basicConstraints
>extensions are not consulted.
>
> The existence or the location of the certificate in the repository does
>not play a role for authentication.
>
>Dave Horvath
>
>-----Original Message-----
>From: Sean Turner <turners@ieca.com>
>To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
>Date: Tuesday, October 13, 1998 1:41 PM
>Subject: CA strong binds
>
>
>>All,
>>
>>Appologies in advance if you get two of this message but I wasn't sure
>>which list to send the message to.
>>
>>Recently some colleagues and I have been arguing whether applications
>>will choke when looking for CA certificates in
>>CertificationPath.userCertificate. For example, when a CA binds to an
>>LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
>>the CA's certificate will be passed in
>>certification-path.userCertificate and the CA's superiors certificates
>>are passed in certication-path.theCACertificates. Will applications
>>choke when trying to process the CA certificate from a field called
>>userCertificate or when trying to look for a "user's certificate"
>>which is in a CA's directory entry?
>>
>>I know the name of the field shouldn't be confused with the value that
>>goes into it, but we were concerned that many of the specifications
>>were clear on where CA certificates should be put when attempting to
>>perform strong binds to the directory.
>>
>>Any thoughts - implementation experience?
>>
>>Thanks,
>>
>>spt
>>
>>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20470 for ietf-pkix-bks; Tue, 13 Oct 1998 12:07:22 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20466 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 12:07:21 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDYMJ>; Tue, 13 Oct 1998 15:06:58 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E20B0CD@WUHER>
From: Santosh Chokhani <chokhani@cygnacom.com>
To: "'Dave Horvath'" <David.Horvath@chromatix.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, Ldapext <ietf-ldapext@netscape.com>
Subject: RE: CA strong binds
Date: Tue, 13 Oct 1998 15:06:56 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dave:
I assume the digital signature bit is required to be turned only if the
key usage extension is marked critical.
> -----Original Message-----
> From: Dave Horvath [SMTP:David.Horvath@chromatix.com]
> Sent: Tuesday, October 13, 1998 2:44 PM
> To: Sean Turner; PKIX; Ldapext
> Subject: Re: CA strong binds
>
>
> Sean,
>
> The only requirement that we have for the SafePages LDAP/X.500
> products
> is that the certificate must have the digitalSignature bit asserted in
> the
> keyUsage field if it is a Version 3 certificate with the keyUsage
> extension
> present. The other bits and the cA flag in the basicConstraints
> extensions are not consulted.
>
> The existence or the location of the certificate in the repository
> does
> not play a role for authentication.
>
> Dave Horvath
>
> -----Original Message-----
> From: Sean Turner <turners@ieca.com>
> To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
> Date: Tuesday, October 13, 1998 1:41 PM
> Subject: CA strong binds
>
>
> >All,
> >
> >Appologies in advance if you get two of this message but I wasn't
> sure
> >which list to send the message to.
> >
> >Recently some colleagues and I have been arguing whether applications
> >will choke when looking for CA certificates in
> >CertificationPath.userCertificate. For example, when a CA binds to
> an
> >LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
> >the CA's certificate will be passed in
> >certification-path.userCertificate and the CA's superiors
> certificates
> >are passed in certication-path.theCACertificates. Will applications
> >choke when trying to process the CA certificate from a field called
> >userCertificate or when trying to look for a "user's certificate"
> >which is in a CA's directory entry?
> >
> >I know the name of the field shouldn't be confused with the value
> that
> >goes into it, but we were concerned that many of the specifications
> >were clear on where CA certificates should be put when attempting to
> >perform strong binds to the directory.
> >
> >Any thoughts - implementation experience?
> >
> >Thanks,
> >
> >spt
> >
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20288 for ietf-pkix-bks; Tue, 13 Oct 1998 11:54:37 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20284 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 11:54:36 -0700 (PDT)
Received: from ash (ash.chromatix.com [207.97.115.9]) by chromatix.com (8.8.8/8.8.8) with SMTP id OAA19857; Tue, 13 Oct 1998 14:55:02 -0400 (EDT) (envelope-from David.Horvath@chromatix.com)
Message-ID: <002001bdf6d9$742a3060$097361cf@ash.chromatix.com>
From: "Dave Horvath" <David.Horvath@chromatix.com>
To: "Sean Turner" <turners@ieca.com>, "PKIX" <ietf-pkix@imc.org>, "Ldapext" <ietf-ldapext@netscape.com>
Subject: Re: CA strong binds
Date: Tue, 13 Oct 1998 14:44:04 -0400
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 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sean,
The only requirement that we have for the SafePages LDAP/X.500 products
is that the certificate must have the digitalSignature bit asserted in the
keyUsage field if it is a Version 3 certificate with the keyUsage extension
present. The other bits and the cA flag in the basicConstraints
extensions are not consulted.
The existence or the location of the certificate in the repository does
not play a role for authentication.
Dave Horvath
-----Original Message-----
From: Sean Turner <turners@ieca.com>
To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
Date: Tuesday, October 13, 1998 1:41 PM
Subject: CA strong binds
>All,
>
>Appologies in advance if you get two of this message but I wasn't sure
>which list to send the message to.
>
>Recently some colleagues and I have been arguing whether applications
>will choke when looking for CA certificates in
>CertificationPath.userCertificate. For example, when a CA binds to an
>LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
>the CA's certificate will be passed in
>certification-path.userCertificate and the CA's superiors certificates
>are passed in certication-path.theCACertificates. Will applications
>choke when trying to process the CA certificate from a field called
>userCertificate or when trying to look for a "user's certificate"
>which is in a CA's directory entry?
>
>I know the name of the field shouldn't be confused with the value that
>goes into it, but we were concerned that many of the specifications
>were clear on where CA certificates should be put when attempting to
>perform strong binds to the directory.
>
>Any thoughts - implementation experience?
>
>Thanks,
>
>spt
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19934 for ietf-pkix-bks; Tue, 13 Oct 1998 11:16:51 -0700 (PDT)
Received: from dimoni.upc.es (dimoni.upc.es [147.83.2.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19930 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 11:16:44 -0700 (PDT)
Received: from sert.ac.upc.es (sert.ac.upc.es [147.83.33.7]) by dimoni.upc.es (8.8.6/8.8.6) with ESMTP id UAA20931; Tue, 13 Oct 1998 20:15:42 +0200 (MET DST)
Received: (from smap@localhost) by sert.ac.upc.es (8.9.1/8.9.1) id UAA11603; Tue, 13 Oct 1998 20:20:37 +0200 (MET DST)
Received: from mila10.ac.upc.es(147.83.34.83) by sert.ac.upc.es via smap (V2.0) id xma011599; Tue, 13 Oct 98 20:20:34 +0200
Message-Id: <3.0.1.32.19981013202002.006a042c@popserver.ac.upc.es>
X-Sender: isn99@popserver.ac.upc.es
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 13 Oct 1998 20:20:02 +0200
To: isn99@ac.upc.es
From: "IS&N'99 Conference" <isn99@ac.upc.es>
Subject: IS&N'99 in Barcelona - Second Call for Contributions
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id LAA19931
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dear Sir/Madam,
Please find enclosed the IS&N'99 Second Call for Contributions.
Please apologize any possible duplication!
================================
<<<<< Paving the Way for an Open Service Market >>>>>
IS&N'99
Sixth International Conference on Intelligence in Services and Networks
***********************
27th - 29th April 1999
Barcelona, Spain
***********************
Second call for contributions
http://www.ac.upc.es/isn99/
********************************************
The Conference is jointly sponsored by
the European Commission,
the Universitat Politècnica de Catalunya (UPC)
and Telefónica.
The Conference is currently supported by
the ACTS projects in the IS&N Domain,
EURESCOM,
NMF,
OMG, and
TINA-C.
<<< IEEE Communications Society is technical co-sponsor of the Conference >>>
We live in an age when powerful communications technology is becoming
universally available. Each home has the power to send and receive not
just analogue voice, but also growing volumes of digital information and
even intelligence in the form of agents. Users are becoming increasingly
mobile and are expecting the same level of connectivity in the home, in the
office and on the road.
The progress in computing and communications technologies has created a
need for advanced software and services, to control the complexity of the
technology and place it at the service of the end-user. The challenge for
service engineers is to develop the tools and techniques that will
ultimately bring the full power of communications and information to
everyone, in a way that everyone can easily use.
At the same time, the regulatory and commercial context in which these
technologies are used is changing. The telecommunications market is more
and more open to full competition. The Internet is erasing the borders
between information technology and telecommunications. And the way we do
business is ever more dominated by electronic exchanges of information. Is
our technology ready for the open market of services and networks?
The Sixth International Conference on Intelligence in Services and Networks
(ISN'99) addresses the question of paving the way to the open services
market. The main theme of the conference is the advance in technologies
that will contribute to managing the complexity of an open service market
and delivering services to the people.
Contributions are also invited on market and regulatory issues and
standards. Reports on industrial experience and trials from across the
world are especially welcomed.
<<<<**** Topics ****>>>>
Contributions are invited on (but not limited to) topics such as:
Agent Technology
· use of intelligent and mobile agents
Applications & Security
· electronic commerce
· safety, security and integrity of services and systems
· human machine interfaces
Service engineering & Communications management
· open architectures and interfaces
· interoperability
· communications management
· managing quality of service
· middleware for communications services
· software engineering techniques for the creation of new services
· deployment, provisioning and brokerage of services
· managing wanted and unwanted interactions between services and networks
· evolution of existing technologies such as IN, TMN, Internet
· new trends in multi-media services
· mobile services
· performance issues
<<<<**** Technical papers ****>>>>
Authors are invited to submit a full paper of up to 10 pages including
figures, tables, references and annexes. Papers will be selected for
publication and presentation by the Technical Programme Committee. The
conference proceedings will be published in book form.
All correspondence will take place electronically. Further details on
submission can be found on the IS&N'99 web page:
http://www.ac.upc.es/isn99/
E-mail address for submission:
isn99@ac.upc.es
<<<<**** Project and Industrial showcase ****>>>>
Projects from around the world working on one of the topics above are
invited to demonstrate their results at the conference. Industrial and
product exhibitions are also expected.
If you are interested in a demonstration, please send an e-mail to:
isn99@ac.upc.es
<<<<******* IMPORTANT DATES *******>>>>
Full paper submissions due: 30 November 1998
Notification of acceptance: 15 January 1999
Final papers due: 27 February 1999
<<<<**** IS&N Organisation ****>>>>
Steering committee
Alvin Mullery, ICEurope, France
Chairman
Mario Campolargo, European Commission, Belgium
Jaime Delgado, Universitat Politècnica de Catalunya, Spain
Han Zuidweg, Alcatel, Belgium
Technical programme committee
Han Zuidweg, Alcatel, Belgium
Chairman
Ordinary members
Stefano Antoniazzi, Italtel
E. Athanassiou, DeTeBerkom
Rob Brennan, Teltec
Stefan Covaci, GMD Fokus
Jaime Delgado, UPC
Sofoklis Efremidis, Intracom
Nigel Jefferies, Vodafone
Jens Kristensen, EC
Thomas Magedanz, GMD Fokus
Ahmed Patel, University College Dublin
Raymond Posch, University Graz
Martin Potts, ASPA
Rick Reed, TSE
Pierre Rodier, ICEurope
Simone Sedillot, INRIA
Keith Start, Orca Research
Alan Steventon, BT
Fabrizio Zizza, Italtel
Corresponding members
Alessandro Barbagli, EC
Stephane Beauvais, Softwire
Hendrik Berndt, TINA-C
Vincent Bic, SUN
Wiet Bouma, KPN Research
Brian Byrnes, Object Design
Mikael Ek, Telelogic
Takeyuki Endo, Hitachi
Dieter Gantenbein, IBM
Alex Galis, UCL
Takeo Hamada, Fujitsu
Per Fly Hansen, TeleDanmark
Duncan James-Bell, Lucent
Kristofer Kimbler, Lund University
Patricia Lago, Politecnico Torino
Dirk Lecluse, WTCM/CRIF Belgium
Juha Lipiainen, Nokia
Julio López, Ericsson
Claudio Maristany, Telecom Argentina
Sean Martin, Cambridge Consultants
Kathleen Milsted, France Telecom
David Muldowney, Broadcom
Declan O'Sullivan, Iona Technologies
George Pavlou, Univ. Surrey
Kimmo Raatikainen, Univ. Helsinki
Munir Tag, Sema Group
Sebastiano Trigila, FUB
Anh Hoang Van, CNET
Hans Vanderstraeten, Alcatel
Dong Sik Yun, Korea Telecom
Organising committee
Jaime Delgado, Universitat Politècnica de Catalunya, Spain
Chairman
Germán Santos, Telefónica, Spain
Isabel Gallego, Universitat Politècnica de Catalunya, Spain
====================
More information on:
http://www.ac.upc.es/isn99/
isn99@ac.upc.es
Tel: +34 93 401 68 14 / 6792 / 5947
Fax: +34 93 401 70 55
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18684 for ietf-pkix-bks; Tue, 13 Oct 1998 09:15:56 -0700 (PDT)
Received: from hq.vni.net (hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA18680 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 09:15:53 -0700 (PDT)
Received: from ieca.com (nova-aaa-047.vni.net [205.177.115.47]) by hq.vni.net (8.8.8/8.8.5) with ESMTP id MAA29050; Tue, 13 Oct 1998 12:16:44 -0400 (EDT)
Message-ID: <36237BEE.2645691B@ieca.com>
Date: Tue, 13 Oct 1998 12:12:30 -0500
From: Sean Turner <turners@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.06 [en] (Win98; U)
MIME-Version: 1.0
To: PKIX <ietf-pkix@imc.org>, Ldapext <ietf-ldapext@netscape.com>
Subject: CA strong binds
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
Appologies in advance if you get two of this message but I wasn't sure
which list to send the message to.
Recently some colleagues and I have been arguing whether applications
will choke when looking for CA certificates in
CertificationPath.userCertificate. For example, when a CA binds to an
LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
the CA's certificate will be passed in
certification-path.userCertificate and the CA's superiors certificates
are passed in certication-path.theCACertificates. Will applications
choke when trying to process the CA certificate from a field called
userCertificate or when trying to look for a "user's certificate"
which is in a CA's directory entry?
I know the name of the field shouldn't be confused with the value that
goes into it, but we were concerned that many of the specifications
were clear on where CA certificates should be put when attempting to
perform strong binds to the directory.
Any thoughts - implementation experience?
Thanks,
spt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18166 for ietf-pkix-bks; Tue, 13 Oct 1998 07:48:07 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18162 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 07:48:05 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 13 Oct 1998 15:48:25 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: Sarbari Gupta <sgupta@cygnacom.com>
cc: "'David Boyce'" <D.Boyce@isode.com>, ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
In-reply-to: Your message of "Tue, 13 Oct 1998 09:06:58 EDT." <51BF55C30B4FD1118B4900207812701E1F9046@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 13 Oct 1998 15:48:24 +0100
Message-ID: <21792.908290104@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari Gupta writes (quoting David Boyce):
>>(I don't believe specifying 'prefix of Name' is adequate, since it may
>>not be acceptable to match an Issuer at some greater depth than
>>intended. Both SubtreeSpecification and NameConstraintsSyntax permit
>>limits to be placed on the depth of the matching, and also permit the
>>explicit exclusion of Names which would otherwise match.)
>
>In the context of discussing a mechanism for "selecting" end entity
>certificates for use, I do not understand why the 'prefix of name'
>criterion is inadequate.
Let me see if I can clarify what I mean. As I understand it, a
matching rule which supported 'prefix of Issuer' (without further
qualification) would be adequate for the specific purpose you
described ONLY if ANY Issuer whose name contained the prefix specified
would satisfy the intended purpose of the selection. I think there
might be other scenarios for which this would not be sufficient.
For example, consider an environment in which an organization has a
mixture of 'high-trust' CAs at one level, subordinate to the
organization, and other 'Low-trust' CAs subordinate to them. All
these CAs would satisfy a selection criterion of 'prefix of Issuer'
with a value corresponding to the organization's name; clearly if the
intention was to select only 'high-trust' CAs, "prefix of Issuer" is
inadequate; some other discriminator would have to be used,
e.g. policyIds.
A Certificate Matching rule which used NameConstraintsSyntax against
the Issuer name would permit successful discrimination in this case on
the basis of Issuer name alone, as specifying a permittedSubtrees.base
of the organisation name, with a permittedSubtrees.minimum of 1 and
permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
considered.
In general, once a shortcoming in the present mechanism has been
identified, it's worth trying to think about what other constraints a
certificate selector might wish to specify with regard to the Issuer
name. (Of course, this whole discussion also has application to
Subject name and their respective altName extenstions.)
You have indicated a need for 'prefix of Issuer'; by suggesting
e.g. NameConstraintsSyntax, I'm trying to address that need, and at
the same time think about what other aspects of the same problem might
need to be addressed. "prefix of Issuer" matching may well be
adequate for your own environment; but it may not be for other
environments.
> On the other hand, if we were discussing
>certificate path validation, I would agree with you completely; for CA
>certificates in the path to be validated, the NameConstraints extension
>with the permitted and excluded subtrees would be absolutely relevant.
We're not discussing certificate path validation (although clearly
certificate selection has a bearing on subsequent certificate path
validation).
In the above discussion, I'm suggesting extending/adapting the current
NameConstraintsSyntax definition so that it becomes a basis for a
matching rule for Issuer name.
>Apparently, what is needed to support "selection of a certificate for
>use" by secure applications is the ability to draw upon the richness
>that is already present in the X.509 v3 certificate syntax.
I am beginning to realise there is a more general problem here: how to
select a Certificate Path (end user certificate plus zero or more CA
certs) which will permit authentication. So far we have just been
discussing the selection of an end-user certificate while assuming
that the Cert path follows automatically ... it might make sense to
use X.509 certificatePairMatch for this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18001 for ietf-pkix-bks; Tue, 13 Oct 1998 07:27:18 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17997 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 07:27:17 -0700 (PDT)
From: Stefan_Salzmann/HAM/Lotus@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id KAA03949 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:32:44 -0400 (EDT)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id KAA25024 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:26:33 -0400 (EDT)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3 (723.2 9-26-1998)) id 8525669C.004FEE8F ; Tue, 13 Oct 1998 10:33:04 -0400
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: ietf-pkix@imc.org
Message-ID: <8525669C.004BC008.00@mta2.lotus.com>
Date: Tue, 13 Oct 1998 15:39:19 +0200
Subject: Centralized Scheme versus Basic Authentication Scheme
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA17998
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello once again,
wouldn´t it be better as well as easier to use the centralized scheme instead
using the basic authentication scheme:
In Draft draft-ietf-pkix-ipki3cmp-08.txt Certificate Management Protocols the
basic authentication scheme MUST be used. So why not using the easier
centralized scheme.
Thanks for answering,
Stefan
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17888 for ietf-pkix-bks; Tue, 13 Oct 1998 07:10:54 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17883 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 07:10:52 -0700 (PDT)
From: Stefan_Salzmann/HAM/Lotus@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id KAA01730 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:16:17 -0400 (EDT)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id KAA22966 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:10:04 -0400 (EDT)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3 (723.2 9-26-1998)) id 8525669C.004E6BB4 ; Tue, 13 Oct 1998 10:16:33 -0400
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: ietf-pkix@imc.org
Message-ID: <8525669C.004BA8A9.00@mta2.lotus.com>
Date: Tue, 13 Oct 1998 15:32:51 +0200
Subject: Question about Basic Authentication Scheme
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA17884
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello,
In draft-ietf-pkix-ipki3cmp-08.txt Certification Management Protocol the basic
authentication scheme is described as:
End entity RA/CA
========== =============
out-of-band distribution of Initial Authentication
Key (IAK) and reference value (RA/CA -> EE)
Key generation
Creation of certification request
Protect request with IAK
-->>--certification request-->>--
verify request
process request
create response
--<<--certification response--<<--
handle response
create confirmation
-->>--confirmation message-->>--
verify confirmation
The Initial Authentication Key (IAK) distributed by the CA/RA is not used in
PKCS#10 described in RFC 2314. In that RFC the process of designing a
certification request will be carried out without the IAK. So why use it?? Isn´t
it better to use the private key for encrypting the certificate request message
rather than using the IAK?
Thanks for answering,
Stefan
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA17353 for ietf-pkix-bks; Tue, 13 Oct 1998 06:07:27 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA17349 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 06:07:25 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDYF1>; Tue, 13 Oct 1998 09:07:00 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9046@WUHER>
From: Sarbari Gupta <sgupta@cygnacom.com>
To: "'David Boyce'" <D.Boyce@isode.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 13 Oct 1998 09:06:58 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
David,
>>Sarbari also asked about matching against the prefix of the
Issuer name.
>> The short answer appears to be that that is not possible
using the
>>current definition of certificateMatch Matching Rule, since it
always
>>uses an equality match of the Issuer name. A new Matching
Rule (or the
>>present one modified) would have to be defined to support
matching a
>>prefix.
I got the same impression (that an equality match is implied) when I
looked at the X.500 matching rules.
>>(I don't believe specifying 'prefix of Name' is adequate,
since it may
>>not be acceptable to match an Issuer at some greater depth
than
>>intended. Both SubtreeSpecification and NameConstraintsSyntax
permit
>>limits to be placed on the depth of the matching, and also
permit the
>>explicit exclusion of Names which would otherwise match.)
In the context of discussing a mechanism for "selecting" end entity
certificates for use, I do not understand why the 'prefix of name'
criterion is inadequate. On the other hand, if we were discussing
certificate path validation, I would agree with you completely; for CA
certificates in the path to be validated, the NameConstraints extension
with the permitted and excluded subtrees would be absolutely relevant.
Apparently, what is needed to support "selection of a certificate for
use" by secure applications is the ability to draw upon the richness
that is already present in the X.509 v3 certificate syntax.
- Sarbari
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================
> -----Original Message-----
> From: David Boyce [SMTP:D.Boyce@isode.com]
> Sent: Tuesday, October 13, 1998 8:08 AM
> To: Stefan Santesson
> Cc: Sarbari Gupta; 'Dwight Arthur'; ietf-pkix@imc.org
> Subject: Re: NEW Data type for certificate selection ?
>
> Stefan Santesson writes:
> >To your question. Does the X.500 matching rule cover selection by
> issuer
> >name according to your scheme?
> >My conclusion is that it does. You can specify any set of Issuer name
> >attributes you want and you get a match as long as your presented
> >attributes matches those of the target certificate.
> >(If any X.500 expert have another opinion, I would like to here it.)
>
> That appears to be broadly correct. Bear in mind that in order to
> match
> against a set of Issuer names, you will have to be able to specify
> multiple matching rules (one for each Issuer you wish to match
> against);
> a DAP/LDAP search filter allows you to do this, but in the specific
> context of this discussion (selection mechanisms for certificates)
> this
> may not apply.
>
> Sarbari also asked about matching against the prefix of the Issuer
> name.
> The short answer appears to be that that is not possible using the
> current definition of certificateMatch Matching Rule, since it always
> uses an equality match of the Issuer name. A new Matching Rule (or
> the
> present one modified) would have to be defined to support matching a
> prefix.
>
> If such a new prefix matching rule were defined, one way forward is to
> adapt either an X.501 SubtreeSpecification or X.509
> NameConstraintsSyntax to define the limits of matching. The latter,
> being X.509 based anyway, is probably the better choice since it also
> caters for similar matching against subjectAltName and issuerAltName.
>
> (I don't believe specifying 'prefix of Name' is adequate, since it may
> not be acceptable to match an Issuer at some greater depth than
> intended. Both SubtreeSpecification and NameConstraintsSyntax permit
> limits to be placed on the depth of the matching, and also permit the
> explicit exclusion of Names which would otherwise match.)
>
> >And as you see (Dwight), the policy OID is also covered by this
> structure.
>
> Correct; although I have some questions about its definition which I
> raise separately, they don't appear to affect this.
>
> David.
>
> --
> David Boyce
>
> Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
> Email: d.boyce@isode.com Isode's WWW:
> http://www.isode.com/
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16914 for ietf-pkix-bks; Tue, 13 Oct 1998 05:09:43 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16910 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 05:09:41 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 13 Oct 1998 13:09:55 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: ietf-pkix@imc.org
Subject: CertPolicySet definition (was Re: NEW Data type for certificate selection ? )
In-reply-to: Your message of "Mon, 12 Oct 1998 23:40:34 +0200." <3.0.32.19981012233953.00a39cf0@m1.403.telia.com>
Date: Tue, 13 Oct 1998 13:09:54 +0100
Message-ID: <21679.908280594@isode.com>
From: David Boyce <D.Boyce@isode.com>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA16911
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I have a couple of questions regarding the X.509 definition of
CertPolicySet which Stefan quoted.
Stefan Santesson writes:
>The certificateMatch has the following structure (X.509 section
12.7.2):
>
>certificateMatch MATCHING-RULE ::= {
> SYNTAX CertificateAssertion
> ID id-mr-certificateMatch }
>
>CertificateAssertion ::= SEQUENCE {
...
> policy [9] CertPolicySet OPTIONAL,
...
>CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId
Can anyone shed light on why this is called a CertPolicy*Set* when it's
defined as a SEQUENCE OF ?
The only thing I can think of is that the nature of the data is 'SET
OF', with the name reflecting that nature, but that 'SEQUENCE OF' has
been used in the definition of the type in order to avoid introducing
DER-encoding hassles.
> j) policy matches if all of the policy elements identified
> in one of the presented values are contained in the set of
> policyElementIds in any of the policyInformation values in
> the certificate policies extension in the stored attribute
> value; there is no match if there is no certificate policies
> extension in the stored attribute value;
Is there mismatch between this description and the defined syntax for
CertPolicySet here? The presence of the phrase 'in one of the presented
values' seems to indicate a different syntax to the one defined.
It looks to me as if the author had in mind a definition of
CertPolicySet along the lines of
CertPolicySet ::= SET (1..MAX) OF CertPolicyPresentedValues
CertPolicyPresentedValues ::= SET (1..MAX) OF CertPolicyId
(SET OF being regarded as equivalent to SEQUENCE OF for the purposes of
this discussion).
If not, then surely CertPolicySet would comprise the entire 'presented
value', making the phrase 'identified in one of the presented values'
misleading.
Or am I just reading something into the description which isn't there?
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16904 for ietf-pkix-bks; Tue, 13 Oct 1998 05:08:45 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16900 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 05:08:44 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 13 Oct 1998 13:08:18 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: Stefan Santesson <stefan@accurata.se>
cc: Sarbari Gupta <sgupta@cygnacom.com>, "'Dwight Arthur'" <dwightarthur@mindspring.com>, ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
In-reply-to: Your message of "Mon, 12 Oct 1998 23:40:34 +0200." <3.0.32.19981012233953.00a39cf0@m1.403.telia.com>
Date: Tue, 13 Oct 1998 13:08:10 +0100
Message-ID: <21672.908280490@isode.com>
From: David Boyce <D.Boyce@isode.com>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA16901
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Stefan Santesson writes:
>To your question. Does the X.500 matching rule cover selection by
issuer
>name according to your scheme?
>My conclusion is that it does. You can specify any set of Issuer name
>attributes you want and you get a match as long as your presented
>attributes matches those of the target certificate.
>(If any X.500 expert have another opinion, I would like to here it.)
That appears to be broadly correct. Bear in mind that in order to match
against a set of Issuer names, you will have to be able to specify
multiple matching rules (one for each Issuer you wish to match against);
a DAP/LDAP search filter allows you to do this, but in the specific
context of this discussion (selection mechanisms for certificates) this
may not apply.
Sarbari also asked about matching against the prefix of the Issuer name.
The short answer appears to be that that is not possible using the
current definition of certificateMatch Matching Rule, since it always
uses an equality match of the Issuer name. A new Matching Rule (or the
present one modified) would have to be defined to support matching a
prefix.
If such a new prefix matching rule were defined, one way forward is to
adapt either an X.501 SubtreeSpecification or X.509
NameConstraintsSyntax to define the limits of matching. The latter,
being X.509 based anyway, is probably the better choice since it also
caters for similar matching against subjectAltName and issuerAltName.
(I don't believe specifying 'prefix of Name' is adequate, since it may
not be acceptable to match an Issuer at some greater depth than
intended. Both SubtreeSpecification and NameConstraintsSyntax permit
limits to be placed on the depth of the matching, and also permit the
explicit exclusion of Names which would otherwise match.)
>And as you see (Dwight), the policy OID is also covered by this
structure.
Correct; although I have some questions about its definition which I
raise separately, they don't appear to affect this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA16330 for ietf-pkix-bks; Tue, 13 Oct 1998 03:30:38 -0700 (PDT)
Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA16326 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 03:30:34 -0700 (PDT)
From: r1naray@in.ibm.com
Received: from f03n05e.au.ibm.com (f03n05s.au.ibm.com [9.185.166.73]) by ausmtp02.au.ibm.com (1.0.0) with ESMTP id UAA55482; Tue, 13 Oct 1998 20:28:49 +1000
Received: from au.ibm.com (f06n01s [9.185.166.65]) by f03n05e.au.ibm.com (8.8.7/8.8.7) with SMTP id UAA44954; Tue, 13 Oct 1998 20:31:03 +1000
Received: by au.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id CA25669C.0039C2F2 ; Tue, 13 Oct 1998 20:30:54 +1000
X-Lotus-FromDomain: IBMIN@IBMAU
To: stefan@accurata.se
cc: sgupta@cygnacom.com, dwightarthur@mindspring.com, ietf-pkix@imc.org
Message-ID: <CA25669C.0039C1C4.00@au.ibm.com>
Date: Tue, 13 Oct 1998 15:55:04 +0530
Subject: RE: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello,
A sort of tangential question.
I'm not sure if you have glanced through the I-D on Atomic Certificates.
I was just wondering if anyone had any suggestions as to negotiation of
required Attributes for such a setup.
imho, this concept permits hiding from the user lots of gory details about
required attributes, since the setup
permits it to be automated.
There are two questions here :
Negotiating the trusted root - (will affect chaining, as has been pointed
out)
Negotiating the required Attributes - (will be very different with Atomic
Certificates, imho)
We are thinking of a trial run on Atomic Certificates, and for that, we
need to have a pilot protocol that uses it.
Any comments are welcome.
Thanks,
Regards,
narry
PS: for those who have not read the draft at
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
here's a very brief writeup of the concept.
Atomic Certificates are basically X.509v3 certificates containing NO
subject Name, and containing exactly ONE
extension, with criticality bit set to true. The peer is expected to
collect Attribute Certificates, for different attributes
signed by different CAs over a period of time. The peer would mix-n-match
and send to the other peer ONLY those
certificates that are required by the other peer, for validation. All the
Atomic Certificates have the same public key.
The whole thing centers around the concept that Certificates are not
documents that identify an entity, but are
documents that attest to an attribute of an entity.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21453 for ietf-pkix-bks; Mon, 12 Oct 1998 14:43:08 -0700 (PDT)
Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21449 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 14:43:07 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id XAA25418; Mon, 12 Oct 1998 23:43:54 +0200 (CEST)
Received: from stefans (t3o68p97.telia.com [62.20.139.97]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id XAA03765; Mon, 12 Oct 1998 23:43:48 +0200 (CEST)
Message-Id: <3.0.32.19981012233953.00a39cf0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 12 Oct 1998 23:40:34 +0200
To: Sarbari Gupta <sgupta@cygnacom.com>, "'Dwight Arthur'" <dwightarthur@mindspring.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: NEW Data type for certificate selection ?
Cc: ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA21450
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari,
As I see it I would not rule out any select criteria and say that in
general that criteria is better than another.
So personally I recognize your criteria solution as a very valid one in
some situations, as I also recognize Dwights policy OID as a valid criteria
in other cases.
To your question. Does the X.500 matching rule cover selection by issuer
name according to your scheme?
My conclusion is that it does. You can specify any set of Issuer name
attributes you want and you get a match as long as your presented
attributes matches those of the target certificate.
(If any X.500 expert have another opinion, I would like to here it.)
And as you see (Dwight), the policy OID is also covered by this structure.
The certificateMatch has the following structure (X.509 section 12.7.2):
certificateMatch MATCHING-RULE ::= {
SYNTAX CertificateAssertion
ID id-mr-certificateMatch }
CertificateAssertion ::= SEQUENCE {
serialNumber [0] CertificateSerialNumber OPTIONAL,
issuer [1] Name OPTIONAL,
subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,
authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,
certificateValid [4] Time OPTIONAL,
privateKeyValid [5] GeneralizedTime OPTIONAL,
subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,
keyUsage [7] KeyUsage OPTIONAL,
subjectAltName [8] AltNameType OPTIONAL,
policy [9] CertPolicySet OPTIONAL,
pathToName [10] Name OPTIONAL }
AltNameType ::= CHOICE {
builtinNameForm ENUMERATED {
rfc822Name (1),
dNSName (2),
x400Address (3),
directoryName (4),
ediPartyName (5),
uniformResourceIdentifier (6),
iPAddress (7),
registeredId (8) },
otherNameForm OBJECT IDENTIFIER }
CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId
The following is defined in X.509, concerning Issuer name and policy OID:
This matching rule returns TRUE if all of the components
that are present in the presented value match the corresponding
components of the attribute value, as follows:
b) issuer matches if the value of this component in the
attribute value equals that in the presented
value;
j) policy matches if all of the policy elements identified
in one of the presented values are contained in the set of
policyElementIds in any of the policyInformation values in
the certificate policies extension in the stored attribute
value; there is no match if there is no certificate policies
extension in the stored attribute value;
/Stefan
At 11:28 AM 10/12/98 -0400, Sarbari Gupta wrote:
>I have been following this thread with great interest. Since the thread
>was rekindled, I wanted to offer another usage model that needs a
>slightly different selection criterion. I was not sure whether this
>model was discussed before on this list.
>
>One of the certificate selection mechanisms in use today is based on
>matching the issuer name. SSL implementations allow this form of
>selection. There is another variant of this model that may also be
>useful. In this variant, the certificate selection is based on a prefix
>of the issuer name. For example, the selection may be done based only on
>the country name and the organization name components of the issuer DN.
>Thus, if a large organization has multiple CAs, the selection criteria
>may logically be "a certificate issued by the organization" instead of
>the more restrictive "a certificate issued by a particular CA within the
>organization".
>
>Do the X.500 matching rules support this kind of selection? This model
>may be useful for SSL connections. It will certainly be useful for
>S/MIME implementations; if the peer's certificate is part of an
>organization-specific PKI, the S/MIME implementation could conceivably
>select an appropriate certificate (for the user) based on a prefix of
>the issuer DN of the peer's certificate. Ideally, the S/MIME
>implementation would support a configurable set of prioritized selection
>criteria that allows the automatic selection of one amongst a set of
>user certificates.
>
>- Sarbari Gupta
>=============================
>Sarbari Gupta
>CygnaCom Solutions
>(703)848-0883 ext 217
>sgupta@cygnacom.com
>=============================
>
>> -----Original Message-----
>> From: Dwight Arthur [SMTP:dwightarthur@mindspring.com]
>> Sent: Friday, October 09, 1998 3:31 PM
>> To: Stefan Santesson; Alan Lloyd; ietf-pkix@imc.org;
>> list@seis.nc-forum.com; cert-talk@structuredarts.com
>> Subject: RE: NEW Data type for certificate selection ?
>>
>> I apologize for posting this after the thread has been summarized and
>> closed. The summary did not mention the part of the discussion that
>> suggested policy oids as the basis for a solution. I would like to
>> expand on
>> this.
>>
>> Selecting the right certificate is an instance of the general problem
>> of
>> building the right chain. This problem, in turn, needs to be closely
>> aligned
>> with the trust model being used. Many or most of the examples given
>> were
>> drawn from the so-called "open" or public model in which parties with
>> no
>> prior relationship (NPR) establish a (very low) level of trust because
>> someone in the public CA business has issued a certificate asserting
>> that
>> the subject produced documentary evidence of a certain identity.
>>
>> Other models, imho more suitable for significant business use, are:
>>
>> a. The parties have an existing business relationship and one of the
>> parties
>> has issued the other a certificate as a token of that relationship.
>> This
>> certificate is then to be used for access control and signing in
>> facilities
>> offered by the issuer. I believe that Netscape's crypto.signText()
>> function
>> provides a fully satisfactory method of saying, "I will only accept
>> certificates I issued." In addition, the emerging AADS approach
>> supports
>> this without requiring actual certificates.
>>
>> b. The parties share a relationship with an intermediary (bank,
>> finance
>> company, expeditor, factor, etc) who guarantees (for a fee) the
>> parties to
>> each other. Again, crypto.signText() or equivalents could be used to
>> say, "I
>> am looking for a certificate issued by MonsterBank" or a slightly more
>> complex form of AADS could be used.
>>
>> c. The parties share membership in an organization which, through
>> member
>> agreements, binds all parties to acceptable business terms and risk
>> management procedures. Similar procedures can be used as in (b): "I am
>> looking for your certificate issued by S.W.I.F.T."
>>
>> d. Each party has a relationship with an intermediary that's a member
>> of an
>> organization such as described in (c). Now we are looking for
>> something more
>> complex, like, "I will accept and debit card issued by any bank that
>> participates in NYCE or CIRRUS but not STAR." These relationships
>> should
>> imho _not_ be recorded in the client certificates as the data may
>> change
>> during the life of the certificate. Nor, imho, should the server send
>> a list
>> of the thousands of member banks as a part of its signing request.
>> Instead,
>> CIRRUS etc should each establish a certificate policy and form
>> contracts
>> with each participating bank binding it to the policy. It should
>> register
>> the policy and obtain an OID, then allow each member bank to issue
>> certificates bearing the OID. Your bank may then issue a certificate
>> to you
>> carrying the CIRRUS and STAR oids. I may send a signing request
>> calling for
>> certificates bearing NYCE or CIRRUS OIDs. Your browser would then
>> respond
>> with your bank certificate because the CIRRUS OID matched. If you have
>> several matching certificates (because, for example, you have several
>> bank
>> cards) the browser would ask you to chose, but the list of
>> alternatives
>> would be only your CIRRUS or NYCE bank cards and would exclude your
>> drivers
>> license, your library card, etc. Fraudulent certificates issued by
>> BongoCerts with the NYCE OID would be defeated either by (1) OCSP to
>> the
>> NYCE responder, or (2) your browser sends a certificate chain
>> including your
>> certificate from your bank and your bank's certificate from NYCE.
>>
>> e. Finally, the model that I personally believe will account for the
>> most
>> profitable segment of eCommerce: the employee card. I do not want to
>> offer
>> my employee a certificate for accessing our bank, a separate
>> certificate for
>> accessing our broker, a separate certificate for accessing our office
>> supplies vendor, and a separate certificate for accessing her 401K
>> plan.
>> (Too much overhead, doesn't fit on a smartcard, too much risk that we
>> l miss
>> one when it's time to revoke.) Instead, I want to offer every employee
>> a
>> certificate that says, "this is an employee of this company" that
>> allows
>> access to the benefits plans, the ability to initiate (but not
>> authorize)
>> office supplies purchases, and access to the appropriate gender
>> washrooms. I
>> may also offer some employees a different certificate (or an attribute
>> certificate that supplements the identity certificate) that includes a
>> policy OID that says, this is an officer, the company stands behind
>> and
>> honors commitments made by this person. In my cross-certification with
>> the
>> office supplies vendor, I can map my "this is an officer" policy with
>> the
>> vendor's "authorized approver of purchases" policy. Further, I could
>> map my
>> "this is an officer" policy to my bank's "authorized signer" policy or
>> I
>> could create a different "authorized for high value financial
>> transactions"
>> policy and map it to the appropriate policies of my bank and my
>> broker.
>> (Note, I am not inventing this policy mapping stuff, it's straight out
>> of
>> X.509) Now, when some other bank sends my employee a signing request
>> it asks
>> for something like "a certificate bearing the authorized signer OID
>> issued
>> by a bank that's a member of some ACH network." In this case, it is
>> necessary but not sufficient to select the right certificate. It is
>> further
>> necessary to build a chain of certificates, leading back to some
>> appropriate
>> root, with the specifies policies (or mapped policies) at every
>> certificate
>> in the chain.
>>
>> Note that I am _not_ advocating roles or authorizations in the
>> certificate.
>> I am advocating policies, represented by OIDs, that specify issues
>> like
>> acceptable uses of certificates, applicable communities of interest,
>> etc.
>> where all subjects, issuers, and authorized relying parties are bound
>> by
>> contract to the policy.
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21058 for ietf-pkix-bks; Mon, 12 Oct 1998 14:03:01 -0700 (PDT)
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21054 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 14:02:59 -0700 (PDT)
Received: by relay.hq.tis.com; id RAA03301; Mon, 12 Oct 1998 17:08:03 -0400 (EDT)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.1) id xma003291; Mon, 12 Oct 98 17:07:55 -0400
Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.9.1/8.9.1) with SMTP id RAA18692; Mon, 12 Oct 1998 17:02:52 -0400 (EDT)
Message-Id: <199810122102.RAA18692@clipper.hq.tis.com>
X-Sender: balenson@pop.hq.tis.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 12 Oct 1998 17:03:51 -0400
To: ietf-pkix@imc.org
From: "David M. Balenson" <balenson@tis.com>
Subject: NDSS '99 Registration Now Taking Place!!
Cc: balenson@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
R E G I S T E R N O W ! !
THE INTERNET SOCIETY'S
1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 3-5, 1999
Catamaran Resort Hotel
San Diego, California
General Chair: Steve Welke, Trusted Computer Solutions
Program Chairs: Steve Kent, BBN Technologies
Gene Tsudik, USC/Information Sciences Institute
ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99
EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 1999
The 6th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges. The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented. NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.
KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems. Co-author of
"Privacy on the Line: The Politics of Wiretapping and Encryption."
THIS YEAR'S TOPICS INCLUDE:
- Secure Password-Based Protocol for Downloading a Private Key
- A Real-World Analysis of Kerberos Password Security
- Secure Remote Access to an Internal Web Server
- Security and the User
- Experimenting with Shared Generation of RSA Keys
- Addressing the Problem of Undetected Signature Key Compromise
- Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
- New Approaches to BGP Security
- Distributed Policy Management for Java 1.2
- Distributed Execution with Remote Audit
- Trust-Based Authentication in Open Networks
- A Network Security Research Agenda
- PGRIP: PNNI Global Routing Infrastructure Protection
- A Cryptographic Countermeasure Against Connection Depletion Attacks
- IPSec: Friend or Foe?
EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Windows NT Security
- Cryptography
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)
- JAVA Security
FOR MORE INFORMATION contact the Internet Society:
Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
Phone: +1-703-648-9888
Fax: +1-703-648-9887
E-mail: ndss99reg@isoc.org
URL: http://www.isoc.org/ndss99/
SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high
visibility event. Contact Carla Rosenfeld at the Internet Society
at +1-703-648-9888 or send e-mail to carla@isoc.org.
THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.
----------------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738 USA
balenson@tis.com; 301-854-5358; fax 301-854-5363
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA18151 for ietf-pkix-bks; Mon, 12 Oct 1998 10:45:57 -0700 (PDT)
Received: from eng1.certicom.com (mailhost.certicom.com [209.121.99.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA18147 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 10:45:55 -0700 (PDT)
Received: from domino2.certicom.com (domino2.certicom.com [10.0.1.25]) by eng1.certicom.com (8.8.7/8.8.7) with SMTP id NAA20012; Mon, 12 Oct 1998 13:46:50 -0400 (EDT) (envelope-from plambert@certicom.com)
Received: by domino2.certicom.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 8525669B.0061B0AD ; Mon, 12 Oct 1998 13:47:02 -0400
X-Lotus-FromDomain: CERTICOM
From: "Paul Lambert" <plambert@certicom.com>
To: "Robert W. Shirey" <rshirey@bbn.com>
cc: ietf-pkix@imc.org
Message-ID: <8825669B.006018AF.00@domino2.certicom.com>
Date: Mon, 12 Oct 1998 10:33:35 -0700
Subject: Re: Photuris
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Rob,
Photuris was not in PKIX,, but was an IPsec document. There is good
information on Photuris at:
http://wserver.physnet.uni-hamburg.de/provos/photuris/
I'm not sure if this contains the very latest draft.
Regards,
Paul A. Lambert
Certicom Corp.
San Mateo, CA
+1650-312-7996
"Robert W. Shirey" <rshirey@bbn.com> on 10/12/98 08:26:19 AM
To: ietf-pkix@imc.org
cc: (bcc: Paul Lambert/Certicom)
Subject: Photuris
Is the latest draft for Photuris still posted somewhere where I can
download it?
Regards, -Rob-
rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766
Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200
1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA17124 for ietf-pkix-bks; Mon, 12 Oct 1998 08:30:57 -0700 (PDT)
Received: from rosslyn.BBN.COM (ROSSLYN.BBN.COM [192.1.7.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA17119 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 08:30:56 -0700 (PDT)
Received: from RSHIREY.BBN.COM by rosslyn.BBN.COM id aa24914; 12 Oct 98 11:35 EDT
X-Sender: rshirey@rosslyn.bbn.com
Message-Id: <v03110700b247cfefad24@[192.1.7.164]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 Oct 1998 11:26:19 -0400
To: ietf-pkix@imc.org
From: "Robert W. Shirey" <rshirey@bbn.com>
Subject: Photuris
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Is the latest draft for Photuris still posted somewhere where I can
download it?
Regards, -Rob-
rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766
Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200
1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA17085 for ietf-pkix-bks; Mon, 12 Oct 1998 08:29:39 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA17081 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 08:29:37 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDX9Z>; Mon, 12 Oct 1998 11:28:44 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9045@WUHER>
From: Sarbari Gupta <sgupta@cygnacom.com>
To: "'Dwight Arthur'" <dwightarthur@mindspring.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 12 Oct 1998 11:28:43 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I have been following this thread with great interest. Since the thread
was rekindled, I wanted to offer another usage model that needs a
slightly different selection criterion. I was not sure whether this
model was discussed before on this list.
One of the certificate selection mechanisms in use today is based on
matching the issuer name. SSL implementations allow this form of
selection. There is another variant of this model that may also be
useful. In this variant, the certificate selection is based on a prefix
of the issuer name. For example, the selection may be done based only on
the country name and the organization name components of the issuer DN.
Thus, if a large organization has multiple CAs, the selection criteria
may logically be "a certificate issued by the organization" instead of
the more restrictive "a certificate issued by a particular CA within the
organization".
Do the X.500 matching rules support this kind of selection? This model
may be useful for SSL connections. It will certainly be useful for
S/MIME implementations; if the peer's certificate is part of an
organization-specific PKI, the S/MIME implementation could conceivably
select an appropriate certificate (for the user) based on a prefix of
the issuer DN of the peer's certificate. Ideally, the S/MIME
implementation would support a configurable set of prioritized selection
criteria that allows the automatic selection of one amongst a set of
user certificates.
- Sarbari Gupta
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================
> -----Original Message-----
> From: Dwight Arthur [SMTP:dwightarthur@mindspring.com]
> Sent: Friday, October 09, 1998 3:31 PM
> To: Stefan Santesson; Alan Lloyd; ietf-pkix@imc.org;
> list@seis.nc-forum.com; cert-talk@structuredarts.com
> Subject: RE: NEW Data type for certificate selection ?
>
> I apologize for posting this after the thread has been summarized and
> closed. The summary did not mention the part of the discussion that
> suggested policy oids as the basis for a solution. I would like to
> expand on
> this.
>
> Selecting the right certificate is an instance of the general problem
> of
> building the right chain. This problem, in turn, needs to be closely
> aligned
> with the trust model being used. Many or most of the examples given
> were
> drawn from the so-called "open" or public model in which parties with
> no
> prior relationship (NPR) establish a (very low) level of trust because
> someone in the public CA business has issued a certificate asserting
> that
> the subject produced documentary evidence of a certain identity.
>
> Other models, imho more suitable for significant business use, are:
>
> a. The parties have an existing business relationship and one of the
> parties
> has issued the other a certificate as a token of that relationship.
> This
> certificate is then to be used for access control and signing in
> facilities
> offered by the issuer. I believe that Netscape's crypto.signText()
> function
> provides a fully satisfactory method of saying, "I will only accept
> certificates I issued." In addition, the emerging AADS approach
> supports
> this without requiring actual certificates.
>
> b. The parties share a relationship with an intermediary (bank,
> finance
> company, expeditor, factor, etc) who guarantees (for a fee) the
> parties to
> each other. Again, crypto.signText() or equivalents could be used to
> say, "I
> am looking for a certificate issued by MonsterBank" or a slightly more
> complex form of AADS could be used.
>
> c. The parties share membership in an organization which, through
> member
> agreements, binds all parties to acceptable business terms and risk
> management procedures. Similar procedures can be used as in (b): "I am
> looking for your certificate issued by S.W.I.F.T."
>
> d. Each party has a relationship with an intermediary that's a member
> of an
> organization such as described in (c). Now we are looking for
> something more
> complex, like, "I will accept and debit card issued by any bank that
> participates in NYCE or CIRRUS but not STAR." These relationships
> should
> imho _not_ be recorded in the client certificates as the data may
> change
> during the life of the certificate. Nor, imho, should the server send
> a list
> of the thousands of member banks as a part of its signing request.
> Instead,
> CIRRUS etc should each establish a certificate policy and form
> contracts
> with each participating bank binding it to the policy. It should
> register
> the policy and obtain an OID, then allow each member bank to issue
> certificates bearing the OID. Your bank may then issue a certificate
> to you
> carrying the CIRRUS and STAR oids. I may send a signing request
> calling for
> certificates bearing NYCE or CIRRUS OIDs. Your browser would then
> respond
> with your bank certificate because the CIRRUS OID matched. If you have
> several matching certificates (because, for example, you have several
> bank
> cards) the browser would ask you to chose, but the list of
> alternatives
> would be only your CIRRUS or NYCE bank cards and would exclude your
> drivers
> license, your library card, etc. Fraudulent certificates issued by
> BongoCerts with the NYCE OID would be defeated either by (1) OCSP to
> the
> NYCE responder, or (2) your browser sends a certificate chain
> including your
> certificate from your bank and your bank's certificate from NYCE.
>
> e. Finally, the model that I personally believe will account for the
> most
> profitable segment of eCommerce: the employee card. I do not want to
> offer
> my employee a certificate for accessing our bank, a separate
> certificate for
> accessing our broker, a separate certificate for accessing our office
> supplies vendor, and a separate certificate for accessing her 401K
> plan.
> (Too much overhead, doesn't fit on a smartcard, too much risk that we
> l miss
> one when it's time to revoke.) Instead, I want to offer every employee
> a
> certificate that says, "this is an employee of this company" that
> allows
> access to the benefits plans, the ability to initiate (but not
> authorize)
> office supplies purchases, and access to the appropriate gender
> washrooms. I
> may also offer some employees a different certificate (or an attribute
> certificate that supplements the identity certificate) that includes a
> policy OID that says, this is an officer, the company stands behind
> and
> honors commitments made by this person. In my cross-certification with
> the
> office supplies vendor, I can map my "this is an officer" policy with
> the
> vendor's "authorized approver of purchases" policy. Further, I could
> map my
> "this is an officer" policy to my bank's "authorized signer" policy or
> I
> could create a different "authorized for high value financial
> transactions"
> policy and map it to the appropriate policies of my bank and my
> broker.
> (Note, I am not inventing this policy mapping stuff, it's straight out
> of
> X.509) Now, when some other bank sends my employee a signing request
> it asks
> for something like "a certificate bearing the authorized signer OID
> issued
> by a bank that's a member of some ACH network." In this case, it is
> necessary but not sufficient to select the right certificate. It is
> further
> necessary to build a chain of certificates, leading back to some
> appropriate
> root, with the specifies policies (or mapped policies) at every
> certificate
> in the chain.
>
> Note that I am _not_ advocating roles or authorizations in the
> certificate.
> I am advocating policies, represented by OIDs, that specify issues
> like
> acceptable uses of certificates, applicable communities of interest,
> etc.
> where all subjects, issuers, and authorized relying parties are bound
> by
> contract to the policy.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA15343 for ietf-pkix-bks; Mon, 12 Oct 1998 04:06:47 -0700 (PDT)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA15339 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 04:06:45 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id NAA10967; Mon, 12 Oct 1998 13:06:23 +0200 (CEST)
Received: from stefans (t2o68p80.telia.com [62.20.138.200]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA06826; Mon, 12 Oct 1998 13:06:04 +0200 (CEST)
Message-Id: <3.0.32.19981012125924.00a33b80@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 12 Oct 1998 13:03:04 +0200
To: Stephen Kent <kent@bbn.com>, "Dwight Arthur" <dwightarthur@mindspring.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: NEW Data type for certificate selection ?
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA15340
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dwight and Stephen,
Thank you Dwight for valuable information.
Just some remarks.
1) I did not focus on a prticular selecting mechanism such as policy OID
over Issuer Name. I'm looking for selective mechanisms that will work
generally in standard products in closed and in open environments.
2) Selection by policy OID is covered by the discussed X.500
certificateMatch rule
3) Thank you for pointing out that Netscape have mechanisms for slecting
certificate by issuer in crypto.signText(). This was new to mee. I will
check this within our projects.
3) My primary concern is how to manage certificate selection by using
standard products. I'm not focusing on whether this is a closed or an open
PKI. In my cases the PKI is closed in most cases but the problem is still
relevant.
/Stefan Santesson
At 12:13 PM 10/11/98 -0400, Stephen Kent wrote:
>Dwight,
>
>Thanks for a good characterization of the underlying assumptions that have
>been driving much of this discussion. I agree completely! In a completely
>open, public PKI model, it's very hard to find the "right" certificate and
>I agree that this sort of PKI model is questionable for many reasons, not
>just in a business context. I'll send you a paper on the topic from last
>fall, separately, that I believe you will find consistent with the views
>articulated in your message.
>
>Steve
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA20088 for ietf-pkix-bks; Sun, 11 Oct 1998 09:12:50 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20084 for <ietf-pkix@imc.org>; Sun, 11 Oct 1998 09:12:49 -0700 (PDT)
Received: from [128.33.238.25] (TC085.BBN.COM [128.33.238.85]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA20787; Sun, 11 Oct 1998 12:13:01 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011704b24688f40e3f@[128.33.238.25]>
In-Reply-To: <000401bdf3bb$5f6f3740$3b8556d1@ns95lap005.nscc.com>
References: <3.0.32.19980928111642.00a76390@m1.403.telia.com>
Date: Sun, 11 Oct 1998 12:13:05 -0400
To: "Dwight Arthur" <dwightarthur@mindspring.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dwight,
Thanks for a good characterization of the underlying assumptions that have
been driving much of this discussion. I agree completely! In a completely
open, public PKI model, it's very hard to find the "right" certificate and
I agree that this sort of PKI model is questionable for many reasons, not
just in a business context. I'll send you a paper on the topic from last
fall, separately, that I believe you will find consistent with the views
articulated in your message.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04708 for ietf-pkix-bks; Sat, 10 Oct 1998 07:34:53 -0700 (PDT)
Received: from vop.nucleus.com (vop.nucleus.com [207.34.93.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04704 for <ietf-pkix@imc.org>; Sat, 10 Oct 1998 07:34:52 -0700 (PDT)
Received: from loki (unverified [207.34.67.172]) by vop.nucleus.com (Vircom SMTPRS 1.0.1691) with SMTP id <B0003902608@vop.nucleus.com>; Sat, 10 Oct 1998 08:35:15 -0600
Message-Id: <3.0.5.32.19981010083939.009ca1b0@dreamwvr.com>
X-Sender: dreamwvr@dreamwvr.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 10 Oct 1998 08:39:39 -0600
To: pgut001@cs.auckland.ac.nz, cert-talk@structuredarts.com, ietf-pkix@imc.org
From: dreamwvr <dreamwvr@dreamwvr.com>
Subject: CERT
In-Reply-To: <199810100020.RAA23723@gateway-ext.StructuredArts.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
hi,
i am looking for some URLS that describe how to setup your own certificate
server on linux. I am interested for test purposes only. Also is this a
howto that describes how to add additional non default certificates to
communicator? All your assistance is appreciated.
Regards,
dreamwvr@dreamwvr.com
Reuters, London, February 29, 1998:
Scientists have announced discovering a meteorite which will strike the
earth in March, 2028. Millions of UNIX coders expressed relief for being
spared the UNIX epoch "crisis" of 2038.
_______________________________________________________________________
DREAMWVR.COM - TOTAL WEB INTEGRATION, DEVELOPMENT, DESIGN SERVICES.
Featuring Website Development and Web Strategies of a TOP Developer
<http://www.dreamwvr.com/dynamicduo.html> <mailto:dreamwvr@dreamwvr.com>
"As Unique as the Company You Keep." "===0 PGP Key Available
________________________________________________________________________
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA11978 for ietf-pkix-bks; Fri, 9 Oct 1998 18:12:26 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA11974 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 18:12:23 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id OAA16127; Sat, 10 Oct 1998 14:12:40 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90798195929090>; Sat, 10 Oct 1998 14:12:39 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cert-talk@structuredarts.com, ietf-pkix@imc.org
Subject: Interesting(?) sample certificate
Reply-To: pgut001@cs.auckland.ac.nz
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 10 Oct 1998 14:12:39 (NZDT)
Message-ID: <90798195929090@cs26.cs.auckland.ac.nz>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
For your edification I have prepared a sample cert which people may find
interesting. You can find it at
http://www.cs.auckland.ac.nz/~pgut001/pubs/dave.der, with the issuing cert at
http://www.cs.auckland.ac.nz/~pgut001/pubs/dave_ca.der. An ASN.1 dump of the
cert is:
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 2
}
INTEGER 9188644
SEQUENCE {
OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER countryName (2 5 4 6)
PrintableString 'NZ'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
TeletexString 'Dave's Wetaburgers and CA'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
PrintableString 'Certification Division'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
PrintableString 'Dave Himself'
}
}
}
SEQUENCE {
UTCTime '981007082404Z'
UTCTime '990912032309Z'
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER countryName (2 5 4 6)
PrintableString 'NZ'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
TeletexString 'Dave's Wetaburgers'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
PrintableString 'Procurement'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
PrintableString 'Dave Smith'
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING 0 unused bits
30 48 02 41 00 C8 E1 BB 88 F5 87 48 7C A7 96 00
50 A5 03 13 BA 81 7C 8F DD 55 FB 88 4B F4 82 6D
15 82 D1 ED 2D 69 EC 65 43 C8 70 7C 0F 8B E9 EE
B5 B7 96 C5 4C 3B 95 71 D2 A7 23 80 89 0B 48 B5
2B 29 C9 5F 1D 02 03 01 00 01
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
BOOLEAN TRUE
OCTET STRING, encapsulates {
BIT STRING 5 unused bits
'111'B
}
}
SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17)
OCTET STRING, encapsulates {
SEQUENCE {
[0] {
OBJECT IDENTIFIER mpeg-1 (1 3 6 1 4 1 3029 42 11172 1)
[0] {
OCTET STRING
00 00 01 B3 16 01 20 83 02 AE 60 A4 00 00 01 B8
00 08 00 00 00 00 01 00 00 8A 75 00 00 00 01 01
2B FB AA 3E 68 96 93 A7 7E D3 7E F7 90 90 18 B0
60 C5 EE D9 B8 7C D9 77 1D 73 52 1A F4 06 F4 F5
F3 5E 9A 92 5E 10 00 93 38 06 45 F0 46 FA 2F 02
50 19 57 BB 75 DF 3B 04 02 92 12 4B 00 BB F4 23
A7 F0 2A 59 CB 03 C5 50 4C 24 F1 DB 1F 6E 02 7C
E4 C4 87 11 EA EF 22 05 00 27 0E 49 1B DF 67 28
[ Another 1220786 bytes skipped ]
}
}
[1] 'dave@wetas-r-us.com'
[6] 'http://www.wetas-r-us.com'
}
}
}
SEQUENCE {
OBJECT IDENTIFIER basicConstraints (2 5 29 19)
BOOLEAN TRUE
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING 0 unused bits
78 B3 5F 74 E7 23 08 C2 FA E2 38 7F DE 08 F6 B2
59 E9 3F BE B9 8F 18 00 F5 72 47 FA 99 32 DB C1
32 BC 1E 9B 36 95 AD 2D 92 8C B3 B1 D4 71 23 FF
5E 73 48 47 F5 C4 5B 6F 40 76 81 78 28 8D D8 C0
}
Peter.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10870 for ietf-pkix-bks; Fri, 9 Oct 1998 14:50:42 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10866 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 14:50:40 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id TAA00707; Fri, 9 Oct 1998 19:51:07 -0200
Date: Fri, 9 Oct 1998 19:51:06 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Phillip M Hallam-Baker <pbaker@verisign.com>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, ietf-pkix@imc.org, Einar Stefferud <Stef@nma.com>
Subject: RE: Common misconception #10. was RE: NEW Data type forcertificate
In-Reply-To: <001801bdf3c0$aa5f88e0$9d07a8c0@pbaker-pc.verisign.com>
Message-ID: <Pine.LNX.4.02.9810091850060.542-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Fri, 9 Oct 1998, Phillip M Hallam-Baker wrote:
> Ed Gerck wrote:
>
>> My assertion was "every PKIX CA must inevitably disclaim all legal
>> liability to the user" -- not to the subscriber.
>
>A statement which is untrue, completely and utterly wrong.
>
Denial is good. But it is no more than a marketing technique when
Verisign's own warranty declaration and CPS say what I affirm and you
deny.
I also note, for the record and I have already made that clear, what
is called a CA "user" is not the subscriber that buys the cert
services from the CA, but the Joe Doe that needs to rely on the cert
presented by the subscriber and that has no relationship whatsoever
with the CA. Certainly, the majority of cases in international trade,
since not all users will also be customers of the very same CA.
This question gains in importance as we remember that there is no
international law system that uniquely defines matters, not even in
the same country. So, a cert user represents an open risk also in the
legal sense, and not only in terms of key-snatching, virus, etc.
Given the overabundance of lawyers in the US alone and the growing
attitude of finding culprits for one's own lack of foresight, any CA
that makes an offer to the whole world, capable of acceptance without
communication and by mere conduct, is suicidal.
Is this relevant to PKIX? No, if PKIX is being designed to work
within a company or in a bounded environment, where subscribers and
users share a common and pre-existent trusted environment. Yes, if
PKIX wants to address no-previous relationship cases worldwide.
>
>> BTW, you did not show any counterarguments.
>
>I believe that I countered your statement that a CPS cannot
>be audited by stating that the ABA was working on audit standards
>for that very purpose.
>
First, the statement that current CPSs cannot be audited was NOT mine
(as you unfortunately misstated) but YOUR own and public, verbatim
as:
The CPS is not a document designed for auditing use however. It
describes a 'specification', it does not describe details which may
be checked by a third party in a systematic manner."
Second, it is very probable that *any* future CPS standards (of which
there are none today) will NOT provide any assurance of correct
results -- just correct methods and within some broad assumtpions.
Which is however already granted by law such as by the UCC. Thus, the
"new" CPS standard will very probably simply deal with a convergence
of terms and clauses, while leaving open the door I mentioned you
saying.
But, while that remains to be seen it is perhaps clear that you
cannot cite non-existent CPS regulations to say that current CPSs are
or will be auditable in a next incarnation. Oftentimes, problems have
no solutions in a broader scope. In particular, I have reasonable
doubt that one could ever audit or warrant ***results*** in CA
certification.
>As an employee of the major CA on the Internet I am not going
>to speculate on the future liabilities or insurance which might
>be offered by VeriSign or any of its competitors here. The PKIX
>architecture does not prevent such products being offered or
>supported which was your claim.
>
I appreciate your technical and business competence.
However, I may indeed question why all the work if no public CA will
ever be able to offer public warranty on results, from a general
subscriber to the general public. Which is what the public needs.
>I will merely remind people that five years ago folk were loudly
>proclaiming that a public CA such as VeriSign was an impossibility.
I did not say that. In fact, I have recently affirmed it is a very
good business to be a CA. The question is ...what next?
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09988 for ietf-pkix-bks; Fri, 9 Oct 1998 13:09:25 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA09984 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 13:09:24 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA19908; Fri, 9 Oct 1998 13:06:52 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA29062; Fri, 9 Oct 1998 13:08:56 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Dwight Arthur" <dwightarthur@mindspring.com>, "Stefan Santesson" <stefan@accurata.se>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Subject: RE: NEW Data type for certificate selection ?
Date: Fri, 9 Oct 1998 16:09:16 -0400
Message-ID: <001a01bdf3c0$b0d28920$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <000401bdf3bb$5f6f3740$3b8556d1@ns95lap005.nscc.com>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Note that I am _not_ advocating roles or authorizations in the
> certificate.
> I am advocating policies, represented by OIDs, that specify issues like
> acceptable uses of certificates, applicable communities of interest, etc.
> where all subjects, issuers, and authorized relying parties are bound by
> contract to the policy.
A very important distinction. If there is a private agreement to recognize
a particular OID as having a specific semantics the extension is logically
a simple reference to a commonly agreed standard.
The problem comes in attempting to create public standards for such
agreements ab initio. Clearly private agreements can be widely adopted
and evolve into public standards through use and convention. It is
very hard to invent public conventions however.
You may be interested in the eTerms project of the ICC which is essentially
a third party repository into which terms of this nature can be deposited.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09982 for ietf-pkix-bks; Fri, 9 Oct 1998 13:08:42 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA09978 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 13:08:41 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA19902; Fri, 9 Oct 1998 13:06:42 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA29043; Fri, 9 Oct 1998 13:08:45 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ed Gerck" <egerck@laser.cps.softex.br>
Cc: "Anders Rundgren" <anders.rundgren@jaybis.com>, <ietf-pkix@imc.org>, "Einar Stefferud" <Stef@nma.com>
Subject: RE: Common misconception #10. was RE: NEW Data type forcertificate
Date: Fri, 9 Oct 1998 16:09:05 -0400
Message-ID: <001801bdf3c0$aa5f88e0$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <Pine.LNX.4.02.9810091615300.542-100000@laser.cps.softex.br>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> My assertion was "every PKIX CA must inevitably disclaim all legal
> liability to the user" -- not to the subscriber.
A statement which is untrue, completely and utterly wrong.
> BTW, you did not show any counterarguments.
I believe that I countered your statement that a CPS cannot
be audited by stating that the ABA was working on audit standards
for that very purpose.
As an employee of the major CA on the Internet I am not going
to speculate on the future liabilities or insurance which might
be offered by VeriSign or any of its competitors here. The PKIX
architecture does not prevent such products being offered or
supported which was your claim.
I will merely remind people that five years ago folk were loudly
proclaiming that a public CA such as VeriSign was an impossibility.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA09770 for ietf-pkix-bks; Fri, 9 Oct 1998 12:31:34 -0700 (PDT)
Received: from camel7.mindspring.com (camel7.mindspring.com [207.69.200.57]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09766 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 12:31:33 -0700 (PDT)
Received: from ns95lap005.nscc.com (user-38ld19r.dialup.mindspring.com [209.86.133.59]) by camel7.mindspring.com (8.8.5/8.8.5) with SMTP id PAA10912; Fri, 9 Oct 1998 15:31:47 -0400 (EDT)
From: "Dwight Arthur" <dwightarthur@mindspring.com>
To: "Stefan Santesson" <stefan@accurata.se>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Subject: RE: NEW Data type for certificate selection ?
Date: Fri, 9 Oct 1998 15:31:12 -0400
Message-ID: <000401bdf3bb$5f6f3740$3b8556d1@ns95lap005.nscc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <3.0.32.19980928111642.00a76390@m1.403.telia.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I apologize for posting this after the thread has been summarized and
closed. The summary did not mention the part of the discussion that
suggested policy oids as the basis for a solution. I would like to expand on
this.
Selecting the right certificate is an instance of the general problem of
building the right chain. This problem, in turn, needs to be closely aligned
with the trust model being used. Many or most of the examples given were
drawn from the so-called "open" or public model in which parties with no
prior relationship (NPR) establish a (very low) level of trust because
someone in the public CA business has issued a certificate asserting that
the subject produced documentary evidence of a certain identity.
Other models, imho more suitable for significant business use, are:
a. The parties have an existing business relationship and one of the parties
has issued the other a certificate as a token of that relationship. This
certificate is then to be used for access control and signing in facilities
offered by the issuer. I believe that Netscape's crypto.signText() function
provides a fully satisfactory method of saying, "I will only accept
certificates I issued." In addition, the emerging AADS approach supports
this without requiring actual certificates.
b. The parties share a relationship with an intermediary (bank, finance
company, expeditor, factor, etc) who guarantees (for a fee) the parties to
each other. Again, crypto.signText() or equivalents could be used to say, "I
am looking for a certificate issued by MonsterBank" or a slightly more
complex form of AADS could be used.
c. The parties share membership in an organization which, through member
agreements, binds all parties to acceptable business terms and risk
management procedures. Similar procedures can be used as in (b): "I am
looking for your certificate issued by S.W.I.F.T."
d. Each party has a relationship with an intermediary that's a member of an
organization such as described in (c). Now we are looking for something more
complex, like, "I will accept and debit card issued by any bank that
participates in NYCE or CIRRUS but not STAR." These relationships should
imho _not_ be recorded in the client certificates as the data may change
during the life of the certificate. Nor, imho, should the server send a list
of the thousands of member banks as a part of its signing request. Instead,
CIRRUS etc should each establish a certificate policy and form contracts
with each participating bank binding it to the policy. It should register
the policy and obtain an OID, then allow each member bank to issue
certificates bearing the OID. Your bank may then issue a certificate to you
carrying the CIRRUS and STAR oids. I may send a signing request calling for
certificates bearing NYCE or CIRRUS OIDs. Your browser would then respond
with your bank certificate because the CIRRUS OID matched. If you have
several matching certificates (because, for example, you have several bank
cards) the browser would ask you to chose, but the list of alternatives
would be only your CIRRUS or NYCE bank cards and would exclude your drivers
license, your library card, etc. Fraudulent certificates issued by
BongoCerts with the NYCE OID would be defeated either by (1) OCSP to the
NYCE responder, or (2) your browser sends a certificate chain including your
certificate from your bank and your bank's certificate from NYCE.
e. Finally, the model that I personally believe will account for the most
profitable segment of eCommerce: the employee card. I do not want to offer
my employee a certificate for accessing our bank, a separate certificate for
accessing our broker, a separate certificate for accessing our office
supplies vendor, and a separate certificate for accessing her 401K plan.
(Too much overhead, doesn't fit on a smartcard, too much risk that we l miss
one when it's time to revoke.) Instead, I want to offer every employee a
certificate that says, "this is an employee of this company" that allows
access to the benefits plans, the ability to initiate (but not authorize)
office supplies purchases, and access to the appropriate gender washrooms. I
may also offer some employees a different certificate (or an attribute
certificate that supplements the identity certificate) that includes a
policy OID that says, this is an officer, the company stands behind and
honors commitments made by this person. In my cross-certification with the
office supplies vendor, I can map my "this is an officer" policy with the
vendor's "authorized approver of purchases" policy. Further, I could map my
"this is an officer" policy to my bank's "authorized signer" policy or I
could create a different "authorized for high value financial transactions"
policy and map it to the appropriate policies of my bank and my broker.
(Note, I am not inventing this policy mapping stuff, it's straight out of
X.509) Now, when some other bank sends my employee a signing request it asks
for something like "a certificate bearing the authorized signer OID issued
by a bank that's a member of some ACH network." In this case, it is
necessary but not sufficient to select the right certificate. It is further
necessary to build a chain of certificates, leading back to some appropriate
root, with the specifies policies (or mapped policies) at every certificate
in the chain.
Note that I am _not_ advocating roles or authorizations in the certificate.
I am advocating policies, represented by OIDs, that specify issues like
acceptable uses of certificates, applicable communities of interest, etc.
where all subjects, issuers, and authorized relying parties are bound by
contract to the policy.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA09332 for ietf-pkix-bks; Fri, 9 Oct 1998 11:34:20 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA09328 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 11:34:15 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id QAA00571; Fri, 9 Oct 1998 16:34:24 -0200
Date: Fri, 9 Oct 1998 16:34:24 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Phillip M Hallam-Baker <pbaker@verisign.com>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, ietf-pkix@imc.org, Einar Stefferud <Stef@nma.com>
Subject: RE: Common misconception #10. was RE: NEW Data type for certificate
In-Reply-To: <006201bdf3a5$08de9440$9d07a8c0@pbaker-pc.verisign.com>
Message-ID: <Pine.LNX.4.02.9810091615300.542-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Fri, 9 Oct 1998, Phillip M Hallam-Baker wrote:
>Ed,
>
> This has gone way off topic for PKIX. I don't see a limitation
>of the PKIX infrastructure being discussed, clearly the types of insurance
>you envision can be supported by PKIX. If a customer wants to purchase a
>cert carrying such insurance the technology clearly is not the impediment.
Phill:
If you believe that insurance is a topic for PKIX, pls go ahead.
If you believe that one-sided PKIX subscriber-CA insurance can solve
the security problem of many-sided PKIX user-subscriber security, pls
also go ahead.
>
> I really don't think that the tone of your argument is suitable
>for a PKIX discussion which has already gone off topic. You started off
>with a blanket assertion that every PKIX CA must inevitably disclaim
>all legal liability. That is simply not true.
>
My assertion was "every PKIX CA must inevitably disclaim all legal
liability to the user" -- not to the subscriber.
The fact that you, again, want to put a blank denial over a
qualified denial is misleading to say the least.
If you think that you can use the tone you want but others cannot
disagree in technical terms, as I did, then this is a "hollier than
thou attitude" which would be slightly amusing if PKIX would be
private and personal -- but which is unacepatble for a IETF
discussion, IMHO.
BTW, to say that it "is simply not true" is too simple -- sorry, no
cigar.
> I really don't think I want to continue to debate with someone
>who titles their emails 'common misconception #10'. It betrays an
>apparent intention to demonstrate the ignorance and wrong headedness
>of the other side.
>
No, it says what it is -- a common misconception, also rather old.
BTW, you did not show any counterarguments.
> You appear to be arguing that the emperor has not clothes and that you
>are the only taylor who can dress him.
That is again a blank statement you put out. But, again, I refuse to
be bound by words I did not say. Please, do not keep trying that
because I will keep denying I said so -- with the difference that I
can prove that I did not say it. Truth begins at samll values.
>Whether or not we accept your first
>premise I doubt many accept your second. The emperor has sufficient clothes
>for the weather he is currently going out in and by the time the weather is
>worse he will have donned his multi-layer alpine ski wear and hazardous
>environment encounter suit.
I doubt your own statement is on-topic for PKIX. To say that
something is "sufficient" demands proof -- which you did not show,
while I did show otherwise. Hence your paragraph above has no content
I acn measure.
Just don't try to convince the whole world that everyone should buy
into it just because you say it will be just fine. The very fact that
you did not answer one of the questions I posed already shows that
you are still talking about emperors while the Internet is already
beyond democracy.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA08655 for ietf-pkix-bks; Fri, 9 Oct 1998 09:51:01 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA08651 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 09:51:00 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA15424; Fri, 9 Oct 1998 09:49:01 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA14360; Fri, 9 Oct 1998 09:50:58 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ed Gerck" <egerck@laser.cps.softex.br>
Cc: "Anders Rundgren" <anders.rundgren@jaybis.com>, <ietf-pkix@imc.org>
Subject: RE: Common misconception #10. was RE: NEW Data type for certificate
Date: Fri, 9 Oct 1998 12:51:18 -0400
Message-ID: <006201bdf3a5$08de9440$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <Pine.LNX.4.02.9810071337220.392-100000@laser.cps.softex.br>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
This has gone way off topic for PKIX. I don't see a limitation
of the PKIX infrastructure being discussed, clearly the types of insurance
you envision can be supported by PKIX. If a customer wants to purchase a
cert carrying such insurance the technology clearly is not the impediment.
I really don't think that the tone of your argument is suitable
for a PKIX discussion which has already gone off topic. You started off
with a blanket assertion that every PKIX CA must inevitably disclaim
all legal liability. That is simply not true.
I really don't think I want to continue to debate with someone
who titles their emails 'common misconception #10'. It betrays an
apparent intention to demonstrate the ignorance and wrong headedness
of the other side.
You appear to be arguing that the emperor has not clothes and that you
are the only taylor who can dress him. Whether or not we accept your first
premise I doubt many accept your second. The emperor has sufficient clothes
for the weather he is currently going out in and by the time the weather is
worse he will have donned his multi-layer alpine ski wear and hazardous
environment encounter suit.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA01533 for ietf-pkix-bks; Fri, 9 Oct 1998 01:50:48 -0700 (PDT)
Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA01529 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 01:50:42 -0700 (PDT)
From: r1naray@in.ibm.com
Received: from f03n05e.au.ibm.com (f03n05s.au.ibm.com [9.185.166.73]) by ausmtp02.au.ibm.com (1.0.0) with ESMTP id SAA26070; Fri, 9 Oct 1998 18:48:24 +1000
Received: from au.ibm.com (f06n04s [9.185.166.98]) by f03n05e.au.ibm.com (8.8.7/8.8.7) with SMTP id SAA18478; Fri, 9 Oct 1998 18:50:34 +1000
Received: by au.ibm.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id CA256698.003BF108 ; Fri, 9 Oct 1998 18:50:27 +1000
X-Lotus-FromDomain: IBMIN@IBMAU
To: ietf-pkix@imc.org
cc: wford@verisign.com, kent@bbn.com
Message-ID: <65256698.002D346A.00@au.ibm.com>
Date: Fri, 9 Oct 1998 13:58:04 +0530
Subject: New ID - Atomic Certificates
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello,
I'd like to bring to the attention of the work group, an I-D I've just
submitted, that I hope will follow the standards track.
Though I'd have liked very much to have submitted it through the group, I
was told by the work group chairs that I'd best submit it as an Independent
Internet Draft and bring it to the attention of the work group.
The I-D can be accessed at:
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
Thanks,
Regards,
Narayan Raghu
IBM Bangalore
India
ABSTRACT
The existing PKI has a few inherent limitations like:
1. It is implicitly assumed that the two trading parties have ONE
mutually trusted third party that can attest ALL of each
party's attributes. It provides no mechanism to separate out the
fields in a certificate for attestation by different Certification
Authorities.
2. This standard in no way gives the flexibility to expose only
certain fields of a certificate to the other party.
This memo proposes a model which, while working well within the
X.509v3 framework, overcomes these limitations by
breaking up a certificate into pre-signed "unit attestations"
referred to as "Atomic Certificates" and packaging them in the
X.509v3 format only at the time of sending the certificate to the
other party.
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08183 for ietf-pkix-bks; Thu, 8 Oct 1998 12:29:29 -0700 (PDT)
Received: from camel14.mindspring.com (camel14.mindspring.com [207.69.200.64]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08178 for <ietf-pkix@imc.org>; Thu, 8 Oct 1998 12:29:26 -0700 (PDT)
Received: from ns95lap005.nscc.com (pool-207-205-161-29.nwrk.grid.net [207.205.161.29]) by camel14.mindspring.com (8.8.5/8.8.5) with SMTP id PAA13977; Thu, 8 Oct 1998 15:29:19 -0400 (EDT)
From: "Dwight Arthur" <dwightarthur@mindspring.com>
To: "Stefan Santesson" <stefan@accurata.se>, "David Horvath" <dave@chromatix.com>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <pgut001@cs.auckland.ac.nz>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 8 Oct 1998 15:28:48 -0400
Message-ID: <000601bdf2f1$df93fde0$1da1cdcf@ns95lap005.nscc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-reply-to: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
A similar application has been tested by the Internet Council of the
National Automated Clearing House Association (NACHA) - see
www.internetcouncil.org
The Javascript "crypto.signText()" function implemented in Netscape
Communicator 4.04 permits a solution to the issue you describe. One of the
fields passed to the function delineates acceptable certificates, I believe
it is a list of acceptable signers.
--------------------------------------------------
p:(212) 412-8687 Dwight Arthur
f:(212) 908-2345 Managing Director: Systems
b:(917) 646-6682 National Securities Clearing
dwightarthur@mindspring.com 55 Water Street
http://www.nscc.com New York, NY 10041-0082
-----Original Message-----
From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org] On Behalf Of
Stefan Santesson
Sent: Wednesday, September 30, 1998 10:44 AM
To: David Horvath; Alan Lloyd
Cc: 'ietf-pkix@imc.org '; 'list@seis.nc-forum.com ';
'pgut001@cs.auckland.ac.nz '
Subject: Re: NEW Data type for certificate selection ?
David,
Thank's for putting this issue in the right focus.
Alan, I don't suggest any new certificate extensions
Ed, I don't want to define any universal criteria for how certificate
selection SHALL be done or any who decides what for whom, regulations.
All I want to do is to define some mechanisms that CAN be used, if
required, by local PKI-related services in order to make it POSSIBLE for
them to build working services with STANDARD components.
Let me highlight this again and describe a realistic problem relevant to me.
Bank A offer web-based banking applications. This requires the end user to
get a specific certificate issued by Bank A. The certificate and the
corresponding private key is processed through the standard web browser of
the client
Two certificates and private keys are used in the normal process.
1) Certificate for SSL (TLS) security
2) Certificate for non-repudiation protection of Bank transactions.
In addition to these certificates, a specific end-user may be populated
with several other certificates, un-known to the Bank.
The question is. How can this Bank create a web based application without
distributing a customized client plug-in for the purpose. Well the Bank can
get far using Java Scripts but it will fail due to the problem that the
end-user may have to select a certificate.
Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.
I realize that today there is no way to do this without distributing
customized plug-in components to end-users, but I strongly would like to se
options developed that helps getting around this. The current matching
mechanism in SSL and TLS is just not good enough to solve the problem.
So If we instead had a standardized matching rule that could be invoked
into protocols and Java Scripts etc, then the situation would be much more
hopeful for the Bank in my case.
They would then construct a match rule that with high probability would
point out the right end-user certificate and invoke that matching rule both
in the TLS protocol and in the Java Script, forming their secure
transaction application.
It wouldn't have to be perfect, just good enough to handle some 95%+ of the
cases as long as the Bank could detect cases where it didn't work. Then the
non-working cases could be fixed by personal customer service.
I see even more use for this matching rule. It could be used in S/MIME so
specify a preferred encryption certificate for replies to a mail. Of course
this matching rule could be used for X.500 directories as well (that's what
it was built for). MY concern here is however not _where_ the certificates
are stored but, how to select 1 of several known certificates regardless of
where they reside.
Comments?
How do wee proceed ?
Could we have any comments from Microsoft and Netscape ?
/Stefan
At 11:15 AM 9/30/98 -0400, David Horvath wrote:
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Alan,
>
>While I personally agree that X.500 provides a mature and feature rich
>core to implement certificate repositories, I am having trouble
>understanding some of your assertions as to why X.500 is the answer to
>so many problems.
>
>It seems to me that the first step for locating certificates in a
>repository is to define the fields in the certificate object that are a
>prerequisite to perform the match. Matching rules are a good start and
>foster the thought process required to provide a well designed solution.
>Once the matching rules are defined, a protocol such as DAP or LDAP V3
>with extensions may be used to exploit the matching rules. In some
>cases, clients may choose not to use the matching rules and retrieve all
>certificates. Perhaps matching rules are not supported by the protocol
>(LDAP V2 or HTTP), therefore the client will collect all the
>certificates and perform the match locally. This may be even more
>efficient than submitting multiple searches with different variations of
>matching rules. It could easily be more efficient to submit one search
>and retrieve 10 certificates, then to submit 3 searches with different
>matching rules each time until the required certificate is found. This
>should be defined by local policies based on performance analysis.
>
>Once the rules for matching certificates are defined ( and I think X.500
>matching rules are an excellent start ) the distribution model can be
>analyzed. This is another case where X.500 may be superior to LDAP, but
>unless you have a well planned global infrastructure neither X.500 or
>LDAP can help with the distribution model.
>
>Dave Horvath
>
>Alan Lloyd wrote:
>>
>>
>> Snip
>>
>> ----------
>> From: pgut001@cs.auckland.ac.nz
>> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>> list@seis.nc-forum.com
>> Sent: 9/29/98 1:01:30 PM
>> Subject: Re: NEW Data type for certificate selection ?
>>
>> Peter - you went through great lenghts to define the problem with
>> relationships between and searching directory based objects and a
>> distributed information issue and then you say:
>> "
>> If anyone has any useful solutions for this (apart from "We should
>> force
>> everyone to use an X.500 directory, that would solve everything" :-) I'd
>> be interested in hearing them.
>>
>> "
>> Oh well - that counts me out. I cannot do solutions - without the
>> solution :-)))
>> regards alan
>>
>> Peter.
>>
>
>
>----------------- SEIS mailing list (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08174 for ietf-pkix-bks; Thu, 8 Oct 1998 12:28:45 -0700 (PDT)
Received: from camel14.mindspring.com (camel14.mindspring.com [207.69.200.64]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08170 for <ietf-pkix@imc.org>; Thu, 8 Oct 1998 12:28:44 -0700 (PDT)
Received: from ns95lap005.nscc.com (pool-207-205-161-29.nwrk.grid.net [207.205.161.29]) by camel14.mindspring.com (8.8.5/8.8.5) with SMTP id PAA09094; Thu, 8 Oct 1998 15:29:06 -0400 (EDT)
From: "Dwight Arthur" <dwightarthur@mindspring.com>
To: "Marc Branchaud" <marcnarc@xcert.com>
Cc: <stefan@aqccurata.se>, <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 8 Oct 1998 15:28:33 -0400
Message-ID: <000501bdf2f1$d8146fa0$1da1cdcf@ns95lap005.nscc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-reply-to: <199810020018.RAA07570@crack.x509.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
In banking applications for the "big market" I do not think that you can
assume that you know the issuing CA or its root. Effective "big market"
applications need to deal with the case where the Relying Party and the
Subject are involved with entirely separate banking entities that subscribe
to the necessary hierarchies, cross-certification communities, etc to
construct a usable chain.
In the US Securities Industry (http://www.sia.com/sirca/) we are seeking
ways to meet this need by the use of certificate policies. Certificates
usable for a particular purpose will be recognizable by the fact that they
reference the required policy OID (or, can map to it through policy
mappings).
There is a definite shortage of client-side and server-side protocols for
completing a certificate chain that's restricted to certificates meeting
policy requirements. I believe that we will be articulating some business
requirements by year end that will stimulate some further work in this area.
--------------------------------------------------
p:(212) 412-8687 Dwight Arthur
f:(212) 908-2345 Managing Director: Systems
b:(917) 646-6682 National Securities Clearing
dwightarthur@mindspring.com 55 Water Street
http://www.nscc.com New York, NY 10041-0082
-----Original Message-----
From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org] On Behalf Of
Marc Branchaud
Sent: Thursday, October 01, 1998 8:18 PM
To: 'ietf-pkix@imc.org '
Subject: Re: NEW Data type for certificate selection ?
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Stefan Santesson <stefan@accurata.se> scrawled:
> =
> Marc,
> =
> If I follow you right you suggest that I use the knowledge from the SSL=
> negotiation to select the proper non-repudiation cert for signing
> transactions. I have thought of that but I have my doubts.
> =
Not necessarily from the SSL handshake itself (although since that's
already there it would be an optimization). But the same kind of mechani=
sm
could be employed, i.e. "here's a list of CAs whose certs I can accept."
> It would be very easy for the server to link knowledge from the link le=
vel
> (SSL) to the Application level (Javascript). The question is if that is=
> possible at the client side, by only using standard components (existin=
g or
> coming).
> =
So, you have this new requirement that nobody's really though of yet, and=
=
you're wondering if existing or planned components will solve your =
problem. Hmmm....
> Suppose the following steps:
> 1) The client browser knows which certificate was used to set up the SS=
L
> channel.
> 2) The server transfer a Javascript to the client in order to create th=
e
> electronic transaction form
> 3) After completing the form the Javascript request a signature on the
> completed form before it's transferred to the server.
> =
> Now even if the non-repudiation certificate and the SSL certificate was=
> issued by the same CA, Will any existing or planned version of any brow=
ser
> have the logic needed to find the right certificate. Not in theory, in
> practice.
> =
In practice, no such Javascript program exists so, practically speaking,
one would have to plan one's Javascript program to have such functionalit=
y.
I'm not familiar with web scripting languages, but I imagine that it's
possible to get the issuer DN of the server's cert and/or all the certs
presented by the server in the SSL handshake. Whether that's existing or=
=
planned, I have no idea.
As for whatever matching rule is required, it will most likely be =
implemented by the applet than the browser. I expect few browser makers =
would be happy to write some kind of generic lookup function to answer =
queries of the form "I need a cert of type <fee> that has a <foo> and =
isn't <foe> but can be <fum>". They'd be much happier to simply expose =
the broswer's certificate store to the applet and let the applet do the =
search.
> If not, then the problem is real and needs a solution. And if a solutio=
n is
> needed I would like to see better selective mechanisms than just Issuer=
DN
> of the CA.
> =
This, I think, is the crucial issue. I'm having trouble seeing why
matching issuer DNs is inadequate. Is it because having a CA per =
application is impractical? Since we're talking about banking here, I =
can't believe that the answer would be "yes" [heck, with a moderate =
hierarchy, the user would only need one cert (from the root CA) to use al=
l =
of the bank's applications].
Please explain to me why saying "I need you to use a cert signed by one o=
f =
these CAs" isn't a good enough solution.
Marc
+------------------------------------------------------------------------=
+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC=
=2E
marcnarc@xcert.com PKI References page: www.xcert.co=
m
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------=
+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNhQbt1rdFXNdDxPlAQEtswL8CZltb8fpsRO5urWESF9Ps4FNVlO9rLui
8+eDmkaf9L7AnY+ljW7ZCYF0p8zk/f6d7xmpia+gxdQBxT6edKYOOTzsr2cwY3Hf
RITSfqoIf4XpQTy/N1lBRhGRLZ0qYYwR
=9JQx
-----END PGP SIGNATURE-----
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06577 for ietf-pkix-bks; Wed, 7 Oct 1998 10:47:55 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06572 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 10:47:51 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id PAA04465; Wed, 7 Oct 1998 15:47:25 -0200
Date: Wed, 7 Oct 1998 15:47:25 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Phillip M Hallam-Baker <pbaker@verisign.com>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, ietf-pkix@imc.org, list@seis.nc-forum.com
Subject: Common misconception #10. was RE: NEW Data type for certificate
In-Reply-To: <000001bdf1fd$05426860$9d07a8c0@pbaker-pc.verisign.com>
Message-ID: <Pine.LNX.4.02.9810071337220.392-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Wed, 7 Oct 1998, Phillip M Hallam-Baker wrote:
> Ed Gerck wrote;
>> The uncertainty reaches a point of almost uselessness, where CAs
>> usually explicitly state in the certification contracts that the CA
>> is exempt of all or almost all responsibility regarding the
>> "certificate", its accuracy and its data. For example:
>
>Taking one part of a contract in isolation is misleading. The VeriSign
>contract has a 'disclaim all implied warranties clause', in other words
>it states that the only warranties provided are those explicitly stated.
>
Phill:
Which are zilch to the cert user, as Verisign's CPS affirm. Of
course, I am not talking about the cert subscriber (that has a
contract with Verisign and a limited warranty) but I am talking about
a general cert user -- who is not privy with that contract, at all,
and which is denied any liability from Verisign.
If I make an offer to the whole world, capable of acceptance without
communication by mere conduct, I can be contractually bound. The
classical example was the 19th century case of the Carbolic Smoke
Ball Company, which advertised an offer of money to any purchaser of
its product (from a retailer, not from the advertising manufacturer)
who contracted influenza after using it. A purchaser sued
successfully for the money.
The same principle governs modern cheque guarantee cards. The bank
promises anyone who accepts a cheque covered by the card that it will
honour the cheque. The bank can be compelled to do so.
So a CA who promises users that its certificates are correct can be
sued by a user.
Or, a CA that promises users that its CRLS are correct can be sued by
a user.
That does not undermine my conclusion, however, because CAs are ever
so careful that neither their certificates nor their CPSs contain any
promise open for acceptance in the way I have described above -- or
in the way that you have described -- or in the way that users
mistakenly may imagine.
It is that fact, rather than the impossibility of such a promise
being binding, that protects the CA.
This point is also contained, albeit more mildly, in my posting on
"If there is a business for CAs" (archives for mcg-talk, cert-talk,
e-carm, etc) and I thank Nicholas Bohm for the legal input on it. It
is also in the Overview paper at certover.pdf.
This is common misconception #10:
CAs have subscribers and users. Users have no contract to
CAs and are specifically excluded from any warranty or liability
by commercial CAs very well-written an public CPSs -- even though
users are called "relying-parties" in such CPSs. However, users
must understand that they are a "relying-party" of their own due
dilligence.
>The explicitly stated warranty consists of NetSure insurance in a sum
>that varies from $1,000 to $100,000 depending on the certificate
>category. If necessary higher sums could be agreed. This is real
>insurance underwritten by a leading insurer.
The NetSure insurance only applies to Verisign's subscribers -- who
pay for the insurance and are so insured ;-)
It does NOT apply to the world at large, the user, who is not privy
to the contract between Verisign and the subscriber. You would need
the whole world to sign and pay into that NetSure policy in order to
make it begin to be useful to users.. not a bad perspective for some,
but unlikely.
Further, just to make it clear why you cannot fight open risks with
insurance, suppose that 1,000 users have problems with just 1 cert
for ACME, issued by Verisign and insured by NetSure. I ask:
- Who is laible for what?
- Who should each of the 1,000 users sue: ACME, Verisign, the insurer
or, all?
- How much is each of the 1,000 users entitled to claim under
NetSure: the full certificate's insurance for each (thus, suppose,
1,000 x $1,000) or a rate of the total insurance (say $1,000 divided
by 1,000)?
- Who pays what NetSure does not pay but each 1,000 users will
certainly claim?
Thus, it is not misleading to single out that part, since that part
is what negates the user's rigths.
But, I am sure we all know this. Especially the guys that calculated
the NetSure insurance coverage and its exceptions, as well as the
guys that wrote Verisign's CPS.
So -- why the fuss? Perhaps, it is intersting to view common
misconception #10 under a different light. It was very well stated by
a Harvard-graduated lawyer, who declared:
> CAs and PKI rely on that same sort of systems trust. You trust
> that the CA, as an expert system, will do the identify
> verification, certification revocation, etc. properly. It's
> analogous to when you trust that the architect/civil engineer who
> designed your house (and who are part of a system of education,
> licensing, and bureaucratic approval) did it properly and don't
> worry about your house falling down.
To which I publicly responded, with:
The analogy you point out does NOT exist and this is a common
misconception. A relying-party (aka, the cert user) cannot rely upon
the CA as a house owner relies upon the expert engineer he hired,
for several reasons.
First, because there is no contract between a user and a CA while
the engineer was hired by the house owner or, in other words,
because the person who pays for the certificate is not the one who
relies on it. Second, because it is generally accepted that Internet
traffic is subject to so many possible sources of disturbance
(willingful or by chance) in so many possible routes that a CA
cannot present a guarantee of correct results, just of correct
methods -- which is also law doctrine for consultation work and data
processing in general. Third, because a certificate is an open-ended
risk. Fourth, because certificates cannot really be revoked, and so
represent an open assignment. For a list of 16+ causes, you can
check http://www.mcg.org.br/cert.htm
One other cause is that Verisign denies warranties to the public at
large -- as commented at the top.
Clearly, for any CA the majority of relationships is, albeit
indirectly, defined by CA/user. The number of CA/subscriber cases is
much smaller. This highlights the importance of this issue, since
users are also the ones that must primarily weigh potential losses.
Further, it is also clear that users may hold the subscribers to be
responsible. However, if the subscriber publicly denies any liability
to anyone in the world, then a user may also have only its own due
dilligence to rely upon.
>
>
>> As publicly declared by Phillip Hallam-Baker, a
>> Verisign consultant, not only are the CPSs indeed different and
>> self-made by each CA but they are not designed to be audited, either:
>> "There is not as yet a defined standard for CA practices against
>> which a company may be audited. In effect each company states their
>> own practices in their Certificate Practices Statement (CPS). The CPS
>> is not a document designed for auditing use however. It describes a
>> 'specification', it does not describe details which may be checked by
>> a third party in a systematic manner."
>
>Here you are quoting me out of context. This was in the context of
>your argument concerning the use of a standardized audit statement.
I provided the full reference, which was in hypertext under your
name and as reference [Bak98] in http://www.mcg.org.br/certover.pdf.
As referenced in: (long URL)
http://www.mcg.org.br/cgi-bin/lwg-mcg/MCG-TALK/archives/mcg/date/article-379.html
and anyone could search the archives for the full thread.
>
>Taking off the cuff statements out of mailing list exchanges and
>quoting them verbatim offline without checking the context seems
>somewhat odd behaviour.
As above, that is not the case. The reader can go to the original
thread and check the full contexts of all your messages -- which IMO
will not change anything in that isolated paragraph. Now, if you want
to imply that public mailing lists are not useful to provide
meaningful information without further checking, then I must agree as
we see how much misinformation is oftentimes put out through these
channels. Which we must oftentimes weed out and just get what seems
to be fitting to our own intelligence. Perhaps, this posting also
exemplifies that.
However, if you feel that you can issue a more accurate statement,
then I will be pleased to change them in all the certover.pdf,
certover.ps and cert.htm.htm files -- which have BTW been downloaded
more than 55,000 times in the last year and are cited in some books
and thesis on the subject.
>
>I was arguing that before you could use 'audit statements' in the
>manner you envisioned there had to be agreement on audit standards.
>Work on audit standards for a CPS is taking place. It is thus entirely
>misleading to take a specific objection to a specific use of auditing
>for a specirfic purpose and conclude that no CPS can ever be audited.
>
But, not the way they are -- and that was what you yourself wrote in
the quote above. Now, I ask: what does a subscriber buy from Verisign
today -- a cert issued acording to today's CPS that we both agree
cannot be audited or, based on a future Verisign's CPS? And, I also
ask: What should we discuss -- today's CPS risks or risks of future
CPSs we do not know of?
>
>Saying that a CPS issued by BongoCert Inc. may not necessarily prove
>to be auditable is not the same as saying that 'A CPS is not designed
>to be audited'. In fact a CPS can be designed to be auditable and
>the ability to conduct an audit may be considered a quality differentiator
>between CPSs.
>
>Rather than 'does not describe' I would instead restate this as
>'does not necessarily describe'.
>
Let me comment by parts. The relevant section of your quote began
with:
>>"In effect each company states their own practices in their
>> Certificate Practices Statement (CPS)."
This means that unless we believe in serendipity as a valid work tool
then we should expect that CPSs from different CAs do not
interoperate. This reflects BTW a basic flaw of laissez-faire
certification systems such as X.509 and PKIX, exactly where we would
need interoperation -- the semantic rules that certificate issuance
must obey are not defined by the standard but ad hoc by each company.
Who cares that the syntatic rules are clear (ahem...) in the
standard? Is that all?
>>"The CPS is not a document designed for auditing use however."
Clear -- like a car is not designed to fly, and does not fly. I also
think that if a CPS would allow what it is not designed to do (as you
seem to imply in your comment above) then that is a security flaw,
by itself no? I mean, what other unthought-of properties could one
spelunk from it? Will such "easter eggs" be good or bad for me? Meet
you in court, you say ....
>>"It describes a 'specification', it does not describe details which
>>may be checked by a third party in a systematic manner."
It says "it does not describe" and you want to change to "it does not
necessarily describe". Fine. However, are we not again relying on
serendipity? And, as Descartes affirmed: "Doubt until you have proof"
means that I can surely doubt such statement will ever support the
exsitence of even ONE auditable CPS, right?
>
>The problem I believe I was having with your argument was that the
>invocation of 'auditors' appeared to be used as a panacea as if the
>statement 'I have been audited' translated to the conclusion 'He is
>trustworthy' without taking account of how the audit was performed,
>who performed it and what the objective of the audit was.
>
I do not think that can be deduced from any of my postings or
articles. Nor inferred. Should I be bound by a word I did not say?
On the contrary, my posting considerably stressed that any reliance
derived from trust must depend on the exact underlying terms and
rules that support such trust:
Thus, in legal reliance terms, one trusts the name confirmation
procedures of the CA during certificate reliance, but one cannot
rely upon the name for other than its value as a representation of
the CA's authentication management act expressed in the CA's own
terms and rules.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
--- Meta-certificate Group Member -- http://www.mcg.org.br ---
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04781 for ietf-pkix-bks; Wed, 7 Oct 1998 07:16:35 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04777 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 07:16:34 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA00874; Wed, 7 Oct 1998 07:13:53 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA11347; Wed, 7 Oct 1998 07:15:46 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ed Gerck" <egerck@laser.cps.softex.br>, "Anders Rundgren" <anders.rundgren@jaybis.com>
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
Date: Wed, 7 Oct 1998 10:16:04 -0400
Message-ID: <000001bdf1fd$05426860$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <Pine.LNX.4.02.9810020308410.25643-100000@laser.cps.softex.br>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> The uncertainty reaches a point of almost uselessness, where CAs
> usually explicitly state in the certification contracts that the CA
> is exempt of all or almost all responsibility regarding the
> "certificate", its accuracy and its data. For example:
Taking one part of a contract in isolation is misleading. The VeriSign
contract has a 'disclaim all implied warranties clause', in other words
it states that the only warranties provided are those explicitly stated.
The explicitly stated warranty consists of NetSure insurance in a sum
that varies from $1,000 to $100,000 depending on the certificate
category. If necessary higher sums could be agreed. This is real
insurance underwritten by a leading insurer.
> As publicly declared by Phillip Hallam-Baker, a
> Verisign consultant, not only are the CPSs indeed different and
> self-made by each CA but they are not designed to be audited, either:
> "There is not as yet a defined standard for CA practices against
> which a company may be audited. In effect each company states their
> own practices in their Certificate Practices Statement (CPS). The CPS
> is not a document designed for auditing use however. It describes a
> 'specification', it does not describe details which may be checked by
> a third party in a systematic manner."
Here you are quoting me out of context. This was in the context of
your argument concerning the use of a standardized audit statement.
Taking off the cuff statements out of mailing list exchanges and
quoting them verbatim offline without checking the context seems
somewhat odd behaviour.
I was arguing that before you could use 'audit statements' in the
manner you envisioned there had to be agreement on audit standards.
Work on audit standards for a CPS is taking place. It is thus entirely
misleading to take a specific objection to a specific use of auditing
for a specirfic purpose and conclude that no CPS can ever be audited.
Saying that a CPS issued by BongoCert Inc. may not necessarily prove
to be auditable is not the same as saying that 'A CPS is not designed
to be audited'. In fact a CPS can be designed to be auditable and
the ability to conduct an audit may be considered a quality differentiator
between CPSs.
Rather than 'does not describe' I would instead restate this as
'does not necessarily describe'.
The problem I believe I was having with your argument was that the
invocation of 'auditors' appeared to be used as a panacea as if the
statement 'I have been audited' translated to the conclusion 'He is
trustworthy' without taking account of how the audit was performed,
who performed it and what the objective of the audit was.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA03754 for ietf-pkix-bks; Wed, 7 Oct 1998 04:05:57 -0700 (PDT)
Received: from noms.capgemini.fr (noms.capgemini.fr [194.3.247.254]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA03750 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 04:05:56 -0700 (PDT)
From: cgilmach@capgemini.es
Received: from prenoms.capgemini.fr (capmail [194.2.91.200]) by noms.capgemini.fr (8.8.7/8.8.7) with ESMTP id NAA05297 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 13:09:47 +0200 (MET DST)
Received: from dionisio.capgemini.es ([194.75.0.3] (may be forged)) by prenoms.capgemini.fr (8.8.6/8.8.6) with SMTP id NAA25249 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 13:05:42 +0200 (MET DST)
Received: by dionisio.capgemini.es(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id C1256696.003C353B ; Wed, 7 Oct 1998 12:57:37 +0200
X-Lotus-FromDomain: CAP
To: ietf-pkix@imc.org
Message-ID: <C1256696.003BC3C9.00@dionisio.capgemini.es>
Date: Wed, 7 Oct 1998 13:04:40 +0200
Subject: Re: DNS Name definition
Mime-Version: 1.0
Content-type: multipart/mixed; Boundary="0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y"
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
--0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
Jacques Lebastard <Jacques.Lebastard@bull.net> con fecha 10/06/98 05:37=
:42
PM
Destinatarios: PKI Mailing list <ietf-pkix@imc.org>
CC: (cci: Carlos Javier Gil Mach=EDn/BCN/CAP)
Asunto: DNS Name definition
=
--0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
I'm looking for the Standard document defining the format
of a DNS name. Does such an Internet RFC exist ?
--
Jacques LEBASTARD mailto:Jacques.Lebastard@bull.net
BULL SA - ISM AccessMaster http://www.openmaster.com/
Rue Jean Jaures - F3-2G-03 Tel: +33 1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 1 30 80 77 99
The RFCs 1034 and 1035 define the DNS format. There are several updates of
these documents; I think the lastest one is the 2038.
You can look at the RFC index at:
http://info.internet.isi.edu:80/in-notes/rfc/rfc-index.txt
Yours,
Carlos Gil.
----------------------------------------------------------------------
Carlos J. Gil Machin <cgilmach@capgemini.es>
Telecommunications Engineer
Cap Gemini Spain Tel. + 34 93 495 86 00
Avda. Diagonal, 640, 4th. Fax. + 34 93 405 90 54
08006 Barcelona SPAIN WWW: http://www.capgemini.es
PGP Fingerprint: 86BE 4FDF F2A3 A39D CCDD 6936 0E4E A79C 0E11 B7F0
----------------------------------------------------------------------
--0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06151 for ietf-pkix-bks; Tue, 6 Oct 1998 08:39:02 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06144 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 08:38:52 -0700 (PDT)
Received: from bahamas.frcl.bull.fr (bahamas.frcl.bull.fr [129.182.22.122]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with SMTP id RAA13327 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 17:37:30 +0200
Received: from localhost by bahamas.frcl.bull.fr (AIX 4.1/UCB 5.64/4.03) id AA21032; Tue, 6 Oct 1998 17:37:42 +0200
Message-Id: <361A3946.3D352C33@bull.net>
Date: Tue, 06 Oct 1998 17:37:42 +0200
From: Jacques Lebastard <Jacques.Lebastard@bull.net>
Organization: BULL SA - ISM/AccessMaster
X-Mailer: Mozilla 4.03 [en] (X11; I; AIX 4.1)
Mime-Version: 1.0
To: PKI Mailing list <ietf-pkix@imc.org>
Subject: DNS Name definition
References: <199810061501.IAA05512@mail.proper.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I'm looking for the Standard document defining the format
of a DNS name. Does such an Internet RFC exist ?
--
Jacques LEBASTARD mailto:Jacques.Lebastard@bull.net
BULL SA - ISM AccessMaster http://www.openmaster.com/
Rue Jean Jaures - F3-2G-03 Tel: +33 1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 1 30 80 77 99
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05516 for ietf-pkix-bks; Tue, 6 Oct 1998 08:01:23 -0700 (PDT)
Received: from aum.proper.com (ts004d05.sea-wa.concentric.net [209.31.208.161]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA05512 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 08:01:21 -0700 (PDT)
Message-Id: <199810061501.IAA05512@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Tue, 06 Oct 1998 08:01:35 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PKIX: DNS name constraint in Cert. Profile (Sept. 23, 1998)
In-Reply-To: <199810060119.LAA14517@cdn-mail.dn.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
At 11:17 AM 10/6/98 +1000, Manger, James wrote:
>Either require a leading period in the constraint, e.g. ".foo.bar.com" (c.f.
>URI constraint); or replace the "adding to the left" sentence with "Any
>sub-domain satisfies the constraint.". Change "foo1.bar.com" to
>"bigfoo.bar.com" as an example that does not satisfy the constraint.
Extremely good point, and I believe that the latter ("any subdomain...")
should be used. If this clarification can be made before the RFC is issued,
it should be; otherwise, we should probably be starting a "clarifications"
draft and this should be in it.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA03851 for ietf-pkix-bks; Tue, 6 Oct 1998 05:27:23 -0700 (PDT)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA03847 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 05:27:21 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id OAA05234 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 14:27:32 +0200 (CEST)
Received: from stefans (t4o68p29.telia.com [62.20.139.149]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA28207 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 14:27:26 +0200 (CEST)
Message-Id: <3.0.32.19981006142344.00a3a5e0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 06 Oct 1998 14:24:25 +0200
To: "'pkix'" <ietf-pkix@imc.org>
From: Stefan Santesson <stefan@accurata.se>
Subject: Summary: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA03848
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
I have been asked by some private mailers to sum up this thread.
The problem originally addressed was:
Experiences until today has shown that successful services over Internet
allows users to access these services through their standard internet
software components, in particular e-mail clients and web browsers.
As soon as a service require a custom designed plug-in module to be
installed at the clients computer, a threshold mechanism is introduced that
dramatically limits the probability of success.
Unfortunately X.509 PKI dependent services are many times faced with this
problem. Today many browsers and e-mail clients have to be supplemented
with plug-ins to handle directory access, certificate selection,
non-repudiation services, smart card access etc. Many of these problems
will be solved by emerging protocols and standards (like directory access
and API to cryptographic tokens). However the certificate select problem
will continue to be at least partially unsolved, unless something is done
about it.
----
So one of the most important obstacles to remove before PKI-based security
can be introduced in a large scale, is the problem of certificate
selection, i.e. to solve how one out of several certificates is selected by
standard mechanisms in standard client products without having to rely on
the end users ability to pick the right certificate.
We have seen that on the "link level" there is a solution (in SSL and TLS).
Here the server can communicate to the client a list of CA:s accepted by
the server. Except from this it is total darkness.
At the application level there is no solutions. Java script may be used to
create data forms to be signed by the client, but the process to select a
proper user certificate is not covered.
The possible solution debated here was to define a general select mechanism
in the form of a defined data type, such as the X.500 match rule. This
mechanism could then be introduced into link level protocols as well as
application level command interpreters.
I end this debate with my conclusion that this problem space remains to be
solved. As working for some potential providers of public PKI-based
services over Internet I can only encourage any effort aimed at solving
this in a near future.
/Stefan Santesson
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA11378 for ietf-pkix-bks; Mon, 5 Oct 1998 18:40:10 -0700 (PDT)
Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA11374 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 18:40:07 -0700 (PDT)
Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id LAA11437 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 11:39:28 +1000 (EST)
Received: from mail-gw.fwall.telstra.com.au(192.148.147.16) via SMTP by mail.telstra.com.au, id smtpd003254; Tue Oct 6 11:20:19 1998
Received: (from uucp@localhost) by mail-gw.fwall.telstra.com.au (8.8.2/8.6.9) id LAA04501 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 11:20:16 +1000 (EST)
Received: from cdn-mail.dn.itg.telecom.com.au(144.135.109.134) via SMTP by mail-gw.fwall.telstra.com.au, id smtpd004142; Tue Oct 6 11:19:49 1998
Received: from qbpde-nm03.corpmail.telstra.com.au (qbpde-nm03.corpmail.telstra.com.au [172.51.17.214]) by cdn-mail.dn.itg.telecom.com.au (8.8.2/8.6.9) with ESMTP id LAA14517 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 11:19:47 +1000 (EST)
Message-Id: <199810060119.LAA14517@cdn-mail.dn.itg.telecom.com.au>
Received: by qbpde-nm03.corpmail.telstra.com.au with Internet Mail Service (5.5.2232.9) id <4K0RA11H>; Tue, 6 Oct 1998 11:19:47 +1000
From: "Manger, James" <JManger@vtrlmel1.telstra.com.au>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: PKIX: DNS name constraint in Cert. Profile (Sept. 23, 1998)
Date: Tue, 6 Oct 1998 11:17:32 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
<draft-ietf-pkix-ipki-part1-11.txt>
At a quick glance the latest draft looks good. The Name Constraints clause
(4.2.1.11) has been tightened up for URIs but the same is needed for DNS
restrictions. The relevant text is quoted below. A constraint
"foo.bar.com" should NOT be satisfied by "bigfoo.bar.com", yet this is
constructed "by simply adding to the left hand side" so it does satisfy the
constraint according to the draft.
Either require a leading period in the constraint, e.g. ".foo.bar.com" (c.f.
URI constraint); or replace the "adding to the left" sentence with "Any
sub-domain satisfies the constraint.". Change "foo1.bar.com" to
"bigfoo.bar.com" as an example that does not satisfy the constraint.
-----
INTERNET DRAFT September 23, 1998
4.2.1.11 Name Constraints
...
DNS name restrictions are expressed as foo.bar.com. Any DNS name that
can be constructed by simply adding to the left hand side of the name
satisfies the name constraint. For example, www.foo.bar.com would
satisfy the constraint but foo1.bar.com would not.
...
Housley, Ford, Polk, & Solo [Page 36]
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07872 for ietf-pkix-bks; Mon, 5 Oct 1998 10:00:02 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07868 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 10:00:01 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id JAA21407; Mon, 5 Oct 1998 09:56:41 -0700 (PDT)
Message-Id: <3.0.3.32.19981005095524.00b025b0@poptop.llnl.gov>
X-Sender: e048786@poptop.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 05 Oct 1998 09:55:24 -0700
To: =?iso-8859-1?Q?Sievänen?= Markku <markku.sievanen@setec.fi>, Anders Rundgren <anders.rundgren@jaybis.com>
From: Tony Bartoletti <azb@llnl.gov>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'pkix'" <ietf-pkix@imc.org>
In-Reply-To: <514651EC9177D111ABE700805F0D75DC17B27B@eemeli.setec.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
Sorry I was not clear. What I meant was that I send an (electronic) check
to whom I _think_ is Acme Hardware on Third Street, when in fact some
miscreant has posed as such to the CA/Directory Service in order to get
a fraudulent certificate or listing.
In such a case, I relied upon the CA/Directory to be authoritative. But
when they get hoodwinked (though they followed their own stated procedures)
I am left with little recourse. I may as well be hoodwinked directly, and
leave out the middleman;)
___tony___
Tony Bartoletti LL
SPI-NET GURU LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07030 for ietf-pkix-bks; Mon, 5 Oct 1998 08:03:07 -0700 (PDT)
Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07026 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 08:02:59 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.0.1461.28) id <4JBWNXD0>; Mon, 5 Oct 1998 17:09:19 +0200
Message-ID: <8160937F4F4CD111A93E00805FC17529A59FD5@ntsiaexch.office>
From: Santoni Adriano <santoni@sia.it>
To: "'Robert Zuccherato'" <robert.zuccherato@entrust.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: R: Time Stamp and Notary Drafts
Date: Mon, 5 Oct 1998 17:09:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1461.28)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA07027
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Thank you for you reply.
So, where you say "the nonce in the token must be present if the nonce is
present in the request. However, the nonce is mandatory in the request.
Thus, using the present protocol, the nonce is mandatory" ...you imply that
whatever value the requestor puts in the nonce field of his request, the TSA
must copy that same value in the nonce field of the response (token), right?
If things are going to stay that way, I'd suggest to issue a new draft
(well, when the time is right for doing that) with the field "nonce" in both
the TimeStampReq and the TimeStampToken structures marked OPTIONAL. The
criterium that "if the requestor sends it, the responder must also send it"
can be explained, and declared REQUIRED, in the text.
The reason for having a repository URL in the response would be that of
binding the TSA to mantain an available online repository of all timestamp
responses ever generated (or, well, a large enough sliding window of them),
so that people may retrieve them at will in case they ever need. After all,
a timestamp response is much like a certificate (it just do not bind people
to keys but hashes to times), and a CA is suposed to have such a repository.
However, I agree that this concept needs more thinking (and, yes, the
tsaFreeData would be the obvious place to put that sort of information,
lacking other possibilities).
Regards.
Adriano
> -----Messaggio originale-----
> Da: Robert Zuccherato [SMTP:robert.zuccherato@entrust.com]
> Inviato: lunedì 5 ottobre 1998 15.17
> A: 'Santoni Adriano'
> Cc: 'ietf-pkix@imc.org'
> Oggetto: RE: Time Stamp and Notary Drafts
>
> Thanks for your comments. My replies are embedded below.
>
> > ----------
> > From: Santoni Adriano[SMTP:santoni@sia.it]
> > Sent: Monday, October 05, 1998 5:15 AM
> > To: 'Robert Zuccherato'
> > Cc: 'ietf-pkix@imc.org'
> > Subject: R: Time Stamp and Notary Drafts
> >
> > Regarding the nonce field in timestamp requests and responses: the
> > draft
> > says (at page X) that the TSA must include the same nonce value the
> > requestor specified in his request, in case he did. But how is the TSA
> > going
> > to determine that the requestor did specify a nonne value? I can
> > imagine two
> > possible answers: either the nonce field is OPTIONAL in the
> > TimeStampReq,
> > too (and not only in the response), or a "blank" value is established
> > by
> > convention (e.g. zero).
> >
> I had a request to include a second type of time stamp request. This
> lower quality of service request would be http based and would just
> return a "blank" token without a message imprint or nonce. Basically,
> it would just be a signature on the current time. This would be a lower
> quality of service because without a trusted source of time, one could
> not verify that the returned token was "fresh". People would be able to
> just go to a web site and pick up one of these tokens.
>
> I am in the process of adding this option and have included the nonce in
> the token as OPTIONAL to allow for it, but haven't fully described it
> yet. If people want this service, I will include it. Otherwise, I
> won't and the option on the nonce will be removed.
>
> Notice however that the way things are presently described, the nonce in
> the token must be present if the nonce is present in the request.
> However, the nonce is mandatory in the request. Thus, using the present
> protocol, the nonce is mandatory.
>
> > Regarding the timestamp response (token): would not it be useful to
> > include
> > a pointer to an on-line repository, supposed to be run by the TSA,
> > were all
> > tokens are held and made available to everyone for browsing and
> > downloading?
> >
> I am not entirely sure of the usefulness of this service. How would
> such a repository be used? Could the tsaFreeData field be used for this
> pointer?
>
> > Remarks. The draft should make use, IMO, of the usual keywords (in
> > all-uppercase) indicating requirement levels (MUST, MUST NOT, SHOULD,
> > etc.)
> > as per RFC 2119.
> >
> Certainly.
>
> > A more elaborate explanation of how to intepret the
> > reqPolicy field and some real-world scenarios would also be helpful.
> >
> I agree. There is a need for a document describing time stamp policy
> and time stamp practice statements. These are all important issues.
> However, in this document we are only trying to describe the protocol
> that is to be used between these entities. Discussion of actual policy
> issues is outside of its scope.
>
> Robert.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06884 for ietf-pkix-bks; Mon, 5 Oct 1998 07:45:08 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06880 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 07:45:07 -0700 (PDT)
Received: from [128.33.238.65] (TC065.BBN.COM [128.33.238.65]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id KAA18982 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 10:45:21 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04011701b23e8bad21d9@[128.33.238.58]>
Date: Mon, 5 Oct 1998 10:45:18 -0400
To: ietf-pkix@imc.org
From: Stephen Kent <kent@bbn.com>
Subject: CFP relevant to PKIX
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Call for Papers
IEEE Journal on Selected Areas in Communications (JSAC)
Special Issue on Network Security
Publication date: January, 2000
Recent years have seen great advances in the availability of security
technology for network users. The advances in standardization and
implementation are accompanied by continuing activity in the research
community to tackle the next generation of problems and to improve on
prior technology.
This special issue of JSAC will be devoted to recent research results
that describe or forecast significant changes in the feasibility of
delivering security solutions (such as major improvements in
cryptographic efficiency), or describe progress in areas that have
been especially difficult, or are relevant to newer technologies, such
as optical or mobile wireless communication. Of special interest are
papers that relate their results to use on the Internet today
or to use on next generation networks.
Papers are solicited in the following areas:
Cryptography-based network systems, such as
secure private networks
transactional security
Public-key infrastructures
Applying new cryptographic methods to network communication
New cryptographic protocols supporting secure network systems
Anonymous communication
Recent cryptographic theory advances
Optical network security
Mobile wireless network security
Formal analysis of network security systems
Trends in network-based attacks
Secure group communication
Policy expression and enforcement
Papers in strongly related areas, especially those involving novel
technologies, are also encouraged.
The guest editors for this issue are
Hilarie Orman, University of Arizona, Department of Computer Science
Ueli Maurer, Swiss Federal Institue of Technology (ETH)
Stephen Kent, BBN Technologies
Stephen Bellovin, AT&T Laboratories
The schedule for authors is as follows:
February 5, 1999, manuscripts are due
May 3, 1999, notification of acceptance
August 5, 1999, final manuscripts are due
Manuscripts to be considered for submission should be sent by email to
Hilarie Orman (ho@cs.arizona.edu) by February 5, 1999. The manuscripts
must be in Postscript, viewable in ghostscript. The manuscripts must
be in Postscript, viewable in ghostscript, or six copies can be sent
by mail; contact Hilarie Orman well prior to the deadline for the
mailing address. Please note the IEEE formatting requirements;
information for authors can be found at:
http://gump.bellcore.com:5000/Guidelines/info.html The JSAC home page
is at http://gump.bellcore.com:5000/.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06779 for ietf-pkix-bks; Mon, 5 Oct 1998 07:24:36 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA06775 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 07:24:34 -0700 (PDT)
Received: id KAA26081; Mon, 5 Oct 1998 10:20:30 -0400
Received: by gateway id <4CGY9Q32>; Mon, 5 Oct 1998 10:18:29 -0400
Message-ID: <D789F71F24B4D111955D00A0C99B4F500139B06C@sothmxs01.entrust.com>
From: Robert Zuccherato <robert.zuccherato@entrust.com>
To: "'Santoni Adriano'" <santoni@sia.it>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Time Stamp and Notary Drafts
Date: Mon, 5 Oct 1998 10:16:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Thanks for your comments. My replies are embedded below.
> ----------
> From: Santoni Adriano[SMTP:santoni@sia.it]
> Sent: Monday, October 05, 1998 5:15 AM
> To: 'Robert Zuccherato'
> Cc: 'ietf-pkix@imc.org'
> Subject: R: Time Stamp and Notary Drafts
>
> Regarding the nonce field in timestamp requests and responses: the
> draft
> says (at page X) that the TSA must include the same nonce value the
> requestor specified in his request, in case he did. But how is the TSA
> going
> to determine that the requestor did specify a nonne value? I can
> imagine two
> possible answers: either the nonce field is OPTIONAL in the
> TimeStampReq,
> too (and not only in the response), or a "blank" value is established
> by
> convention (e.g. zero).
>
I had a request to include a second type of time stamp request. This
lower quality of service request would be http based and would just
return a "blank" token without a message imprint or nonce. Basically,
it would just be a signature on the current time. This would be a lower
quality of service because without a trusted source of time, one could
not verify that the returned token was "fresh". People would be able to
just go to a web site and pick up one of these tokens.
I am in the process of adding this option and have included the nonce in
the token as OPTIONAL to allow for it, but haven't fully described it
yet. If people want this service, I will include it. Otherwise, I
won't and the option on the nonce will be removed.
Notice however that the way things are presently described, the nonce in
the token must be present if the nonce is present in the request.
However, the nonce is mandatory in the request. Thus, using the present
protocol, the nonce is mandatory.
> Regarding the timestamp response (token): would not it be useful to
> include
> a pointer to an on-line repository, supposed to be run by the TSA,
> were all
> tokens are held and made available to everyone for browsing and
> downloading?
>
I am not entirely sure of the usefulness of this service. How would
such a repository be used? Could the tsaFreeData field be used for this
pointer?
> Remarks. The draft should make use, IMO, of the usual keywords (in
> all-uppercase) indicating requirement levels (MUST, MUST NOT, SHOULD,
> etc.)
> as per RFC 2119.
>
Certainly.
> A more elaborate explanation of how to intepret the
> reqPolicy field and some real-world scenarios would also be helpful.
>
I agree. There is a need for a document describing time stamp policy
and time stamp practice statements. These are all important issues.
However, in this document we are only trying to describe the protocol
that is to be used between these entities. Discussion of actual policy
issues is outside of its scope.
Robert.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA03316 for ietf-pkix-bks; Mon, 5 Oct 1998 02:09:55 -0700 (PDT)
Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA03312 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 02:09:45 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.0.1461.28) id <4JBWNWYQ>; Mon, 5 Oct 1998 11:15:49 +0200
Message-ID: <8160937F4F4CD111A93E00805FC17529A59FCB@ntsiaexch.office>
From: Santoni Adriano <santoni@sia.it>
To: "'Robert Zuccherato'" <robert.zuccherato@entrust.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: R: Time Stamp and Notary Drafts
Date: Mon, 5 Oct 1998 11:15:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1461.28)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA03313
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Yes, I have a couple of questions and a few remarks.
Regarding the nonce field in timestamp requests and responses: the draft
says (at page X) that the TSA must include the same nonce value the
requestor specified in his request, in case he did. But how is the TSA going
to determine that the requestor did specify a nonne value? I can imagine two
possible answers: either the nonce field is OPTIONAL in the TimeStampReq,
too (and not only in the response), or a "blank" value is established by
convention (e.g. zero).
Regarding the timestamp response (token): would not it be useful to include
a pointer to an on-line repository, supposed to be run by the TSA, were all
tokens are held and made available to everyone for browsing and downloading?
Remarks. The draft should make use, IMO, of the usual keywords (in
all-uppercase) indicating requirement levels (MUST, MUST NOT, SHOULD, etc.)
as per RFC 2119. A more elaborate explanation of how to intepret the
reqPolicy field and some real-world scenarios would also be helpful.
Regards.
Adriano Santoni
__________________________________________
Ing. Adriano Santoni
Direzione Rete - Servizio Progettazione Rete Logica
Società Interbancaria per l'Automazione - SIA S.p.A.
Viale Certosa, 218 - I-20156 Milano
Vox: +39 2 3005 277
Fax: +39 2 38003333
Plain email: santoni@sia.it
S/MIME email: asantoni@sia.it
Website: http://www.sia.it
> -----Messaggio originale-----
> Da: Robert Zuccherato [SMTP:robert.zuccherato@entrust.com]
> Inviato: lunedì 28 settembre 1998 18.37
> A: 'ietf-pkix@imc.org'
> Oggetto: Time Stamp and Notary Drafts
>
> As some of you may have noticed, I have submitted the latest versions of
> our
> Time Stamp and Data Certification Server drafts as PKIX Internet Drafts,
> in
> accordance with the decisions made in Chicago. These drafts are based on
> the drafts that we have been submitting independently on these topics for
> some time now and reporting to PKIX on their progress.
>
> The Time Stamp Draft describes a protocol in which a trusted Time Stamp
> Authority provides evidence that a message existed at a particular point
> in
> time. It is available at:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt
>
> The Data Certification Server provides "notary" type services (signature
> validation, certificate path validation) in support of non-repudiation.
> This draft is available at:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt
>
> As usual, comments are welcome.
>
> Robert Zuccherato.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA29023 for ietf-pkix-bks; Sun, 4 Oct 1998 23:38:50 -0700 (PDT)
Received: from setec.fi (smtp.setec.fi [195.236.90.20]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA29015 for <ietf-pkix@imc.org>; Sun, 4 Oct 1998 23:38:48 -0700 (PDT)
Received: (qmail 11492 invoked by uid 65534); 5 Oct 1998 06:31:59 -0000
Received: from eemeli.setec.fi (10.1.1.1) by smtp.setec.fi with SMTP; 5 Oct 1998 06:31:59 -0000
Received: from eemeli.setec.fi (unverified [127.0.0.1]) by 127.0.0.1 (Data Fellows SMTPRS 2.04) with ESMTP id <B0000024976@127.0.0.1>; Mon, 05 Oct 1998 09:37:47 +0200
Received: by eemeli.setec.fi with Internet Mail Service (5.0.1458.49) id <4DGYKNMK>; Mon, 5 Oct 1998 09:37:47 +0200
Message-Id: <514651EC9177D111ABE700805F0D75DC17B27B@eemeli.setec.fi>
From: =?iso-8859-1?Q?Siev=E4nen_Markku?= <markku.sievanen@setec.fi>
To: "'Tony Bartoletti'" <azb@llnl.gov>
Cc: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 5 Oct 1998 09:37:46 +0200
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA29018
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi!
Tony, don't mix the diffrent roles of PKI. CA is not responsible, if
your's "Acme Hardware" doesn't
return to You anything. CA is only responsible that there is a "secure
path" to validate the check, which is digitally signed. And in that role
CA and PKI infra works fine, if it is build up correctly with building
blocks like smart cards, certicate policies and so on.
Of course, in addition to that, You need "specific security protocols"
to different application sectors, like
e-commerce, to make the whole system work. These protocols might use
Notary Services to make sure,
that "You really get what you paid".
MaSi
> -----Original Message-----
> From: Tony Bartoletti [SMTP:azb@llnl.gov]
> Sent: Friday, October 02, 1998 9:00 PM
> To: Anders Rundgren; 'Ed Gerck'
> Cc: 'ietf-pkixÉimc.org '
> Subject: RE: NEW Data type for certificate selection ?
>
> At 07:59 AM 10/2/98 +0200, Anders Rundgren wrote:
> >Ed,
> >>The first usual misconception here is when people confuse trust in a
> >>certificate to trust in a certificate's contents -- too quite
> >>different animals. In fact, the first is directly defined under
> X.509
> >>or PKIX but the second depends on the CPS, which depends on each CA,
> >>which systematically negate it.
> >
> >Systematically negate it?
> >
> >Sorry, I fail to understand why it is technically, legally, etc.
> impossible to create trusted
> >CA services that issues certificates with contents that can actually
> be used. But as I said earlier,
> >Swedes are probably morons as we just do it anyway in spite of the
> fact that it does not work :-)
> >
> >Anders
>
> Anders,
>
> Current certification systems do "work", much as an ordinary telephone
> directory works. The analogy would be closer if the publisher of the
> phone book digitally signed each entry.
>
> The phone book works because most people are honest and want to help
> make things work. But I have no real way of knowing that the entry
> for "Acme Hardware, Third Street" is indeed a hardware store, or can
> be trusted to perform as I might expect it to.
>
> People expect a digital-sig PKI to somehow automatically provide the
> root of trust that is needed. Indeed, the terminology "root key",
> "root CA" suggests as much. But unless a third party can be relied
> upon to reimburse me for my losses, when I send a digital check to
> "Acme Hardware" and recieve nothing in return, this third party is
> really not much more than a telephone directory.
>
> We want more, and need more from PK technology. The emerging PKIs
> are a start, a component, and a limited one. Again, it does "work"
> in a statistical sense, because most people are not crooks.
>
> My 2 cents.
>
> ___tony___
>
>
>
> Tony Bartoletti LL
> SPI-NET GURU LL LL
> Computer Security Technology Center LL LL LL
> Lawrence Livermore National Lab LL LL LL
> PO Box 808, L - 303 LL LL LLLLLLLL
> Livermore, CA 94551-9900 LL LLLLLLLL
> email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA19309 for ietf-pkix-bks; Sat, 3 Oct 1998 00:46:20 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA19303 for <ietf-pkix@imc.org>; Sat, 3 Oct 1998 00:46:17 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA17633; Sat, 3 Oct 1998 09:46:12 +0200
Received: by HYDRA with Microsoft Mail id <01BDEEB1.C1719370@HYDRA>; Sat, 3 Oct 1998 09:39:45 +0200
Message-ID: <01BDEEB1.C1719370@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Tony Bartoletti'" <azb@llnl.gov>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'Ed Gerck'" <egerck@laser.cps.softex.br>
Subject: RE: NEW Data type for certificate selection ?
Date: Sat, 3 Oct 1998 09:39:43 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA19305
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Tony,
>But unless a third party can be relied
>upon to reimburse me for my losses, when I send a digital check to
>"Acme Hardware" and recieve nothing in return, this third party is
>really not much more than a telephone directory.
Well, I do not share your optimism (?) that such problems have technical
solutions because there are only a few digital ways to adjust for human errors.
That there ever will be third parties that guarantee all kind of losses is
highly unlikely. They simply have to guarantee that the certificates they
issue belongs to known entities. A DUN-number for a company, a
PPIT for a person or a valid credit-card number for a SET-certificate.
And of course run a CA in a sensible way...
That is not rocket-science and we don't need it either!
Biometrical PIN-code replacements will improve the trust you have in clients.
For servers I see few improvements except maybe that some data
can be searched for at public sites. I.e. they may have to agree to
that to get a certificate of the type that you want to trust.
Just my 2 öre
Anders Rundgren
Senior Internet E-commerce Architect
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA29829 for ietf-pkix-bks; Fri, 2 Oct 1998 12:01:43 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29825 for <ietf-pkix@imc.org>; Fri, 2 Oct 1998 12:01:42 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id MAA20418; Fri, 2 Oct 1998 12:00:59 -0700 (PDT)
Message-Id: <3.0.3.32.19981002115946.00b18d50@poptop.llnl.gov>
X-Sender: e048786@poptop.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 02 Oct 1998 11:59:46 -0700
To: Anders Rundgren <anders.rundgren@jaybis.com>, "'Ed Gerck'" <egerck@laser.cps.softex.br>
From: Tony Bartoletti <azb@llnl.gov>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
In-Reply-To: <01BDEDDA.A7BD0CC0@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
At 07:59 AM 10/2/98 +0200, Anders Rundgren wrote:
>Ed,
>>The first usual misconception here is when people confuse trust in a
>>certificate to trust in a certificate's contents -- too quite
>>different animals. In fact, the first is directly defined under X.509
>>or PKIX but the second depends on the CPS, which depends on each CA,
>>which systematically negate it.
>
>Systematically negate it?
>
>Sorry, I fail to understand why it is technically, legally, etc. impossible to create trusted
>CA services that issues certificates with contents that can actually be used. But as I said earlier,
>Swedes are probably morons as we just do it anyway in spite of the fact that it does not work :-)
>
>Anders
Anders,
Current certification systems do "work", much as an ordinary telephone
directory works. The analogy would be closer if the publisher of the
phone book digitally signed each entry.
The phone book works because most people are honest and want to help
make things work. But I have no real way of knowing that the entry
for "Acme Hardware, Third Street" is indeed a hardware store, or can
be trusted to perform as I might expect it to.
People expect a digital-sig PKI to somehow automatically provide the
root of trust that is needed. Indeed, the terminology "root key",
"root CA" suggests as much. But unless a third party can be relied
upon to reimburse me for my losses, when I send a digital check to
"Acme Hardware" and recieve nothing in return, this third party is
really not much more than a telephone directory.
We want more, and need more from PK technology. The emerging PKIs
are a start, a component, and a limited one. Again, it does "work"
in a statistical sense, because most people are not crooks.
My 2 cents.
___tony___
Tony Bartoletti LL
SPI-NET GURU LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27939 for ietf-pkix-bks; Fri, 2 Oct 1998 07:37:51 -0700 (PDT)
Received: from ns.interax.com (interax.com [207.78.8.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27935 for <ietf-pkix@IMC.ORG>; Fri, 2 Oct 1998 07:37:50 -0700 (PDT)
From: administrator@bvc.org
Received: from ntserver.bvc (NTSERVER [207.78.8.214]) by ns.interax.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 4D9M8NY2; Fri, 2 Oct 1998 10:37:39 -0400
Received: by mis_server with Internet Mail Service (5.0.1460.8) id <ST2JLAN3>; Fri, 2 Oct 1998 08:44:29 -0400
Message-ID: <45B30763EBBDD1119458006097AC2E33037738@mis_server>
To: ietf-pkix@imc.org
Subject: RE: Notification: Inbound Mail Failure
Date: Fri, 2 Oct 1998 08:44:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
KWhite@BVC.Org is no longer a valid E-Mail Account. Please stop sending
these messages. Thank You.
-----Original Message-----
From: Administrator
Sent: Thursday, October 01, 1998 10:32 AM
To: Administrator
Subject: Notification: Inbound Mail Failure
The following recipients did not receive the attached mail. Reasons are
listed with each recipient:
<KWhite@BVC.ORG> KWhite@BVC.ORG
MSEXCH:IMS:Business Volunteerism Council:BVC:NTSERVER 0 (000C05A6)
Unknown Recipient
The message that caused this notification was:
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27928 for ietf-pkix-bks; Fri, 2 Oct 1998 07:37:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27924 for <ietf-pkix@imc.org>; Fri, 2 Oct 1998 07:37:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02436; Fri, 2 Oct 1998 10:36:52 -0400 (EDT)
Message-Id: <199810021436.KAA02436@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-ocsp-07.txt
Date: Fri, 02 Oct 1998 10:36:51 -0400
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
--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 : X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams
Filename : draft-ietf-pkix-ocsp-07.txt
Pages : 20
Date : 01-Oct-98
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.
An overview of the protocol is provided in section 3. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document (in uppercase, as shown) are to be interpreted as described
in [RFC2119].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-ocsp-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt
Internet-Drafts directories are located at:
Africa: ftp.is.co.za
Europe: ftp.nordu.net
ftp.nis.garr.it
Pacific Rim: munnari.oz.au
US East Coast: ftp.ietf.org
US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ietf.org. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ocsp-07.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: <19981002102031.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocsp-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ocsp-07.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19981002102031.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA19323 for ietf-pkix-bks; Thu, 1 Oct 1998 23:46:00 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA19262; Thu, 1 Oct 1998 23:45:28 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id SAA17892; Fri, 2 Oct 1998 18:44:52 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90731069200784>; Fri, 2 Oct 1998 18:44:52 (NZST)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cert-talk@structuredarts.com, ietf-pkix@imc.org, ietf-smime@imc.org
Subject: Updated ASN.1 dump program uploaded
Reply-To: pgut001@cs.auckland.ac.nz
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 2 Oct 1998 18:44:52 (NZST)
Message-ID: <90731069200784@cs26.cs.auckland.ac.nz>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I've just uploaded the latest update of my ASN.1 dump/diagnostic tool to
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c,cfg}. The main changes are
more OIDs in the config file, a kludge workaround for when it can't locate the
config file if argv[0] is set wrong (you can also tell it manually where the
file is with the -c option), and more options for picking apart ASN.1
objects. Run it with no args for a help screen.
Peter.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA18754 for ietf-pkix-bks; Thu, 1 Oct 1998 23:29:25 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA18746 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 23:29:23 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id DAA29758; Fri, 2 Oct 1998 03:29:19 -0300
Date: Fri, 2 Oct 1998 03:29:18 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Anders Rundgren <anders.rundgren@jaybis.com>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <01BDEDDA.A7BD0CC0@HYDRA>
Message-ID: <Pine.LNX.4.02.9810020308410.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Fri, 2 Oct 1998, Anders Rundgren wrote:
> Ed Gerck wrote:
>>
>>The first usual misconception here is when people confuse trust in a
>>certificate to trust in a certificate's contents -- too quite
>>different animals. In fact, the first is directly defined under X.509
>>or PKIX but the second depends on the CPS, which depends on each CA,
>>which systematically negate it.
>
>Systematically negate it?
>
>Sorry, I fail to understand why it is technically, legally, etc. impossible to create trusted
>CA services that issues certificates with contents that can actually be used. But as I said earlier,
>Swedes are probably morons as we just do it anyway in spite of the fact that it does not work :-)
Anders:
;-) As I suggested in my earlier msg, let us please leave
water-splashing to the ducks! Looks fun, but no work is done.
Probably you just could not yet read the reference I provided, which
is at http://143.106.29.39/certover.pdf -- "Overview of Certification
Systems: X.509, CA, PGP and SKIP". There is also a (older but more
complete) HTML version at cert.htm
However, the very end of its section on X.509 has the following text,
which I think will address your concerns -- please read the rest of
the paper for the context. You can also check the "Misconception"
series in the mcg-talk archives and the posting "Is there a business
for CAs?" -- the address is http://143.106.29.39/emails.htm
====================================================================
....[snip]
This paper reviews the three most common certification methods in use
today, which are based on X.509 Certificates and Certification
Authorities, PGP and, SKIP. These methods are studied from a systemic
point of view. The main motivations for this paper are: (i) Conduct a
comparative review of the three methods, (ii) Unify a set of
references to the most important issues in certification and
encryption, as they are related to Internet needs and recent
governmental policies, (iii) Provide a basis for the evaluation of
other certification solutions available or to be developed, (iv)
Identify room for improvements on the current security level of
certification, that could be dealt with by other methods, (v) Access
the impact on Internet transaction security due to the security
control policy needs of Governments currently actively promoting such
policy solutions.
....[snip]
In summary, there are many reasons that may jeopardize a
"certificate", create a weak link or, give the wrong contextual clues
for on-the-spot decision making.
The uncertainty reaches a point of almost uselessness, where CAs
usually explicitly state in the certification contracts that the CA
is exempt of all or almost all responsibility regarding the
"certificate", its accuracy and its data. For example:
VERISIGN DISCLAIMS ANY WARRANTIES WITH RESPECT TO THE SERVICES
PROVIDED BY VERISIGN HEREUNDER INCLUDING WITHOUT LIMITATION ANY
AND ALL IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. VERISIGN MAKES NO REPRESENTATION OR WARRANTY
THAT ANY CA OR USER TO WHICH IT HAS ISSUED A DIGITAL ID IN
THE VERISIGN SECURE SERVER HIERARCHY IS IN FACT THE PERSON OR
ORGANIZATION IT CLAIMS TO BE WITH RESPECT TO THE INFORMATION
SUPPLIED TO VERISIGN. VERISIGN MAKES NO ASSURANCES OF THE
ACCURACY, AUTHENTICITY, INTEGRITY, OR RELIABILITY OF
INFORMATION CONTAINED IN DIGITAL IDS OR IN CRLs COMPILED,
PUBLISHED OR DISSEMINATED BY VERISIGN, OR OF THE
RESULTS OF CRYPTOGRAPHIC METHODS IMPLEMENTED.
However, the issuer's disclaimer (i.e., the CA's) is generally not
visible in the certificate itself, for all browsers and all
X.509 implementations.
Further, such CA disclaimers are part of the CA's CPS (Certification
Practice Statement, which is outside the scope of X.509 and
constitutes the governing law that the CA presents to potential
clients). Thus, it can be seen as a legally-enforced way to reduce
deliverables to almost zero -- which is an accepted legal practice to
effectively reduce liability to zero. So, the point is not so much
that CAs deliver a product with zero warranty (which could be
disputed in court even in countries with common-law systems) but that
CAs are delivering a product with almost zero content (which any
court would accept as envolving almost zero liability) -- as it is
clearly exemplified in the second and third sentences of the above
disclaimer ("...MAKES NO REPRESENTATION ..." and "...MAKES NO
ASSURANCES ...").
Actually, the content of a CA's services in relationship to the
subject's data is not zero because there are two items that X.509
mandates and that a CA must deliver in a certificate without content
disclaimers (but, which may still be limited in scope by the CPS):
(i) that the subject's public-key has a working private-key
counterpart elsewhere (with no warranties that the public/private key
pair is not artifically weakened, that it is actually in the
possession of the named subject and that no one else has obtained a
copy of it), and (ii) that the subject's DN is unique to that CA
(with no warranties that such DN contains the actual subject's name,
location or that the subject even exists or has a correctly spelled
name -- as in "Internet Serices"). There are other items in the
certificate which have no relationship to the data supplied by the
subject but which are necessary for the proper use of the certificate
as a secure transport for information in the X.509 model, such as its
serial number, date of issuance, validity, the CA's signature, etc.,
which usually also carry limited CPS warranties (e.g., as in the case
of fraud, computer viruses, etc.) that may further jeopardize the
secure use of the certificate, without the user being even aware of
it.
Now, having cited Verisign's disclaimer, it is important to
understand its reasoning and need. It does not say that Verisign has
no warranty on its services or that it does not take any liability on
them. It only says that Verisign has no warranties and accepts no
liability for services that Verisign does not recognize it provides.
The fact that Verisign does not provide what perhaps the majority may
think they provide is another point altogether. The solution is,
perhaps, much more to educate the majority than to expect a company
to do what is maybe technically unfeasible in X.509 terms. Thus, in
the author's opinion, Verisign's CPS is not at all at odds with X.509
or legislation -- so, it could very well be an example to be copied.
Maybe, it just truly represents the maximum one commercially and
technically could wish for in X.509's and CPS's terms.
Thus, for any generic CA one might expect a similar reasoning.
Indeed, if the only thing that a CA does (as per X.509) is to
challenge the subscriber's private-key in order to bind the
corresponding public-key with the subscriber's DN and, if it signs
the certificate with a CPS that says that any other data are being
copied as received but have not been verified (and have thus no
warranty) then the CA has no responsibility for the contents of the
certificate -- save the positive acknowledgement that the public-key
did have a counterpart when it was linked to that DN (where the CPS
could further provide exceptions for frauds, virus, MITM attacks,
etc.).
One may ask, why are such content limitations and disclaimers
necessary for certificates? First, a certificate is not like a car
that has a limited liablity in space and time (after all, a car is a
localized entity that can contain a limited number of people and only
one driver). A certificate can be endlessly multiplied and
simultaneously presented in a planet-wide area. Certificates are used
without limit in a chain of events, which can include other fully
unrelated certificates and people. With the growing attitude of
seeking large legal compensation for one's lack of foresight, the
liability pyramid created by a lesser disclaimer could easily extend
to the CA's client's clients and so on.
Insurance protection may help here, but there are several issues that
must be touched upon. The use of insurance always signals lack of
knowledge -- so it clearly cannot replace it. Further, there is no
insurance needed for a sure event and there is no insurance possible
for a sure risk. If a user (ie, a CA subscriber) is going to for pay
insurance to cover his liabilities and the CA's liabilities (which is
what it amounts to), then responsibility has gone full-circle and is
now only in the user's hands -- both to get adequate coverage and to
pay for it. While the CA has zero risk and cashes in as the middleman
between the user and the insurance companies. However, that does not
solve the risk problem for the user either, because one cannot make
the whole world sign up one huge insurance policy -- so the user and
the CA may be protected by the insurance policy that the user has
bought with their names as beneficiaries but that does not protect a
third-party (ie, the rest of the world). Last, since CA auditing does
not help here, then insurance does not have a reliable risk estimator
either, even for the CA subscriber.
Regarding recent legislation efforts, such as in Utah (US), Illinois
(US) and other legislation, it is clear form the above discussion
that demanding broader warrants by law can be self-defeating because
CAs may then be forced to reduce the deliverables to zero -- instead
of coming out and providing for more warranties. There simply is a
limit to what X.509 and the CA paradigm can offer regarding legal
certificate reliance and -- most importantly and often confused with
the former -- legal certificate content reliance. Law cannot push the
technical envelope of X.509.
When confronted with risk situations, a normal business solution is
to rely on auditing. However, auditing of a CA's certificates is also
a difficult, if not impossible, task. This is due to X.509, which
allows CA's practices and policies to be built upon islands of
self-regulation exactly on the most important issues of trust and
trust management. As publicly declared by Phillip Hallam-Baker, a
Verisign consultant, not only are the CPSs indeed different and
self-made by each CA but they are not designed to be audited, either:
"There is not as yet a defined standard for CA practices against
which a company may be audited. In effect each company states their
own practices in their Certificate Practices Statement (CPS). The CPS
is not a document designed for auditing use however. It describes a
'specification', it does not describe details which may be checked by
a third party in a systematic manner."
Thus, a X.509 certificate is essentially a bag of bytes, which
meaning and validity strongly depends on the CA. Moreover, in legal
reliance terms, one may trust the confirmation procedures of the CA
during certificate reliance, but one cannot rely upon them for other
than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules --
therefore, a X.509 certificate is neither necessarily meaningful nor
valid in a user's reference frame or for the user's purposes.
Last, when one waches for some time the different mailing lists that
collects doubts and questions on certification systems from users or,
when one reads the majority of the newspaper or magazine articles on
the subject, one cannot help but perceive a pervailing feeling in the
user community to the effect that a certificate is magically infused
with trustworthiness -- which would imply a deterministic and
absolute view of certification. For example, as one user wrote:
"Please provide me with a list of all trusted CAs so that I can enter
those certificates into my browser.", few understand that trust must
be evaluated relative to the user -- the party at risk. Thus, the
very names Trusted Third Party or trusted CA raise already several
questions:
- in relationship to whom?
- trusted by whom?
- trusted for what?
- trusted for how long?
-- etc.
How are these questions answered? Clearly, by each user (ie, verifier
or, relying party -- who is at risk) in its own domain, references
and terms. This means that certificates are essentially statements
from a CA, not fact, and that meaning and trust on a certificate
(like beauty) is in the eyes of the beholder, i.e., depends on each
user.
==================================================================
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
---- Meta-Certificate Group Member -- http://www.mcg.org.br ---
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA16831 for ietf-pkix-bks; Thu, 1 Oct 1998 23:06:37 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA16823 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 23:06:34 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA21520; Fri, 2 Oct 1998 08:06:26 +0200
Received: by HYDRA with Microsoft Mail id <01BDEDDA.A7BD0CC0@HYDRA>; Fri, 2 Oct 1998 08:00:00 +0200
Message-ID: <01BDEDDA.A7BD0CC0@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Ed Gerck'" <egerck@laser.cps.softex.br>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Fri, 2 Oct 1998 07:59:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
>The first usual misconception here is when people confuse trust in a
>certificate to trust in a certificate's contents -- too quite
>different animals. In fact, the first is directly defined under X.509
>or PKIX but the second depends on the CPS, which depends on each CA,
>which systematically negate it.
Systematically negate it?
Sorry, I fail to understand why it is technically, legally, etc. impossible to create trusted
CA services that issues certificates with contents that can actually be used. But as I said earlier,
Swedes are probably morons as we just do it anyway in spite of the fact that it does not work :-)
Anders
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02333 for ietf-pkix-bks; Thu, 1 Oct 1998 17:18:32 -0700 (PDT)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02329 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 17:18:31 -0700 (PDT)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id RAA07570 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 17:18:00 -0700 (PDT)
Message-Id: <199810020018.RAA07570@crack.x509.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: Your message of "Fri, 02 Oct 1998 00:47:37 +0200." <3.0.32.19981002004700.00a4f600@m1.403.telia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 01 Oct 1998 17:18:00 -0700
From: Marc Branchaud <marcnarc@xcert.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Stefan Santesson <stefan@accurata.se> scrawled:
> =
> Marc,
> =
> If I follow you right you suggest that I use the knowledge from the SSL=
> negotiation to select the proper non-repudiation cert for signing
> transactions. I have thought of that but I have my doubts.
> =
Not necessarily from the SSL handshake itself (although since that's
already there it would be an optimization). But the same kind of mechani=
sm
could be employed, i.e. "here's a list of CAs whose certs I can accept."
> It would be very easy for the server to link knowledge from the link le=
vel
> (SSL) to the Application level (Javascript). The question is if that is=
> possible at the client side, by only using standard components (existin=
g or
> coming).
> =
So, you have this new requirement that nobody's really though of yet, and=
=
you're wondering if existing or planned components will solve your =
problem. Hmmm....
> Suppose the following steps:
> 1) The client browser knows which certificate was used to set up the SS=
L
> channel.
> 2) The server transfer a Javascript to the client in order to create th=
e
> electronic transaction form
> 3) After completing the form the Javascript request a signature on the
> completed form before it's transferred to the server.
> =
> Now even if the non-repudiation certificate and the SSL certificate was=
> issued by the same CA, Will any existing or planned version of any brow=
ser
> have the logic needed to find the right certificate. Not in theory, in
> practice.
> =
In practice, no such Javascript program exists so, practically speaking,
one would have to plan one's Javascript program to have such functionalit=
y.
I'm not familiar with web scripting languages, but I imagine that it's
possible to get the issuer DN of the server's cert and/or all the certs
presented by the server in the SSL handshake. Whether that's existing or=
=
planned, I have no idea.
As for whatever matching rule is required, it will most likely be =
implemented by the applet than the browser. I expect few browser makers =
would be happy to write some kind of generic lookup function to answer =
queries of the form "I need a cert of type <fee> that has a <foo> and =
isn't <foe> but can be <fum>". They'd be much happier to simply expose =
the broswer's certificate store to the applet and let the applet do the =
search.
> If not, then the problem is real and needs a solution. And if a solutio=
n is
> needed I would like to see better selective mechanisms than just Issuer=
DN
> of the CA.
> =
This, I think, is the crucial issue. I'm having trouble seeing why
matching issuer DNs is inadequate. Is it because having a CA per =
application is impractical? Since we're talking about banking here, I =
can't believe that the answer would be "yes" [heck, with a moderate =
hierarchy, the user would only need one cert (from the root CA) to use al=
l =
of the bank's applications].
Please explain to me why saying "I need you to use a cert signed by one o=
f =
these CAs" isn't a good enough solution.
Marc
+------------------------------------------------------------------------=
+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC=
=2E
marcnarc@xcert.com PKI References page: www.xcert.co=
m
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------=
+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNhQbt1rdFXNdDxPlAQEtswL8CZltb8fpsRO5urWESF9Ps4FNVlO9rLui
8+eDmkaf9L7AnY+ljW7ZCYF0p8zk/f6d7xmpia+gxdQBxT6edKYOOTzsr2cwY3Hf
RITSfqoIf4XpQTy/N1lBRhGRLZ0qYYwR
=9JQx
-----END PGP SIGNATURE-----
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01845 for ietf-pkix-bks; Thu, 1 Oct 1998 15:43:31 -0700 (PDT)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01841 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 15:43:29 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id AAA15750; Fri, 2 Oct 1998 00:50:36 +0200 (CEST)
Received: from stefans (t1o68p113.telia.com [62.20.138.113]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA15138; Fri, 2 Oct 1998 00:50:34 +0200 (CEST)
Message-Id: <3.0.32.19981002004700.00a4f600@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 02 Oct 1998 00:47:37 +0200
To: Marc Branchaud <marcnarc@xcert.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA01842
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Marc,
If I follow you right you suggest that I use the knowledge from the SSL
negotiation to select the proper non-repudiation cert for signing
transactions. I have thought of that but I have my doubts.
It would be very easy for the server to link knowledge from the link level
(SSL) to the Application level (Javascript). The question is if that is
possible at the client side, by only using standard components (existing or
coming).
Suppose the following steps:
1) The client browser knows which certificate was used to set up the SSL
channel.
2) The server transfer a Javascript to the client in order to create the
electronic transaction form
3) After completing the form the Javascript request a signature on the
completed form before it's transferred to the server.
Now even if the non-repudiation certificate and the SSL certificate was
issued by the same CA, Will any existing or planned version of any browser
have the logic needed to find the right certificate. Not in theory, in
practice.
If not, then the problem is real and needs a solution. And if a solution is
needed I would like to see better selective mechanisms than just Issuer DN
of the CA.
/Stefan
At 11:28 AM 10/1/98 -0700, Marc Branchaud wrote:
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>
>Stefan, your bank application here actually requires two functions:
>
>(1) An automated way to select the non-repudiation cert to be used in ste=
>p =
>
>4, and (2) a way to let browser users create a non-repudiable signature =
>
>(setting aside for the moment the definition of what that is).
>
>This thread started out as a quest for (1). Well, that can easily be =
>
>achieved using existing mechanisms such as SSL. You already mentioned th=
>e =
>
>plastic card analogy, and it can work exactly the same way: the non-rep c=
>ert =
>
>and the SSL server's cert can share a common parent CA. When the browser=
> =
>
>receives the SSL server's cert chain the in SSL handshake, it can know th=
>at =
>
>only certs signed by one of those CAs should be used for these transactio=
>ns.
>
>It's just like the plastic cards, where the logo (DN) of the place you're=
>
>doing buisiness with matches the logo (DN) on one of your cards and so yo=
>u
>know which card to use.
>
>Now, (2) is a completely different problem, and is one that, unlike (1),
>currently requires some kind of plugin, seeing as how there is currently =
>no
>such thing as "signing a web form". However, selecting the proper cert i=
>s
>easy, since the "transaction form" that gets filled out came from a secur=
>e
>site and the SSL handshake contains enough info to match a CA to one of t=
>he
>user's certs. All that is required to to select one of the matching cert=
>s
>that has the nonRepudiation bit set, then present it to the user so that =
>he
>knows it's getting used when he clicks the button.
>
> Marc
>
>+------------------------------------------------------------------------=
>+
> Marc Branchaud \/
> Chief PKI Architect /\CERT INTERNATIONAL INC=
>=2E
> marcnarc@xcert.com PKI References page: www.xcert.co=
>m
> 604-640-6227 www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------=
>+
> PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
>
>
>Stefan Santesson <stefan@accurata.se> scrawled:
>> =
>
>> Ed,
>> =
>
>> Now this is getting really exciting. I really want to understand what y=
>ou
>> are suggesting.
>> =
>
>> How would you create a Bank application over https: ?
>> Here is some simple design requirements:
>> 1) First a secure channel shall be created (using SSL/TLS)
>> 2) Through the secure channel the customer is allowed to view accounts,=
>
>> exchange rates etc.
>> 3) The customer is allowed to enter payment transactions.
>> 4) Each payment transaction shall be individually signed using the
>> customers non-repudiation certificate issued for the purpose.
>> 5) Each transaction signature shall require the customers conscious
>> acceptance.
>> =
>
>> Now. How can you create this function without a plug-in and without usi=
>ng
>> Javascript or similar.
>> I would be vary happy to know this.
>> =
>
>> /Stefan
>> =
>
>> At 12:29 PM 10/1/98 -0300, Ed Gerck wrote:
>> >On Thu, 1 Oct 1998, Stefan Santesson wrote:
>> >
>> >>Hi Ed,
>> >>
>> >>I'm just trying to understand what you are saying.
>> >>
>> >>Are what you are saying, that you would solve the problem generally b=
>y, for
>> >>each issuer, having a different Issuer DN, per certificate type? =
>
>> >>Well I have thought of that for the SSL/TLS case but I don't like it.=
>
>> >
>> >Stefan:
>> >
>> >;-)
>> >
>> >May I remind you that you wrote:
>> > =
>
>> > I realize that today there is no way to do this without distributing
>> > customized plug-in components to end-users
>> >
>> >However, there are actually TWO ways, as I mentioned in my previous
>> >postings, that do not involve plug-ins and do not need Javascript
>> >either (btw, a security risk right there).
>> >
>> >
>> >>Simply because many planned CA-services does not work that way and I'=
>m not
>> >>convinced that they should either.
>> >
>> >;-) Simply because you perhaps want to make commercial CA-services
>> >mandatory to Banks. However, that is neither needed to Banks nor
>> >desirable security wise.
>> >
>> >Further, if you want to name an objection, please do so. Generic
>> >"does not work that way", without qualifying the "that" or why -- is
>> >not useful in a discussion. SMTP carries only written words yet, not
>> >thoughts ;-)
>> >
>> >Can you be specific?
>> >
>> >>
>> >>The next question is, how do I use the SSL/TLS negotiation to pick th=
>e
>> >>right certificate for creating a signed object in a Java script?
>> >
>> >As I explained before, there are TWO ways to pick the intended
>> >certificate and no other cert. However, pls consider abandoning
>> >Javascripts to provide *functionality* -- even though JS may add
>> >embellishments. Several major companies and security concerned
>> >individuals do not use JS at all.
>> >
>> >Cheers,
>> >
>> >Ed Gerck
>> >______________________________________________________________________=
>
>> >Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br=
>
>> >http://novaware.cps.softex.br
>> > -- Member of the Meta-Certificate Group -- http://www.mcg.org.br =
>
>> >
>> >
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson <stefan@accurata.se>
>> Accurata Systems=E4kerhet AB =
>
>> Lotsgatan 27 D Tel. +46-40 152211 =
>
>> 216 42 Malm=F6 Fax. +46-40 150790 =
>
>> Sweden Mobile +46-70 5247799
>> =
>
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29873 for ietf-pkix-bks; Thu, 1 Oct 1998 11:21:45 -0700 (PDT)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29869 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 11:21:44 -0700 (PDT)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id LAA24399 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 11:28:20 -0700 (PDT)
Message-Id: <199810011828.LAA24399@crack.x509.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: Your message of "Thu, 01 Oct 1998 17:40:35 +0200." <3.0.32.19981001173958.00a24a00@m1.403.telia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 01 Oct 1998 11:28:20 -0700
From: Marc Branchaud <marcnarc@xcert.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Stefan, your bank application here actually requires two functions:
(1) An automated way to select the non-repudiation cert to be used in ste=
p =
4, and (2) a way to let browser users create a non-repudiable signature =
(setting aside for the moment the definition of what that is).
This thread started out as a quest for (1). Well, that can easily be =
achieved using existing mechanisms such as SSL. You already mentioned th=
e =
plastic card analogy, and it can work exactly the same way: the non-rep c=
ert =
and the SSL server's cert can share a common parent CA. When the browser=
=
receives the SSL server's cert chain the in SSL handshake, it can know th=
at =
only certs signed by one of those CAs should be used for these transactio=
ns.
It's just like the plastic cards, where the logo (DN) of the place you're=
doing buisiness with matches the logo (DN) on one of your cards and so yo=
u
know which card to use.
Now, (2) is a completely different problem, and is one that, unlike (1),
currently requires some kind of plugin, seeing as how there is currently =
no
such thing as "signing a web form". However, selecting the proper cert i=
s
easy, since the "transaction form" that gets filled out came from a secur=
e
site and the SSL handshake contains enough info to match a CA to one of t=
he
user's certs. All that is required to to select one of the matching cert=
s
that has the nonRepudiation bit set, then present it to the user so that =
he
knows it's getting used when he clicks the button.
Marc
+------------------------------------------------------------------------=
+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC=
=2E
marcnarc@xcert.com PKI References page: www.xcert.co=
m
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------=
+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
Stefan Santesson <stefan@accurata.se> scrawled:
> =
> Ed,
> =
> Now this is getting really exciting. I really want to understand what y=
ou
> are suggesting.
> =
> How would you create a Bank application over https: ?
> Here is some simple design requirements:
> 1) First a secure channel shall be created (using SSL/TLS)
> 2) Through the secure channel the customer is allowed to view accounts,=
> exchange rates etc.
> 3) The customer is allowed to enter payment transactions.
> 4) Each payment transaction shall be individually signed using the
> customers non-repudiation certificate issued for the purpose.
> 5) Each transaction signature shall require the customers conscious
> acceptance.
> =
> Now. How can you create this function without a plug-in and without usi=
ng
> Javascript or similar.
> I would be vary happy to know this.
> =
> /Stefan
> =
> At 12:29 PM 10/1/98 -0300, Ed Gerck wrote:
> >On Thu, 1 Oct 1998, Stefan Santesson wrote:
> >
> >>Hi Ed,
> >>
> >>I'm just trying to understand what you are saying.
> >>
> >>Are what you are saying, that you would solve the problem generally b=
y, for
> >>each issuer, having a different Issuer DN, per certificate type? =
> >>Well I have thought of that for the SSL/TLS case but I don't like it.=
> >
> >Stefan:
> >
> >;-)
> >
> >May I remind you that you wrote:
> > =
> > I realize that today there is no way to do this without distributing
> > customized plug-in components to end-users
> >
> >However, there are actually TWO ways, as I mentioned in my previous
> >postings, that do not involve plug-ins and do not need Javascript
> >either (btw, a security risk right there).
> >
> >
> >>Simply because many planned CA-services does not work that way and I'=
m not
> >>convinced that they should either.
> >
> >;-) Simply because you perhaps want to make commercial CA-services
> >mandatory to Banks. However, that is neither needed to Banks nor
> >desirable security wise.
> >
> >Further, if you want to name an objection, please do so. Generic
> >"does not work that way", without qualifying the "that" or why -- is
> >not useful in a discussion. SMTP carries only written words yet, not
> >thoughts ;-)
> >
> >Can you be specific?
> >
> >>
> >>The next question is, how do I use the SSL/TLS negotiation to pick th=
e
> >>right certificate for creating a signed object in a Java script?
> >
> >As I explained before, there are TWO ways to pick the intended
> >certificate and no other cert. However, pls consider abandoning
> >Javascripts to provide *functionality* -- even though JS may add
> >embellishments. Several major companies and security concerned
> >individuals do not use JS at all.
> >
> >Cheers,
> >
> >Ed Gerck
> >______________________________________________________________________=
> >Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br=
> >http://novaware.cps.softex.br
> > -- Member of the Meta-Certificate Group -- http://www.mcg.org.br =
> >
> >
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson <stefan@accurata.se>
> Accurata Systems=E4kerhet AB =
> Lotsgatan 27 D Tel. +46-40 152211 =
> 216 42 Malm=F6 Fax. +46-40 150790 =
> Sweden Mobile +46-70 5247799
> =
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNhPJw1rdFXNdDxPlAQEUDAL5Ab6kPwIeZiFlyLPHn/Kb5Tqb4x9G1fhJ
yqhoagj3lZuCk1UuO6648160+1u/zNwDCPbxDFIb6luWe68T16Jo7MxZnjZfKPK0
e2pSYkpwHht9mnYSMgA/AKNUQGq/Vrzk
=Xpjl
-----END PGP SIGNATURE-----
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29447 for ietf-pkix-bks; Thu, 1 Oct 1998 10:24:57 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29442 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 10:24:49 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id OAA28802; Thu, 1 Oct 1998 14:31:09 -0300
Date: Thu, 1 Oct 1998 14:31:09 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Anders Rundgren <anders.rundgren@jaybis.com>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, list@seis.nc-forum.com
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <01BDED68.1E552480@HYDRA>
Message-ID: <Pine.LNX.4.02.9810011355240.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Anders Rundgren wrote:
>Ed,
>You failed to comment on the *technical* part of my suggestion and went
>immediately to politics! Please spend some time on that part in spite
>of the fact that you think Swedes are morons (we must be as we have used PPITs
>extensively the last 30 years or so). And even morons want solutions to their
>stupid little problems. :-)
Anders:
I liked very much my visits to Sweden and Stockholm is specially
pretty, though I missed its Spring and Summer. It is also the leading
place in the world for ultra-short high-power Ti:Saphire lasers --
also selling to other Instituts in Europe including the Max-Planck in
Germany. One of the most hilarious things that happened to me in
Sweden was when I read a political comment in one of your neswpapers,
with an excellent drawing to go with it, that depicted two
politicians in a washbasin throwing words to one another -- and it
read "like ducks in a washbasin, happiliy throwing water at each
other and thinking that they are doing something great!"
I remember this now as I expect a better fate for this discussion.
>
>Note that unlike some certificates, certificates with PPITs
>are never published on a directory server. You may though check its status with
>OCSP or similar in case you (as a trusted party) received such a certificate.
I wish to copy one of my earlier remarks on this, as I think it shows
that I had no qualms with what you say above:
However, if we accept that there may be valid uses for "public-key
certs" which are not public, with all the security and privacy risks
that may ensue from such usage (such as when Bill trusts Monica that
trusts Linda; or, when Bill cannot revoke a token that was given to
Monica and which unfortunately Monica had to surrender) -- then we
must consider that each "non-public" public-key cert and private-key
will be handled either by a special application or by an interactive
and possibly customized procedure in a general application (eg, a
web browser). Which then answers subproblems (1) and (2) also for
"non-public" public-key certs.
>
>>> but to allow users to authenticate themselves
>>>using a valid certificate (be it electronical or physical) where the certificate
>>>receiver only must know what issuers (and domain) to trust.
>
>>This has nothing to do with YAPITs. It has to do with issuer trust
>>and key challenge-response.
>
>Not at all. challenge-response verifies that you really are in the possession of the certificate.
>In the physical world you compare the ID-card picture with the face of the card-holder.
>
No, I think you overshoot the target. The point being that after a
sucessful challenge-response with client/server authentication in
SSL, you have a secure channel that you and your party can trust at
most as you both currently trust the CA cert used to authenticate the
server/client certs (I say at most because, of course, that trust
also depends on your certs, your applications, etc. and not only on
the CA cert). Through that secure channel now you transit with
whatever information you may need and the other party be willing to
provide, be it PPITs, or YAPITs, or credit card numbers of course.
The first usual misconception here is when people confuse trust in a
certificate to trust in a certificate's contents -- too quite
different animals. In fact, the first is directly defined under X.509
or PKIX but the second depends on the CPS, which depends on each CA,
which systematically negate it.
The second usual misconception (derived from the first) is when
people confuse reliance on a cert with reliance on a cert's contents.
In legal reliance terms, one may trust the confirmation procedures of
the CA during certificate reliance, but one cannot rely upon them for
other than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules --
therefore, a X.509 certificate is neither necessarily meaningful nor
valid in a user's reference frame or for the user's purposes. [Cf.
http://www.mcg.org.br/certover.pdf or cert.htm]
>>Each country/company/person can do as they please, but in a
>>competitive world market the one with least information exposure has
>>a large advantadge. BTW, is that not what security is all about ? ;-)
>
>Security has many faces. That you really are communicating with
>the right person is one example :-)
Which is not warranted by X.509/PKIX, neither by commercial CAs' CPS,
nor by commercial CAs' quarantees, nor by law (eg, the US UCC).
Unfortunately, it is also a common misconception (number three) to
think otherwise.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29112 for ietf-pkix-bks; Thu, 1 Oct 1998 09:46:50 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29108 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 09:46:48 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id NAA28777; Thu, 1 Oct 1998 13:53:42 -0300
Date: Thu, 1 Oct 1998 13:53:42 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19981001172310.00a3daa0@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9810011341570.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Stefan Santesson wrote:
>
>Ed,
>
>I just want to clearify that I don't want to see any YAPITs (or any other
>speciffic attribute) hardcoded by design into any certificate slection
>mechanism.
Stefan:
I am really glad you are taking private data such as SSN out of the
picture and out of the data that you need to have in a public cert --
for the second time in this thread.
>But I don't want to stop anyone from using it as selective criteria either.
However, I do want to guarantee that no one will be forced or coaxed
into accepting that "selective criteria". As I said, if you want to
have enough rope to hang yourself (eg, as in C) that is fine but just
don't make it mandatory to thy neighbor.
>
>To me the YAPIT (Yet Another Personal Information Token) discussion belongs
>in completely different dimension independent of the certificate select
>problem space. (even if it is an interesting subject).
>
Agreed -- iff it is taken out of that picture! As it is being done
now, again.
However, another point of my msg still remains. Can you pls address
my reply to your affirmation below:
>>> PPITs are not only designed to make big-brothers job easier :-),
>>> but to allow users to authenticate themselves using a valid
>>> certificate (be it electronical or physical) where the
>>> certificate receiver only must know what issuers (and domain) to
>>> trust.
where PPIT is your name for YAPTI and I commented:
>>This has nothing to do with YAPITs. It has to do with issuer trust
>>and key challenge-response.
>>
>>I affirm that a certificate may only be its signature in size -- a 20
>>byte string -- and that suffices to allow anything you can do with
>>any kilobyte-size X509v3 cert, or even mega-byte size. So, YAPTIs do
>>not really belong to certs as a functional need. To ignore this is to
>>ignore what certificates are.
>>
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28983 for ietf-pkix-bks; Thu, 1 Oct 1998 09:33:11 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28979 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 09:33:08 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id NAA28768; Thu, 1 Oct 1998 13:40:10 -0300
Date: Thu, 1 Oct 1998 13:40:10 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19981001173958.00a24a00@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9810011329590.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Stefan Santesson wrote:
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Ed,
>
>Now this is getting really exciting. I really want to understand what you
>are suggesting.
>
>How would you create a Bank application over https: ?
;-) commercial enquiries pls to sales@novaware.com.br
>Here is some simple design requirements:
>1) First a secure channel shall be created (using SSL/TLS)
as explained in my previous postings, with server and client
authentication in SSL.
>2) Through the secure channel the customer is allowed to view accounts,
>exchange rates etc.
a question for a proper cgi-bin or Java servlet at the Bank's server.
>3) The customer is allowed to enter payment transactions.
sure, why not? He has (1) and (2) above at his disposal -- with all
needed functionality.
>4) Each payment transaction shall be individually signed using the
>customers non-repudiation certificate issued for the purpose.
as explained in my previous postings, with TWO options for that
implementation.
>5) Each transaction signature shall require the customers conscious
>acceptance.
>
;-) that you can NEVER guarantee over the Internet! Pls re-state your
goals and NEVER depend on that assumption.
>Now. How can you create this function without a plug-in and without using
>Javascript or similar.
>I would be vary happy to know this.
Well, I already tried to explain -- twice and with TWO options. Can
you tell me step by step, preferably by directly quoting my words of
the first posting where the solution was detailed, where is the
disconnect?
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28875 for ietf-pkix-bks; Thu, 1 Oct 1998 09:19:35 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA28871 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 09:19:33 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id SAA85194; Thu, 1 Oct 1998 18:26:32 +0200
Received: by HYDRA with Microsoft Mail id <01BDED68.1E552480@HYDRA>; Thu, 1 Oct 1998 18:20:07 +0200
Message-ID: <01BDED68.1E552480@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Ed Gerck'" <egerck@laser.cps.softex.br>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 18:20:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
You failed to comment on the *technical* part of my suggestion and went
immediately to politics! Please spend some time on that part in spite
of the fact that you think Swedes are morons (we must be as we have used PPITs
extensively the last 30 years or so). And even morons want solutions to their
stupid little problems. :-)
Note that unlike some certificates, certificates with PPITs
are never published on a directory server. You may though check its status with
OCSP or similar in case you (as a trusted party) received such a certificate.
>> but to allow users to authenticate themselves
>>using a valid certificate (be it electronical or physical) where the certificate
>>receiver only must know what issuers (and domain) to trust.
>This has nothing to do with YAPITs. It has to do with issuer trust
>and key challenge-response.
Not at all. challenge-response verifies that you really are in the possession of the certificate.
In the physical world you compare the ID-card picture with the face of the card-holder.
>Each country/company/person can do as they please, but in a
>competitive world market the one with least information exposure has
>a large advantadge. BTW, is that not what security is all about ? ;-)
Security has many faces. That you really are communicating with the right person is one example :-)
In the competitive world market there are always tradeoffs between "features" that
usually are in some conflict with each other. Like price and speed.
Convenience is also a selling point
Giving a PPIT to an employer is not the same thing as giving up your soul.
Giving a PPIT to everyone is surely stupid, not recommendable, but is unlikely
to give you half as much *real* problems as a publicly known e-mail addresses
or telephone numbers!
But lets get back to the technical track otherwise we must change mailing-list!
Anders
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28500 for ietf-pkix-bks; Thu, 1 Oct 1998 08:36:26 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28496 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:36:25 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id RAA14893; Thu, 1 Oct 1998 17:43:32 +0200 (CEST)
Received: from stefans (t1o68p85.telia.com [62.20.138.85]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id RAA29929; Thu, 1 Oct 1998 17:43:31 +0200 (CEST)
Message-Id: <3.0.32.19981001173958.00a24a00@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 17:40:35 +0200
To: Ed Gerck <egerck@laser.cps.softex.br>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA28497
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
Now this is getting really exciting. I really want to understand what you
are suggesting.
How would you create a Bank application over https: ?
Here is some simple design requirements:
1) First a secure channel shall be created (using SSL/TLS)
2) Through the secure channel the customer is allowed to view accounts,
exchange rates etc.
3) The customer is allowed to enter payment transactions.
4) Each payment transaction shall be individually signed using the
customers non-repudiation certificate issued for the purpose.
5) Each transaction signature shall require the customers conscious
acceptance.
Now. How can you create this function without a plug-in and without using
Javascript or similar.
I would be vary happy to know this.
/Stefan
At 12:29 PM 10/1/98 -0300, Ed Gerck wrote:
>On Thu, 1 Oct 1998, Stefan Santesson wrote:
>
>>Hi Ed,
>>
>>I'm just trying to understand what you are saying.
>>
>>Are what you are saying, that you would solve the problem generally by, for
>>each issuer, having a different Issuer DN, per certificate type?
>>Well I have thought of that for the SSL/TLS case but I don't like it.
>
>Stefan:
>
>;-)
>
>May I remind you that you wrote:
>
> I realize that today there is no way to do this without distributing
> customized plug-in components to end-users
>
>However, there are actually TWO ways, as I mentioned in my previous
>postings, that do not involve plug-ins and do not need Javascript
>either (btw, a security risk right there).
>
>
>>Simply because many planned CA-services does not work that way and I'm not
>>convinced that they should either.
>
>;-) Simply because you perhaps want to make commercial CA-services
>mandatory to Banks. However, that is neither needed to Banks nor
>desirable security wise.
>
>Further, if you want to name an objection, please do so. Generic
>"does not work that way", without qualifying the "that" or why -- is
>not useful in a discussion. SMTP carries only written words yet, not
>thoughts ;-)
>
>Can you be specific?
>
>>
>>The next question is, how do I use the SSL/TLS negotiation to pick the
>>right certificate for creating a signed object in a Java script?
>
>As I explained before, there are TWO ways to pick the intended
>certificate and no other cert. However, pls consider abandoning
>Javascripts to provide *functionality* -- even though JS may add
>embellishments. Several major companies and security concerned
>individuals do not use JS at all.
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
>http://novaware.cps.softex.br
> -- Member of the Meta-Certificate Group -- http://www.mcg.org.br
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28389 for ietf-pkix-bks; Thu, 1 Oct 1998 08:27:34 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28385 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:27:29 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28706; Thu, 1 Oct 1998 12:34:01 -0300
Date: Thu, 1 Oct 1998 12:33:58 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Paul Koning <pkoning@xedia.com>
cc: ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <199810011311.JAA00124@tonga.xedia.com>
Message-ID: <Pine.LNX.4.02.9810011230190.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Paul Koning wrote:
>>>>>> "Ed" == Ed Gerck <egerck@laser.cps.softex.br> writes:
>
> Ed> On Thu, 1 Oct 1998, Stefan Santesson wrote:
> >>...
> >> You and I can argue for centuries if certificates handled in
> >> browsers should, or should not, be allowed to contain SSN.
>
> Ed> No, I don't argue. As I wrote two msgs ago, some think they have
> Ed> valid reasons for it and I do not disagree with the need to
> Ed> preserve freedom.
>
>Unfortunately, the world (or at least the country) is infested with
>organizations that think they have a valid reason to ask for a SSN
>when in fact they have neither a valid reason nor any legal authority
>to do so. Some, if you pound on the table enough, will yield. (For
>example, my medical insurance started by asking for it, but when
>pushed conceded that they could make up a number instead. Surprised
>me; most outfits of that type don't have enough sense to see that.)
>
>So I would say that anything protocol mechanism that encourages this
>sort of abuse is evil and must be resisted.
Agreed 100%, especially in a public protocol. That is why I wrote
"some think thay have valid reasons".
However, freedom is never lost all at once (Hume) also means that
I must respect the desire of others -- as long and if and only if
that does not collide with mine.
Thanks,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28359 for ietf-pkix-bks; Thu, 1 Oct 1998 08:23:18 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28355 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:23:16 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id RAA09379; Thu, 1 Oct 1998 17:30:22 +0200 (CEST)
Received: from stefans (t1o68p9.telia.com [62.20.138.9]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id RAA25917; Thu, 1 Oct 1998 17:30:20 +0200 (CEST)
Message-Id: <3.0.32.19981001172310.00a3daa0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 17:27:25 +0200
To: Ed Gerck <egerck@laser.cps.softex.br>, Anders Rundgren <anders.rundgren@jaybis.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA28356
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
I just want to clearify that I don't want to see any YAPITs (or any other
speciffic attribute) hardcoded by design into any certificate slection
mechanism.
But I don't want to stop anyone from using it as selective criteria either.
To me the YAPIT (Yet Another Personal Information Token) discussion belongs
in completely different dimension independent of the certificate select
problem space. (even if it is an interesting subject).
/Stefan
At 12:09 PM 10/1/98 -0300, Ed Gerck wrote:
>On Thu, 1 Oct 1998, Anders Rundgren wrote:
>
>>Hi Ed,
>>>Your suggestion:
>>>
>>>The solution is to add "salt" -- like it is done in UNIX passwords.
>>>For example, you can add 50 chars of salt or as many as you want -- a
>>>passphrase. The point here is that since you know the SSN and the
>>>salt, no one else can guess the SSN from a dictionary attack on only
>>>9 digits. Better still, you can change the hash in a new cert and
>>>keep the SSN constant, by changing the salt, so no one can verify
>>>your SSN in a new cert without your cooperation.
>>
>>As my countryman Stefan already pointed out we can argue for centuries
about the
>>use of SSNs or as I would call them: PPIT - Persistent Personal Identity
Tag.
>>
>>Assuming that you *actually* *have* *such* *a* *scheme* you loose all the
benefits of
>>PPITs by applying your "salted" methods to PPITs. PPITs are not only
designed to
>>make big-brothers job easier :-),
>
>Anders:
>
>I think you can call YAPITs (Yet Another Personal Information Token)
>whatever you like and I will further grant anyone the right to make
>his private information public -- IF he so desires. However, NOT by
>design, which is what you apparently defend to allow as a legitimate
>feature of a "security design". What you imply is similar to the
>"rationale" for GAK-ware considerations.
>
>> but to allow users to authenticate themselves
>>using a valid certificate (be it electronical or physical) where the
certificate
>>receiver only must know what issuers (and domain) to trust.
>>
>
>This has nothing to do with YAPITs. It has to do with issuer trust
>and key challenge-response.
>
>I affirm that a certificate may only be its signature in size -- a 20
>byte string -- and that suffices to allow anything you can do with
>any kilobyte-size X509v3 cert, or even mega-byte size. So, YAPTIs do
>not really belong to certs as a functional need. To ignore this is to
>ignore what certificates are.
>
>
>>This is a major benefit for
>>all parties as you can have a life-time password/userid replacement with
>>full security (technically speaking) independent on actual certificate.
>
>You are unfortunately fully mistaken. What you describe is similar to
>Faustus' dilemma: your security now versus your soul forever. Well,
>we all know how it ends. You cannot trade your life-long privacy in
>exchange for some degree of security now.
>
>> It simply
>>cuts costs and confusion (at the expense of personal integrity).
>
>If an expense cannot be paid back (as privacy cannot) then it is not
>an expense -- it is called a loss, in any country and possibly also
>in yours as you speak about your countryman above.
>
>I'd rather think non-parochially and strive to find and define
>methods which assert equal security rights -- irrespective of
>computational power, influence or supplier.
>
> > If this is
>>good or not is something the market (and in some cases national laws)
>>will decide. My personal opinion is that if successful PKIs (Stefan!) are
>>established based on PPITs the disbeliveers *may* change their mind.
>>
>
>Each country/company/person can do as they please, but in a
>competitive world market the one with least information exposure has
>a large advantadge. BTW, is that not what security is all about ? ;-)
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
>http://novaware.cps.softex.br
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28352 for ietf-pkix-bks; Thu, 1 Oct 1998 08:23:15 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28348 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:23:11 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28694; Thu, 1 Oct 1998 12:29:08 -0300
Date: Thu, 1 Oct 1998 12:29:07 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19981001092359.00a2a820@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9810011215550.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Stefan Santesson wrote:
>Hi Ed,
>
>I'm just trying to understand what you are saying.
>
>Are what you are saying, that you would solve the problem generally by, for
>each issuer, having a different Issuer DN, per certificate type?
>Well I have thought of that for the SSL/TLS case but I don't like it.
Stefan:
;-)
May I remind you that you wrote:
I realize that today there is no way to do this without distributing
customized plug-in components to end-users
However, there are actually TWO ways, as I mentioned in my previous
postings, that do not involve plug-ins and do not need Javascript
either (btw, a security risk right there).
>Simply because many planned CA-services does not work that way and I'm not
>convinced that they should either.
;-) Simply because you perhaps want to make commercial CA-services
mandatory to Banks. However, that is neither needed to Banks nor
desirable security wise.
Further, if you want to name an objection, please do so. Generic
"does not work that way", without qualifying the "that" or why -- is
not useful in a discussion. SMTP carries only written words yet, not
thoughts ;-)
Can you be specific?
>
>The next question is, how do I use the SSL/TLS negotiation to pick the
>right certificate for creating a signed object in a Java script?
As I explained before, there are TWO ways to pick the intended
certificate and no other cert. However, pls consider abandoning
Javascripts to provide *functionality* -- even though JS may add
embellishments. Several major companies and security concerned
individuals do not use JS at all.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
-- Member of the Meta-Certificate Group -- http://www.mcg.org.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28184 for ietf-pkix-bks; Thu, 1 Oct 1998 08:09:10 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28180 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:09:08 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28677; Thu, 1 Oct 1998 12:15:22 -0300
Date: Thu, 1 Oct 1998 12:15:20 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: "Olle E. Johansson" <oej@webway.se>
cc: Stefan Santesson <stefan@accurata.se>, David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <36132C4B.8FB88F64@webway.se>
Message-ID: <Pine.LNX.4.02.9810011210380.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Olle E. Johansson wrote:
>Stefan Santesson wrote:
>
>> 1) In SSL the server may select preferred client certificate by Issuer DN,
>> and "certificate type"
>> 2) You suggest hashed SSN (social security numbers) using "salt"
>>
>Even if I don't know all the details in your scheme, I would like to put
>up a privacy warning here. A user might not want _any_ server to search
>the database of user certificates.
Olle:
As you can read in my previous full msg (where that part was taken
from), Stefan did not copy the following paragraph -- which I would
like to highlight and which fully answers your concern:
It is important to note that *if* the customer's browser fails to
authenticate the Bank's server, then this will generate a fatal
handshake-failure alert in SSL if the non-authenticated Bank still
tries to go into phase 2 above -- so, the second phase is privacy
protected by the first.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
-- Member of the Meta-Certificate Group -- http://www.mcg.org.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28135 for ietf-pkix-bks; Thu, 1 Oct 1998 08:03:47 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28128 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:03:38 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28673; Thu, 1 Oct 1998 12:09:59 -0300
Date: Thu, 1 Oct 1998 12:09:57 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Anders Rundgren <anders.rundgren@jaybis.com>
cc: "'Stefan Santesson'" <stefan@accurata.se>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <01BDED1A.E60F0AC0@HYDRA>
Message-ID: <Pine.LNX.4.02.9810011143170.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Anders Rundgren wrote:
>Hi Ed,
>>Your suggestion:
>>
>>The solution is to add "salt" -- like it is done in UNIX passwords.
>>For example, you can add 50 chars of salt or as many as you want -- a
>>passphrase. The point here is that since you know the SSN and the
>>salt, no one else can guess the SSN from a dictionary attack on only
>>9 digits. Better still, you can change the hash in a new cert and
>>keep the SSN constant, by changing the salt, so no one can verify
>>your SSN in a new cert without your cooperation.
>
>As my countryman Stefan already pointed out we can argue for centuries about the
>use of SSNs or as I would call them: PPIT - Persistent Personal Identity Tag.
>
>Assuming that you *actually* *have* *such* *a* *scheme* you loose all the benefits of
>PPITs by applying your "salted" methods to PPITs. PPITs are not only designed to
>make big-brothers job easier :-),
Anders:
I think you can call YAPITs (Yet Another Personal Information Token)
whatever you like and I will further grant anyone the right to make
his private information public -- IF he so desires. However, NOT by
design, which is what you apparently defend to allow as a legitimate
feature of a "security design". What you imply is similar to the
"rationale" for GAK-ware considerations.
> but to allow users to authenticate themselves
>using a valid certificate (be it electronical or physical) where the certificate
>receiver only must know what issuers (and domain) to trust.
>
This has nothing to do with YAPITs. It has to do with issuer trust
and key challenge-response.
I affirm that a certificate may only be its signature in size -- a 20
byte string -- and that suffices to allow anything you can do with
any kilobyte-size X509v3 cert, or even mega-byte size. So, YAPTIs do
not really belong to certs as a functional need. To ignore this is to
ignore what certificates are.
>This is a major benefit for
>all parties as you can have a life-time password/userid replacement with
>full security (technically speaking) independent on actual certificate.
You are unfortunately fully mistaken. What you describe is similar to
Faustus' dilemma: your security now versus your soul forever. Well,
we all know how it ends. You cannot trade your life-long privacy in
exchange for some degree of security now.
> It simply
>cuts costs and confusion (at the expense of personal integrity).
If an expense cannot be paid back (as privacy cannot) then it is not
an expense -- it is called a loss, in any country and possibly also
in yours as you speak about your countryman above.
I'd rather think non-parochially and strive to find and define
methods which assert equal security rights -- irrespective of
computational power, influence or supplier.
> If this is
>good or not is something the market (and in some cases national laws)
>will decide. My personal opinion is that if successful PKIs (Stefan!) are
>established based on PPITs the disbeliveers *may* change their mind.
>
Each country/company/person can do as they please, but in a
competitive world market the one with least information exposure has
a large advantadge. BTW, is that not what security is all about ? ;-)
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27722 for ietf-pkix-bks; Thu, 1 Oct 1998 07:14:37 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27718 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 07:14:36 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA05486; Thu, 1 Oct 1998 10:21:11 -0400 (EDT)
Message-Id: <199810011421.KAA05486@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-roadmap-00.txt
Date: Thu, 01 Oct 1998 10:21:11 -0400
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
--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 PKIX Roadmap
Author(s) : A. Arsenault, S. Turner
Filename : draft-ietf-pkix-roadmap-00.txt
Pages : 26
Date : 30-Sep-98
This document provides an overview or 'roadmap' of the work done by the
IETF PKIX working group. It describes some of the terminology used in
the working group's documents, and the theory behind an X.509-based PKI.
It identifies each document developed by the PKIX working group, and
describes the relationships among the various document. It also
provides advice to would-be PKIX implementors about some of the issues
discussed at length during PKIX development, in hopes of making it
easier to build implementations that will actually interoperate.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-roadmap-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-00.txt
Internet-Drafts directories are located at:
Africa: ftp.is.co.za
Europe: ftp.nordu.net
ftp.nis.garr.it
Pacific Rim: munnari.oz.au
US East Coast: ftp.ietf.org
US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ietf.org. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-roadmap-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: <19980930102705.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-roadmap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-roadmap-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19980930102705.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27202 for ietf-pkix-bks; Thu, 1 Oct 1998 06:06:39 -0700 (PDT)
Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27198 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 06:06:38 -0700 (PDT)
Received: from xedia.com by relay4.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfjfg19152; Thu, 1 Oct 1998 09:11:52 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08642; Thu, 1 Oct 98 09:10:28 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA00124; Thu, 1 Oct 1998 09:11:37 -0400
Date: Thu, 1 Oct 1998 09:11:37 -0400
Message-Id: <199810011311.JAA00124@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: egerck@laser.cps.softex.br
Cc: ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com> <Pine.LNX.4.02.9810010015150.25643-100000@laser.cps.softex.br>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>>>>> "Ed" == Ed Gerck <egerck@laser.cps.softex.br> writes:
Ed> On Thu, 1 Oct 1998, Stefan Santesson wrote:
>>...
>> You and I can argue for centuries if certificates handled in
>> browsers should, or should not, be allowed to contain SSN.
Ed> No, I don't argue. As I wrote two msgs ago, some think they have
Ed> valid reasons for it and I do not disagree with the need to
Ed> preserve freedom.
Unfortunately, the world (or at least the country) is infested with
organizations that think they have a valid reason to ask for a SSN
when in fact they have neither a valid reason nor any legal authority
to do so. Some, if you pound on the table enough, will yield. (For
example, my medical insurance started by asking for it, but when
pushed conceded that they could make up a number instead. Surprised
me; most outfits of that type don't have enough sense to see that.)
So I would say that anything protocol mechanism that encourages this
sort of abuse is evil and must be resisted.
paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27094 for ietf-pkix-bks; Thu, 1 Oct 1998 05:52:12 -0700 (PDT)
Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27090 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 05:52:10 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id OAA17953; Thu, 1 Oct 1998 14:59:15 +0200 (CEST)
Received: from stefans (t1o68p66.telia.com [62.20.138.66]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA11341; Thu, 1 Oct 1998 14:59:10 +0200 (CEST)
Message-Id: <3.0.32.19981001145537.00a3a4e0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 14:56:18 +0200
To: Andreas Berger <aberger@darmstadt.gmd.de>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA27091
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
There are similarities with phone numbers, but an even better example is to
compare with plastic cards in your wallet.
Say that every plastic card is a certificate given to you to be used in a
certain context. When you by gas you use your petrol card, when you borrow
books you use your library card.
The service context determines which certificate (plastic) you are using.
In a computer environment this is the same. Depending on the service
context you will use different certificates and different private keys for
signatures and decryption.
To day there is no "good" way to communicate the "service context" to the
certificate selecting function in the client. What is proposed here is that
we define a mechanism for this so that a context aware server may help the
client to select a suitable certificate.
This is relevant for a wide range of application and service levels, from
communication services (SSL/TLS) up to application levels (S/MIME and Java
scripts). But regardless of implementation level a general data type could
be used to specify the certificate match rule. X.509 have defined 2
relevant match rules. certificateMatch and certificateExactMatch.
So all we basically have to do is to convince the TLS, S/MIME and Java
peoples to include this in their protocols and client-server products.
/Stefan
At 01:52 PM 10/1/98 +0100, Andreas Berger wrote:
>Is the problem of selecting certificates somewhat similar to the
>selection of telephone numbers?
>
>Example:
>
>have an application select a FAX number for my home phone from an
>address book entry. The numbers itself (the certificate) cannot be
>distinguished from other numbers, it is the attribute name "FAX, home"
>(or something like this) that shows the designated use of the number.
>
>A little difference exists, in that certificates usually contain some
>information about the intended use. But this information is not encoded
>in a uniform way. The decision is usually left to the application (which
>is the problem to be solved here?).
>
>Andreas
>--
>Fifty-three percent of Fortune 1000 executives think the
>Arch Deluxe is something that helps to run a computer.
>-- Jericho Communications
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA26677 for ietf-pkix-bks; Thu, 1 Oct 1998 04:46:34 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA26673 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 04:46:32 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-venedig [141.12.33.63]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id NAA05623; Thu, 1 Oct 1998 13:52:26 +0200 (MET DST)
Message-ID: <36137B2B.2ABE314@darmstadt.gmd.de>
Date: Thu, 01 Oct 1998 13:52:59 +0100
From: Andreas Berger <aberger@darmstadt.gmd.de>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Stefan Santesson <stefan@accurata.se>
CC: Ed Gerck <egerck@laser.cps.softex.br>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19981001092359.00a2a820@m1.403.telia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Is the problem of selecting certificates somewhat similar to the
selection of telephone numbers?
Example:
have an application select a FAX number for my home phone from an
address book entry. The numbers itself (the certificate) cannot be
distinguished from other numbers, it is the attribute name "FAX, home"
(or something like this) that shows the designated use of the number.
A little difference exists, in that certificates usually contain some
information about the intended use. But this information is not encoded
in a uniform way. The decision is usually left to the application (which
is the problem to be solved here?).
Andreas
--
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21470 for ietf-pkix-bks; Thu, 1 Oct 1998 00:20:30 -0700 (PDT)
Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21464 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 00:20:28 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id JAA01602; Thu, 1 Oct 1998 09:27:32 +0200 (CEST)
Received: from stefans (t1o68p117.telia.com [62.20.138.117]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id JAA02214; Thu, 1 Oct 1998 09:27:31 +0200 (CEST)
Message-Id: <3.0.32.19981001092359.00a2a820@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 09:24:36 +0200
To: Ed Gerck <egerck@laser.cps.softex.br>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA21467
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Ed,
I'm just trying to understand what you are saying.
Are what you are saying, that you would solve the problem generally by, for
each issuer, having a different Issuer DN, per certificate type?
Well I have thought of that for the SSL/TLS case but I don't like it.
Simply because many planned CA-services does not work that way and I'm not
convinced that they should either.
The next question is, how do I use the SSL/TLS negotiation to pick the
right certificate for creating a signed object in a Java script?
/Stefan
At 12:48 AM 10/1/98 -0300, Ed Gerck wrote:
>On Thu, 1 Oct 1998, Stefan Santesson wrote:
>
>>Ed,
>>
>>Thank you for very interesting input. If I may try a very compressed sum of
>>your discussion it would be:
>>
>>1) In SSL the server may select preferred client certificate by Issuer DN,
>>and "certificate type"
>
>Stefan:
>
>pls add in your 1) "if the server is non-anonymous"
>
>pls add also a 0) "a self-signed common CA cert for the server and
>user certs can make your life and the customer's life a lot more
>pleasant"
>
>>2) You suggest hashed SSN (social security numbers) using "salt"
>
>if you must add SSN-based info in a public cert, IMO yes!
>
>>
>>Regarding "certificate type" I can't find this as an active selection
>>mechanism. It is however mentioned as prerequisite that the certificate
>>type have to match the selected key exchange algorithm.
>>
>
>I fail to see why you "can't find this as an active selection
>mechanism" together with the issuer DN, even if you want to keep the
>same type for your repudiable and non-repudiable cases (which I
>possibly would not, but that is another story). As I wrote:
>
>>> (for higher security) with a different CA cert for each type.
>
>and, again, later in the same msg:
>
>>> Or, for higher security, the Bank can use different CA certs for
>>> each type and send their DNs accordingly, in each case.
>>>
>
>so, all you need is to have different "types" (ie, DNs) of CA certs,
>where both "types" should be signed by the same root CA cert of
>course and the public-key root CA cert should be included in the
>distribution.
>
>Can you pls explain what causes selection difficulties for you in the
>above scenario?
>
>>Regardless of this I fail to see how this can be used to pick the right
>>"non-repudiation" certificate in the Java script application.
>
>Please read above, I hope it is clearer now.
>
>> I also fail
>>to understand if you suggest that the current SSL/TLS functions solves all
>>my problems or just a part of them.
>>
>
>;-) If "all your problems" is what you stated, sure, all at one stop.
>
>>Do you suggest that a more general matching mechanism is not needed?
>>
>
>If the problem is what you defined, yes.
>
>>/Stefan
>>
>>P.s
>>Regarding hashed SSN with salt, I don't get how the "salt" solves this. If
>>the salt is unknown then the SSN can't be checked and if the salt is known
>>the dictionary attack is still possible.
>
>
>1. The salt is only known to those entities that should know the SSN
>-- not to the evildoer that is trying to get SSNs from a list of
>cached client certs, in a common access area or in memory.
>
>2. the salt is treated as client's private information -- and kept
>separate from the cert, in a protected area together with other
>private information from the client.
>
>BTW, this is similar to "dividing" a SSN "signature" into two parts,
>one public (in the cert) and another private (the salt).
>
>> I would say that your "salt" is
>>equal to suggest that the SSN should be encrypted with a secret key (where
>>the "salt" is being that secret key).
>>
>
>Yes, certainly -- but it is more appropriately called a keyed-MAC.
>
>BTW, I am glad that you now repudiate your phrase after your P.s
>above ;-)
>
>
>>You and I can argue for centuries if certificates handled in browsers
>>should, or should not, be allowed to contain SSN.
>
>No, I don't argue. As I wrote two msgs ago, some think they have
>valid reasons for it and I do not disagree with the need to preserve
>freedom. In that, I follow the C maxim -- even though I think that
>security work is perhaps not the best place to leave enough rope so
>that you may hang yourself with it if you so want or don't think it
>is dangerous...
>
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
>http://novaware.cps.softex.br
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA20810 for ietf-pkix-bks; Thu, 1 Oct 1998 00:08:22 -0700 (PDT)
Received: from maila.telia.com (root@[194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA20802 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 00:08:20 -0700 (PDT)
Received: from webway.se (t3o61p28.telia.com [195.67.228.148]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id JAA16567; Thu, 1 Oct 1998 09:14:16 +0200 (CEST)
Message-ID: <36132C4B.8FB88F64@webway.se>
Date: Thu, 01 Oct 1998 09:16:27 +0200
From: "Olle E. Johansson" <oej@webway.se>
Organization: WebWay AB
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <stefan@accurata.se>
CC: Ed Gerck <egerck@laser.cps.softex.br>, David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Stefan Santesson wrote:
> 1) In SSL the server may select preferred client certificate by Issuer DN,
> and "certificate type"
> 2) You suggest hashed SSN (social security numbers) using "salt"
>
Even if I don't know all the details in your scheme, I would like to put
up a privacy warning here. A user might not want _any_ server to search
the database of user certificates. The user might have certificates he
doesn't want a server, or rather the company running the server, to know
about.
It's like cookies...
Regards,
Olle
--
Olle E. Johansson, oej@webway.se
Mobile +46 70 593 68 51, phone +46 8 590 722 40, fax +46 8 590 759 80
WebWay AB, Sweden, http://www.webway.se
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA20776 for ietf-pkix-bks; Thu, 1 Oct 1998 00:07:30 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA20772 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 00:07:24 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA26790; Thu, 1 Oct 1998 09:13:46 +0200
Received: by HYDRA with Microsoft Mail id <01BDED1A.E60F0AC0@HYDRA>; Thu, 1 Oct 1998 09:07:22 +0200
Message-ID: <01BDED1A.E60F0AC0@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Ed Gerck'" <egerck@laser.cps.softex.br>, "'Stefan Santesson'" <stefan@accurata.se>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 09:07:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Ed,
>Your suggestion:
>
>The solution is to add "salt" -- like it is done in UNIX passwords.
>For example, you can add 50 chars of salt or as many as you want -- a
>passphrase. The point here is that since you know the SSN and the
>salt, no one else can guess the SSN from a dictionary attack on only
>9 digits. Better still, you can change the hash in a new cert and
>keep the SSN constant, by changing the salt, so no one can verify
>your SSN in a new cert without your cooperation.
As my countryman Stefan already pointed out we can argue for centuries about the
use of SSNs or as I would call them: PPIT - Persistent Personal Identity Tag.
Assuming that you *actually* *have* *such* *a* *scheme* you loose all the benefits of
PPITs by applying your "salted" methods to PPITs. PPITs are not only designed to
make big-brothers job easier :-), but to allow users to authenticate themselves
using a valid certificate (be it electronical or physical) where the certificate
receiver only must know what issuers (and domain) to trust. This is a major benefit for
all parties as you can have a life-time password/userid replacement with
full security (technically speaking) independent on actual certificate. It simply
cuts costs and confusion (at the expense of personal integrity). If this is
good or not is something the market (and in some cases national laws)
will decide. My personal opinion is that if successful PKIs (Stefan!) are
established based on PPITs the disbeliveers *may* change their mind.
The general-purpose browser solution is as follows:
The authenticating server may surely *suggest* a list of possible certificate types
that it may accept because it is always *you* (the user) that should manually
select the proper one. In case you feel that a cert with PPIT could create a disaster
if you accidentally gave it to a wrong server the solution would be to have a local
(user-defined) set of valid servers (i.e. their public keys).
To insert a new server would require a few more clicks. I.e. similar to ActiveX
controls or signed Java Applets. Such servers would typically be
governmental (who gave you the PPIT) and a *few* other parties that
you hopefully trust like your bank or employer. A similar scheme could be used
for defining a list of valid receivers of mail signed with a cert containing an PPIT
(or other sensitive information).
Anders Rundgren
Senior Internet E-commerce Architect
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA23903 for ietf-pkix-bks; Sat, 31 Oct 1998 12:44:38 -0800 (PST)
Received: from revnet4.revnet.com (revnet4.revnet.com [198.51.35.125]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA23899 for <ietf-pkix@imc.org>; Sat, 31 Oct 1998 12:44:37 -0800 (PST)
From: scj2@gs4.revnet.com
Received: from gs4.revnet.com (gs4.revnet.com [198.51.35.84]) by revnet4.revnet.com (8.8.7/8.8.7) with SMTP id OAA31179; Sat, 31 Oct 1998 14:42:43 -0600
Message-Id: <199810312042.OAA31179@revnet4.revnet.com>
To: scj2@gs4.revnet.com
Subject: ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent
Date: Sat, 31 Oct 1998 14:47:10 -0600
Originator: scj2@gs4.revnet.com
X-Mailer: GroupMaster
X-Mailer-Version: 1.5
X-GroupMasterUser: Revnet Express
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Please open the following message in your web browser
http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML
____________________________________________________________
International Shoe Manufacturing Corp Update:
International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage
financing to begin full-scale production at its plants in India. The $4.75 million is being
used to purchase the final equipment needed to begin production at the companys existing
plant in India. With equipment in place, the company projects net profits of over $25
million a year within two years.
The company stated that the financing will be followed up by a $9 million dollar IPO in
India, anticipated for March 1999. The IPO will be handled by underwriters in India, and
will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the
IPO will pay off the $4.75 million dollar financing. The balance will be used for the
acquisition of additional shoe manufacturing.
ISHO is in the business of manufacturing athletic footwear for the worlds leading shoe
companies. It owns a 23,000-square-foot plant located in the protected free trade zone in
Noida, just outside of New Delhi, India, where skilled labor is plentiful and very
inexpensive. The Indian government recently developed new economic policy to attract
foreign investment that is export-oriented, and could employ large numbers of people.
ISM is the only athletic shoe manufacturer in India directed toward the international
market. It currently has contracts with Adidas and The Pentland Group. These two
companies have agreed to purchase all the shoes ISM can manufacture.
The athletic shoe industry is estimated at $14.25 billion a year. The worlds leading shoe
companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design
and marketing organizations that spend hundreds of millions of dollars a year getting their
products sold. They then rely on others to manufacture to their specifications. Almost, if
not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of
millions of dollars spent on advertising by the name-brand companies. The result is an
open purchase order where such manufacturers literally can sell every pair of shoes they
can produce. A business like this lends itself to being privately held due to the large cash
flow allowing for internal financing. International Shoe Manufacturing Corp. is the only
company known to exist that offers a public investor the opportunity to own a share of this
highly lucrative business in a pure investment play.
For inquiries please contact the office of the director of investor relations toll free at:
877-ISM-CORP (877-476-2677) or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately. Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752
Please visit ISMs web site at www.ismcorp.net
Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press
release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of
1995. Forward-looking statements involve known and unknown risks and uncertainties which may cause the companys actual
results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things,
product price volatility, product demand, market competition, risk inherent in the companys domestic and international operations,
imprecision in estimating product reserves and the companys ability to replace and expand its holdings.
____________________________________________________________
Unsubscribe or access your membership settings at:
http://gs4.revnet.com/GMG/ctrlpanel/0/79
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27950 for ietf-pkix-bks; Fri, 30 Oct 1998 15:48:46 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27946 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 15:48:45 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id SAA00163; Fri, 30 Oct 1998 18:51:07 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id SAA09153; Fri, 30 Oct 1998 18:51:04 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AD.0082A38C ; Fri, 30 Oct 1998 18:46:55 -0500
X-Lotus-FromDomain: FDC
To: Al Arsenault <aarsenault@spyrus.com>
cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Bill Burr'" <william.burr@nist.gov>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Message-ID: <882566AD.006B35F7.00@lnsunr02.firstdata.com>
Date: Fri, 30 Oct 1998 15:48:03 -0800
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
while the current common certificate infrastructure model is SSL ... which
baiscally checks if the certificate has been manufactored by somebody in
the list of known certificate manufactors/issuers (aka CAs) .... the common
authentication model on the internet is logging on to the service provider.
This one is basically somebody signs up for an account and establishes a
password. When they want to use the internet ... they contact the router,
give their account name and proof of password. The router is likely running
something like radius ... in which case it forwards the account name and
password to an account authenticator.
For PKIX to address the most fundamental of internet authentication
requirements ... could involve the ISP issuing a relying party certificate
with just the account name (sidestepping liability and privacy issues). The
choice now would be would the ISP router accept the certificate
authentication at face-value ... or would it use a PKI flavor of radius to
contact an account authenticator .... for instance to have more timely
information on whether the account is in good standing.
This is possibly the most fundamental current internet requirement ... and
it illustrates again the extremely short step from relying party
certificates to the AADS model ... where if the account has to be touched
as part of the authentication/authoritization ... then it is easily shown
that shipping the certificate with the transaction is superfulous (if
somebody gives you a copy of something .... how many million times do you
have to send the same copy back to them ... before they realize that they
don't have to see the copy if they are already looking at the original
stored in the account record).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27693 for ietf-pkix-bks; Fri, 30 Oct 1998 15:03:12 -0800 (PST)
Received: from cane.deming.com (mail.smime.org [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA27689; Fri, 30 Oct 1998 15:03:11 -0800 (PST)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Fri, 30 Oct 98 15:04:52 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.smime.org with Internet Mail Service (5.5.1960.3) id <VLN0Z7AH>; Fri, 30 Oct 1998 15:04:52 -0800
Message-ID: <01FF24001403D011AD7B00A024BC53C53A72A2@mail.smime.org>
From: "Blake Ramsdell" <BlakeR@deming.com>
To: "'Russ Housley'" <housley@spyrus.com>, "Robert Klerer" <klerer@xhair.com>
cc: <ietf-pkix@imc.org>, <ietf-smime@imc.org>
Subject: RE: email oid
Date: Fri, 30 Oct 1998 15:04:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
X-WSS-ID: 1A24999E55968-01-01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> -----Original Message-----
> From: Russ Housley [mailto:housley@spyrus.com]
> Sent: Thursday, October 29, 1998 5:39 PM
> To: Robert Klerer
> Cc: ietf-pkix@imc.org; ietf-smime@imc.org
> Subject: Re: email oid
>
> It is my understanding that the PKCS#9 OID is widely used in S/MIME v2
> implementations.
I have never seen anything other than the PKCS#9 OID used in S/MIME v2.
For the S/MIME camp this is not ambiguous at all.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA27278 for ietf-pkix-bks; Fri, 30 Oct 1998 13:46:15 -0800 (PST)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27274 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:46:14 -0800 (PST)
Received: from klerer.basit.com (shiva113 [128.209.144.113]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id QAA19715; Fri, 30 Oct 1998 16:47:07 -0500 (EST)
Message-ID: <006f01be044e$f2061e40$010ed180@klerer.basit.com>
From: "Robert Klerer" <klerer@xhair.com>
To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>, "'Russ Housley'" <housley@spyrus.com>
Cc: "'ietf-pkix'" <ietf-pkix@imc.org>, <John.Wang@CyberTrust.GTE.Com>
Subject: Re: email oid
Date: Fri, 30 Oct 1998 16:47:50 -0500
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 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sue,
Adding the additional OID would not be the optimum solution. Since if I
have an RDN of EA=klerer@xhair.com, am I referring to the RFC822mailbox or
the pkcs-9 address? Whichever choice will be wrong sometimes -- hence the
problem. pkix should NOT perpetuate the problem by again calling the same
thing two different names.
Robert
-----Original Message-----
From: Miklos, Sue A. <samiklo@missi.ncsc.mil>
To: 'Russ Housley' <housley@spyrus.com>
Cc: 'ietf-pkix' <ietf-pkix@imc.org>; 'klerer@xhair.com' <klerer@xhair.com>;
'John.Wang@CyberTrust.GTE.Com' <John.Wang@CyberTrust.GTE.Com>
Date: Friday, October 30, 1998 2:34 PM
Subject: RE: email oid
>Russ, and others, may I then request that it be included or is that not
>possible?
>
>Sandi
>
>>----------
>>From: Russ Housley[SMTP:housley@spyrus.com]
>>Sent: Friday, October 30, 1998 1:35 PM
>>To: Miklos, Sue A.
>>Cc: 'ietf-pkix'; 'klerer@xhair.com'; 'John.Wang@CyberTrust.GTE.Com'
>>Subject: Re: email oid
>>
>>Sandi:
>>
>>"Remain" is the issue. It is not in PKIX part 1!
>>
>>Russ
>>
>>
>>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>>All,
>>>In the specifications for the schema for an international defense
>>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>>registered
>>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>>I would like to request that this remain in whatever documentation you
>>>develop.
>>>
>>>Thanks,
>>>Sandi Miklos
>>>>
>>>>
>>>>----------
>>>>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>>To: 'Robert Klerer'; ietf-pkix@imc.org
>>>>Subject: RE: email oid
>>>>
>>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>>if there is a demand for it.
>>>>
>>>>-----Original Message-----
>>>>From: Robert Klerer [mailto:klerer@xhair.com]
>>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>>To: ietf-pkix@imc.org
>>>>Subject: email oid
>>>>
>>>>
>>>>The other day in trying to accommodate a legacy pki, I ran into a
problem
>>>>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1
>>>>specifies
>>>>that the oid used for an email address in the distinguished name is
>>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet
mail
>>>>as specified in RFC1274.
>>>>
>>>>Since I believe that the intention is for both of these oids are meant
to
>>>>represent attributes that hold the same information, this discrepancy
may
>>>>cause confusion and failures in the future. My suggestion would be to
>>>>change part1 to refer to the more commonly used OID.
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA27192 for ietf-pkix-bks; Fri, 30 Oct 1998 13:37:24 -0800 (PST)
Received: from mail.innetix.com (oldmail.innetix.com [207.126.108.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA27188 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:37:23 -0800 (PST)
Received: from iris (user7.sj.dialup.innetix.com [209.172.68.70]) by mail.innetix.com (8.8.7/8.8.5) with SMTP id NAA28300; Fri, 30 Oct 1998 13:31:15 -0800 (PST)
Message-Id: <3.0.2.32.19981030133102.006d8b48@innetix.com>
X-Sender: bruceg@innetix.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32)
Date: Fri, 30 Oct 1998 13:31:02 -0800
To: helm@fionn.es.net, ietf-pkix@imc.org
From: Bruce Greenblatt <bruceg@innetix.com>
Subject: Re: Scale (and the SRV record)
In-Reply-To: <199810301749.JAA18064@fionn.es.net>
References: <Your message of "Fri, 30 Oct 1998 10:25:55 MST." <s639943d.073@prv-mail25.provo.novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
At 09:49 AM 10/30/98 -0800, Michael Helm wrote:
[snip]
>Arguments made in this vein seem convincing to me -- convincing
>that you need signed operations & a very hi standard of integrity,
[snip]
...
For signed operations, you might want to take a look at the Signed
Operations draft of the LDAP Extensions WG
(http://info.internet.isi.edu:80/0/in-drafts/files/draft-ietf-ldapext-sigops
-03.txt). Constructive comments are always welcome. Please post them in
the appropriate mailing list though (i.e. not this one), or privately to
the authors (e.g. me).
Bruce
================================================
Bruce Greenblatt bruceg@innetix.com
http://www.innetix.com/~bruceg
================================================
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25580 for ietf-pkix-bks; Fri, 30 Oct 1998 10:42:25 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25575 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 10:42:24 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA08535 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:44:45 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id NAA08530 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:44:45 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id NAA22393 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:43:50 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000336409@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:44:39 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BE040B.713A2560@avenger.missi.ncsc.mil>; Fri, 30 Oct 1998 13:44:40 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981030184439Z-3919@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'Russ Housley'" <housley@spyrus.com>
Cc: "'ietf-pkix'" <ietf-pkix@imc.org>, "'klerer@xhair.com'" <klerer@xhair.com>, "'John.Wang@CyberTrust.GTE.Com'" <John.Wang@CyberTrust.GTE.Com>
Subject: RE: email oid
Date: Fri, 30 Oct 1998 13:44:39 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Russ, and others, may I then request that it be included or is that not
possible?
Sandi
>----------
>From: Russ Housley[SMTP:housley@spyrus.com]
>Sent: Friday, October 30, 1998 1:35 PM
>To: Miklos, Sue A.
>Cc: 'ietf-pkix'; 'klerer@xhair.com'; 'John.Wang@CyberTrust.GTE.Com'
>Subject: Re: email oid
>
>Sandi:
>
>"Remain" is the issue. It is not in PKIX part 1!
>
>Russ
>
>
>At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>>All,
>>In the specifications for the schema for an international defense
>>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>>registered
>>in RFC 1274. This attribute was also called mail in one Internet Draft.
>>I would like to request that this remain in whatever documentation you
>>develop.
>>
>>Thanks,
>>Sandi Miklos
>>>
>>>
>>>----------
>>>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>>>Sent: Thursday, October 29, 1998 9:17 AM
>>>To: 'Robert Klerer'; ietf-pkix@imc.org
>>>Subject: RE: email oid
>>>
>>>It was my understanding that the RSA-pkcs-9 email address OID
>>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>>if there is a demand for it.
>>>
>>>-----Original Message-----
>>>From: Robert Klerer [mailto:klerer@xhair.com]
>>>Sent: Thursday, October 29, 1998 8:19 AM
>>>To: ietf-pkix@imc.org
>>>Subject: email oid
>>>
>>>
>>>The other day in trying to accommodate a legacy pki, I ran into a problem
>>>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1
>>>specifies
>>>that the oid used for an email address in the distinguished name is
>>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>>>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>>>as specified in RFC1274.
>>>
>>>Since I believe that the intention is for both of these oids are meant to
>>>represent attributes that hold the same information, this discrepancy may
>>>cause confusion and failures in the future. My suggestion would be to
>>>change part1 to refer to the more commonly used OID.
>>>
>>>
>>>
>>>
>>>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25487 for ietf-pkix-bks; Fri, 30 Oct 1998 10:34:30 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25483 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 10:34:29 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA12998; Fri, 30 Oct 1998 10:36:17 -0800 (PST)
Message-Id: <4.1.19981030133442.0099ded0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 13:35:10 -0500
To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
From: Russ Housley <housley@spyrus.com>
Subject: Re: email oid
Cc: "'ietf-pkix'" <ietf-pkix@imc.org>, "'klerer@xhair.com'" <klerer@xhair.com>, "'John.Wang@CyberTrust.GTE.Com'" <John.Wang@CyberTrust.GTE.Com>
In-Reply-To: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981030165333Z-3800@avenge r.missi.ncsc.mil>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sandi:
"Remain" is the issue. It is not in PKIX part 1!
Russ
At 11:53 AM 10/30/98 -0500, Miklos, Sue A. wrote:
>All,
>In the specifications for the schema for an international defense
>system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
>registered
>in RFC 1274. This attribute was also called mail in one Internet Draft.
>I would like to request that this remain in whatever documentation you
>develop.
>
>Thanks,
>Sandi Miklos
>>
>>
>>----------
>>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>>Sent: Thursday, October 29, 1998 9:17 AM
>>To: 'Robert Klerer'; ietf-pkix@imc.org
>>Subject: RE: email oid
>>
>>It was my understanding that the RSA-pkcs-9 email address OID
>>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>>think you can remove the RSA oid but perhaps add the RFC1274 oid
>>if there is a demand for it.
>>
>>-----Original Message-----
>>From: Robert Klerer [mailto:klerer@xhair.com]
>>Sent: Thursday, October 29, 1998 8:19 AM
>>To: ietf-pkix@imc.org
>>Subject: email oid
>>
>>
>>The other day in trying to accommodate a legacy pki, I ran into a problem
>>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
>>that the oid used for an email address in the distinguished name is
>>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>>as specified in RFC1274.
>>
>>Since I believe that the intention is for both of these oids are meant to
>>represent attributes that hold the same information, this discrepancy may
>>cause confusion and failures in the future. My suggestion would be to
>>change part1 to refer to the more commonly used OID.
>>
>>
>>
>>
>>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25233 for ietf-pkix-bks; Fri, 30 Oct 1998 10:00:03 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25226 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:59:58 -0800 (PST)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id KAA18838 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 10:02:20 -0800 (PST)
Message-Id: <199810301802.KAA18838@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Fri, 30 Oct 1998 15:29:04 GMT." <199810301657.QAA22890@ns0.zergo.com>
Date: Fri, 30 Oct 1998 10:02:19 -0800
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
GBland@zergo.com writes:
> Could purchasing software from Microsoft (or Netscape or other) be
> regarded as an authentication mechanism and secure distribution
> mechanism for certificates.
Getting the CD would be, perhaps....
> > From: MHenry [mailto:MHenry@PEC.com]
> > interestingly enough, the largest base of existing
> > pki users (those that have browsers with a hard coded
> > certs at time of purchase) do, regularly, exactly what you take for
> > granted they would never do.=20
I think that the netscape online distribution of the 128-bit
browsers is done thru an ssl connection (& a verisign
certificate for their server). Somewhere along the line,
tho, you got a browser with a verisign CA cert via a connection
that wasn't "authenticated" in this fashion! (NB: It may be that
the software download switches over to non ssl after you pledge
allegiance.)
The IE distribution is different. For windows the browser itself
& related tools is done non-SSL, & you download a separate 128-bit
kit for some other part of 9*/NT via SSL. So the built-in certs are
delivered in a non-authenticated fashion. For Solaris (the
last time I tried this) you get a new 128-bit browser securely,
so the certs are delivered in an authenticated fashion.
(Same comment about browser applies as above.)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA25072 for ietf-pkix-bks; Fri, 30 Oct 1998 09:47:17 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA25067 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:47:12 -0800 (PST)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id JAA18064 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:49:30 -0800 (PST)
Message-Id: <199810301749.JAA18064@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Fri, 30 Oct 1998 10:25:55 MST." <s639943d.073@prv-mail25.provo.novell.com>
Date: Fri, 30 Oct 1998 09:49:30 -0800
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
"Tolga Acar" writes:
> >up for an attack based on a single (or small integer number) point
> >of failure? For example maybe I could trick you into using
> Violation of integrity on the victim's side.
> if you ruin the baseline (integrity), and expect to be secure. can't do it.
> besides, this will hurt that particular victim, not others.
...
> insecurity is coming from the lack of integrity, so called "less reliable".
> you have to have them both: security and integrity. If one is missing, you can't have the other.
Arguments made in this vein seem convincing to me -- convincing
that you need signed operations & a very hi standard of integrity,
as put here, in the services that provide portions of the pki, even if it
seems unnecessary from a theoretical point of view. You never
can tell what a security breach will escalate into, & the
secureness or integrity of the potential victims is almost always
very questionable given the large number of variables (software,
protocol vulnerabilities, social engineering) that most of us
potential victims are subject to.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24969 for ietf-pkix-bks; Fri, 30 Oct 1998 09:34:46 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24941; Fri, 30 Oct 1998 09:32:49 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id JAA11982; Fri, 30 Oct 1998 09:34:08 -0800 (PST)
Message-Id: <4.1.19981029203817.0092fd20@mail.spyrus.com>
Message-Id: <4.1.19981029203817.0092fd20@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 29 Oct 1998 20:39:10 -0500
To: "Robert Klerer" <klerer@xhair.com>
From: Russ Housley <housley@spyrus.com>
Subject: Re: email oid
Cc: ietf-pkix@imc.org, ietf-smime@imc.org
In-Reply-To: <001201be033e$a3e06380$010ed180@klerer.basit.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
It is my understanding that the PKCS#9 OID is widely used in S/MIME v2
implementations.
Russ
At 08:18 AM 10/29/98 -0500, Robert Klerer wrote:
>The other day in trying to accommodate a legacy pki, I ran into a problem
>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
>that the oid used for an email address in the distinguished name is
>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>as specified in RFC1274.
>
>Since I believe that the intention is for both of these oids are meant to
>represent attributes that hold the same information, this discrepancy may
>cause confusion and failures in the future. My suggestion would be to
>change part1 to refer to the more commonly used OID.
>
>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24929 for ietf-pkix-bks; Fri, 30 Oct 1998 09:32:12 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24925 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:32:11 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id JAA11957; Fri, 30 Oct 1998 09:34:00 -0800 (PST)
Message-Id: <4.1.19981029202203.009f8450@mail.spyrus.com>
Message-Id: <4.1.19981029202203.009f8450@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 29 Oct 1998 20:25:20 -0500
To: salzr@certco.com
From: Russ Housley <housley@spyrus.com>
Subject: RE: Scale (and the SRV record)
Cc: ietf-pkix@imc.org
In-Reply-To: <29E0A6D39ABED111A36000A0C99609CA18D2FA@macertco-srv1.ma.ce rtco.com>
References: <000a01be0352$2b946660$c807a8c0@pbaker-pc.verisign.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
This vulnerability cannt be completely eliminated. The CA's policy
determines the amount of risk associated with the frequency of CRL
issuance. Even if a fresh CRL is posted prior ti the earlier on expiring,
clinets may obtain the older one from a cache.
OCSP was supposed to address this concern. But, even OCSP does not get a
fresh answer for every query. Without a protocol that goes all the way to
the CA for a fresh response for every query, this vulnerability cannot be
eliminated.
Russ
At 01:59 PM 10/29/98 -0500, salzr@certco.com wrote:
>>If someone spoofed DNS the worst that would happen is that I would
>>recieve a certificate I didn't trust (and would ignore) or no >certificate
>at all.
>
>Well, if you're only fetching certificates, probably.
>
>But if you're fetching CRL's, then no. Suppose a cert is compromised,
>and CRLn is issued before the "next update" time purely because of
>that compromise. The adversary could spoof DNS and just send out
>the valid, but outdated CRL(n-1) and potentially have quite a
>window of opportunity.
> /r$
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24866 for ietf-pkix-bks; Fri, 30 Oct 1998 09:24:47 -0800 (PST)
Received: from orm-mail20.provo.novell.com (orm-mail20.orem.novell.com [151.155.118.32]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA24862 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:24:46 -0800 (PST)
Received: from INET-ORM-Message_Server by orm-mail20.provo.novell.com with Novell_GroupWise; Fri, 30 Oct 1998 10:26:09 -0700
Message-Id: <s6399441.007@orm-mail20.provo.novell.com>
X-Mailer: Novell GroupWise 5.5
Date: Fri, 30 Oct 1998 10:25:55 -0700
From: "Tolga Acar" <TACAR@novell.com>
To: <helm@fionn.es.net>, <ietf-pkix@imc.org>
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id JAA24863
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>>> Michael Helm <helm@fionn.es.net> 10/30/98 10:05:09 >>>
>This is theoretically true, but then, aren't you setting yourself
>up for an attack based on a single (or small integer number) point
>of failure? For example maybe I could trick you into using
>a bad certificate database (by breaking into a login of yours
>somewhere & trojanning your personal software) but I may not
Violation of integrity on the victim's side.
if you ruin the baseline (integrity), and expect to be secure. can't do it.
besides, this will hurt that particular victim, not others.
>On the other hand, would price would we pay for this complexity?
>Would we somehown make operations more insecure and/or less reliable?
insecurity is coming from the lack of integrity, so called "less reliable".
you have to have them both: security and integrity. If one is missing, you can't have the other.
- Tolga
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24654 for ietf-pkix-bks; Fri, 30 Oct 1998 09:02:53 -0800 (PST)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24649 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:02:52 -0800 (PST)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id JAA17214 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 09:05:10 -0800 (PST)
Message-Id: <199810301705.JAA17214@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Fri, 30 Oct 1998 09:32:51 GMT." <199810301101.LAA21997@ns0.zergo.com>
Date: Fri, 30 Oct 1998 09:05:09 -0800
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Graham Bland writes:
> Why would DNS need to be more secure with signed operations mutual
> authentication etc. Certificates and CRLs are signed objects and their
> security is inherent. Ignoring denial of service I cannot see any
This is theoretically true, but then, aren't you setting yourself
up for an attack based on a single (or small integer number) point
of failure? For example maybe I could trick you into using
a bad certificate database (by breaking into a login of yours
somewhere & trojanning your personal software) but I may not
have enuf access to change your ldap server's certificate db or
trojan your secure dns. If these things were doing signed operations
you may be able to notice you have a problem, or you may make the
attacker's need to fool you more complex & expensive.
On the other hand, would price would we pay for this complexity?
Would we somehown make operations more insecure and/or less reliable?
> What is the problem with the scalability of DNS (How many users does it
> support now ?)
The current commonly used software is terribly memory-intensive
& adding gigantic certificate data-blobs to that is scary.
If your dns stops working the internet (as far as you are concerned!)
goes away. Of course the software will improve.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24557 for ietf-pkix-bks; Fri, 30 Oct 1998 08:51:19 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24552 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 08:51:18 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id LAA00425 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:53:35 -0500 (EST)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id LAA00417 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:53:34 -0500 (EST)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id LAA08478 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:52:40 -0500 (EST)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000336064@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 11:53:33 -0500
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BE03FB.EBF68970@avenger.missi.ncsc.mil>; Fri, 30 Oct 1998 11:53:34 -0500
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981030165333Z-3800@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'ietf-pkix'" <ietf-pkix@imc.org>
Cc: "'klerer@xhair.com'" <klerer@xhair.com>, "'John.Wang@CyberTrust.GTE.Com'" <John.Wang@CyberTrust.GTE.Com>
Subject: email oid
Date: Fri, 30 Oct 1998 11:53:33 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
In the specifications for the schema for an international defense
system, we have chosen rfc822Mailbox, {0 9 2342 19200300 100 1 3}
registered
in RFC 1274. This attribute was also called mail in one Internet Draft.
I would like to request that this remain in whatever documentation you
develop.
Thanks,
Sandi Miklos
>
>
>----------
>From: Wang, John[SMTP:John.Wang@CyberTrust.GTE.Com]
>Sent: Thursday, October 29, 1998 9:17 AM
>To: 'Robert Klerer'; ietf-pkix@imc.org
>Subject: RE: email oid
>
>It was my understanding that the RSA-pkcs-9 email address OID
>(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
>think you can remove the RSA oid but perhaps add the RFC1274 oid
>if there is a demand for it.
>
>-----Original Message-----
>From: Robert Klerer [mailto:klerer@xhair.com]
>Sent: Thursday, October 29, 1998 8:19 AM
>To: ietf-pkix@imc.org
>Subject: email oid
>
>
>The other day in trying to accommodate a legacy pki, I ran into a problem
>with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
>that the oid used for an email address in the distinguished name is
>1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
>others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
>as specified in RFC1274.
>
>Since I believe that the intention is for both of these oids are meant to
>represent attributes that hold the same information, this discrepancy may
>cause confusion and failures in the future. My suggestion would be to
>change part1 to refer to the more commonly used OID.
>
>
>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24354 for ietf-pkix-bks; Fri, 30 Oct 1998 08:24:48 -0800 (PST)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24350 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 08:24:46 -0800 (PST)
Received: from stefans (t4o68p54.telia.com [62.20.139.174]) by maila.telia.com (8.8.8/8.8.8) with SMTP id RAA15715; Fri, 30 Oct 1998 17:26:51 +0100 (CET)
Message-Id: <3.0.32.19981030172236.00a5f980@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 30 Oct 1998 17:23:07 +0100
To: Anders Rundgren <anders.rundgren@jaybis.com>, "'SEIS-List'" <list@seis.nc-forum.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: QC - civicRegistrationNumber
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA24351
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Good point.
I made a search on "civic registration number" and found that it's only
used in Sweden. And as you say, there are countries where non-numeric
characters are used (as in Finland)
It appears that both the wordings "civic registration" and "registration
code" are used in a context wich match our purpose even though i can't find
any documents using the exact combination "civic registration code"
/Stefan
At 01:29 PM 10/30/98 +0100, Anders Rundgren wrote:
>Regarding Qualified Certificates:
>
>civicRegistrationNumber
>
>should IMHO be altered to
>
>civicRegistrationCode
>
>as it does not have to be numeric
>
>Anders Rundgren
>Senior Internet E-commerce Architect
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23968 for ietf-pkix-bks; Fri, 30 Oct 1998 07:36:45 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23964 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:36:44 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA10210; Fri, 30 Oct 1998 07:38:26 -0800 (PST)
Message-Id: <4.1.19981030103143.00a23630@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 10:33:26 -0500
To: David Boyce <D.Boyce@isode.com>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
Cc: ietf-pkix@imc.org
In-Reply-To: <5421.909760948@isode.com>
References: <Your message of "Fri, 30 Oct 1998 09:04:20 EST." <4.1.19981030083342.00a26a10@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
David,
I was unaware of such use. I stand corrected. I'll change my statement to
X.509 is not used in PKIX for its original, X.500-based purpose.
Al Arsenault
-- as if any employer would want to claim my opinions...
At 03:22 PM 10/30/98 +0000, David Boyce wrote:
>Al Arsenault writes:
>>>
>>> Isnt it odd that X.509 is used for PKI and X.500 is discounted?
>>>
>>
>>AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI
>business.
>>X.509 is not used for its original, X.500-based purpose, which was
>actually
>>to control access to the directory for the purpose of limiting who
>could
>>modify entries.
>
>I'm sorry, Al, but it is factually incorrect to say that X.509 is not
>used for its original, X.500-based purpose. There is at least one
>commercial implementation of X.500 which supports strong authentication
>using X.509 certificates, and makes use of the fact for Access Control
>purposes.
>
>I'll grant that X.509 is being used beyond its original purpose, but
>that's just a measure of its utility.
>
>David.
>--
>David Boyce
>
>Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
>Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23903 for ietf-pkix-bks; Fri, 30 Oct 1998 07:30:08 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23891 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:29:51 -0800 (PST)
From: GBland@zergo.com
Message-Id: <199810301657.QAA22890@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
To: MHenry@pec.com, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 15:29:04 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE041A.06C29E92"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE041A.06C29E92
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
An interesting thought.
Could purchasing software from Microsoft (or Netscape or other) be
regarded as an authentication mechanism and secure distribution
mechanism for certificates.
It depends on how much you trust the software vendor (if at all).
Perhaps free certificates are just good value for money.
Graham Bland
> -----Original Message-----
> From: MHenry [mailto:MHenry@PEC.com]
> Sent: 30 October 1998 14:57
> To: GBland@zergo.com; aarsenault@spyrus.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>=20
>=20
> al,
> interestingly enough, the largest base of existing
> pki users (those that have browsers with a hard coded
> certs at time of purchase) do, regularly, exactly what you take for
> granted they would never do.=20
> semper fi,
> mike henry
>=20
> > -----Original Message-----
> > From: GBland@zergo.com [SMTP:GBland@zergo.com]
> > Sent: Friday, October 30, 1998 8:41 AM
> > To: aarsenault@spyrus.com; ietf-pkix@imc.org
> > Subject: RE: Scale (and the SRV record)
> >=20
> > I had taken it for granted that nobody would trust a self signed
> > certificate without having validated it by either a secure=20
> distribution
> > mechanism or verification of the hash from a trusted source.
> >=20
> > I am pleased to say we are in total agreement.=20
> >=20
> > Graham Bland=20
> >=20
> > > -----Original Message-----=20
> > > From: Al Arsenault [ <mailto:aarsenault@spyrus.com>]=20
> > > Sent: 30 October 1998 13:29=20
> > > To: GBland@zergo.com; ietf-pkix@imc.org=20
> > > Subject: RE: Scale (and the SRV record)=20
> > >=20
> > >=20
> > > Since I agree with most of what Phill has to say on this=20
> > > topic, I'll go against=20
> > > my better judgement and jump in here.=20
> > >=20
> > > If I'm understanding this correctly, the attack of concern is=20
> > > as follows:=20
> > > Nothing today stops me from cobbling together my own=20
> > > certificate-generating and=20
> > > -signing software, and then generating a self-signed=20
> > > certificate for user "US=20
> > > Verisign Primary Class 3 Public Certificate Authority" (or=20
> > > whatever the magic=20
> > > string is that will exactly match what VeriSign uses).=A0 This=20
> > > new certificate=20
> > > will use the public key corresponding to a private key that I=20
> > > know, rather than=20
> > > the one that VeriSign actually uses.=A0 (This ignores the=20
> > > scenario described by=20
> > > Graham, in which I've managed to obtain VeriSign's private key.)=20
> > >=20
> > > Given this, can I get you, the unsuspecting user, to use MY=20
> > > certificate (and=20
> > > any user certificates I then issue with it) instead of the=20
> > > real one?=A0 After=20
> > > all, once you've retrieved the certificate, the DN or=20
> > > subjectAltName field will=20
> > > LOOK "right" to you, if you bother to check it.=A0 The argument=20
> > > has been that=20
> > > given an insecure, spoofable, distribution mechanism, I might=20
> > > be able to fool=20
> > > you into using the wrong "VeriSign certificate".=A0 If, for=20
> > > example, I can spoof=20
> > > DNS and make you think that the IP address corresponding to=20
> > > "VeriSign.com" is,=20
> > > say, 130.85.1.3,=A0 and I control that machine (note: I don't=20
> > > :-) then you'll go=20
> > > there for the "real certificate" and I've got you.=A0 So, to=20
> > > counter that, you=20
> > > need a "secure" distribution mechanism.=20
> > >=20
> > > I frankly don't buy that argument, though.=A0 What is required=20
> > > in a PKI is that I=20
> > > somehow securely obtain the certificate/public key of a CA=20
> > > that I have chosen=20
> > > to trust - normally, that's the one that issued my=20
> > > certificate.=A0 If this first=20
> > > step is broken - I'm fooled into accepting a certificate from=20
> > > a phony CA, or=20
> > > whatever - then the security of the entire PKI is shot, and=20
> > > no X.500 directory=20
> > > or other mechanism is going to help.=A0 Once I have that public=20
> > > key, though, I=20
> > > can detect any faked certificates based on the trust my CA=20
> > > has.=A0 My CA will=20
> > > have cross-certified with the REAL VeriSign Class 3 primary=20
> > > CA (when WHAT=20
> > > freezes over? :-)=A0=A0 Thus, even if I get your phony VeriSign=20
> > > cert that looks to=20
> > > be the right one based on the name, I can't build a=20
> > > certification path back to=20
> > > a node I trust, because my CA or whomever else I trust hasn't=20
> > > signed your=20
> > > spoof.=A0 I'm protected against your spoof by the certificates=20
> > > and CRLs, not the=20
> > > distribution mechanism.=20
> > >=20
> > > (Of course, if you can trick the people I trust - my CA, for=20
> > > example - into=20
> > > cross-certifying your fake certificate, I'm hosed.=A0 But that=20
> > > just means that I=20
> > > trusted some incompetent fool I shouldn't have.=A0 A '"secure"=20
> > > X.500 directory=20
> > > won't help at all once my CA has botched it.)=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > =
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Al Arsenault=20
> > >=20
> > > --- standard disclaimer - my own opinions; don't reflect=20
> > > those of my employer=20
> > > or of any other organization to which I may have a=20
> > > relationship; etc., etc., ad=20
> > > infinitum, ad nauseum=20
> > >=20
> > >=20
> > >=20
> > >=A0=A0=A0=A0=A0=A0=A0=A0=20
> > >=20
> > > At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:=20
> > >=20
> > > >=20
> > > > How are you going to do all this ?=20
> > > >=20
> > > > The only way I can think of is that either you know or have=20
> > > compromised the=20
> > > > CA private keys.=20
> > > > If you know the private signature keys then all information=20
> > > is compromised=20
> > > > regardless of source.=20
> > > > If you don't how will you construct the Certificates, CRLs,=20
> > > OCSP responses=20
> > > > etc.=20
> > > >=20
> > > > This is an attack based on the compromise of the CA, not=20
> > > the security of DNS=20
> > > > OCSP etc.=20
> > > >=20
> > > > Graham Bland=20
> > > >=20
> > > > > -----Original Message-----=20
> > > > > From: Ron Ramsay=20
> > > >=20
> > > [< <mailto:Ron.Ramsay@OpenDirectory.com.au>>=20
> <mailto:Ron.Ramsay@Ope>=20
> > > nDirectory.c=20
> > > > om.au]=20
> > > > > Sent: 30 October 1998 02:42=20
> > > > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd=20
> > > > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey=20
> > > > > Subject: RE: Scale (and the SRV record)=20
> > > > >=20
> > > > >=20
> > > > > Phillip,=20
> > > > >=20
> > > > > Thanks again.=20
> > > > >=20
> > > > > Let me pick up on two points.=20
> > > > >=20
> > > > > Firsly, DNS security. If I can spoof DNS (which doesn't look=20
> > > > > to hard) I=20
> > > > > can provide the address of my server in any of the records of =
> > > > > interest.=20
> > > > > A request for your certificate will come to my server and=20
> > > I will send=20
> > > > > back the certificate that I have constructed for you. If=20
> > > you ask for a=20
> > > > > CRL I will give you one that doesn't name this=20
> > > certificate. If you=20
> > > > > choose to use a validation service like OCSP that's OK=20
> > > because I'll=20
> > > > > return 'valid' for your/my certificate.=20
> > > > >=20
> > > > > Denial of service is the best bad behaviour you can=20
> > > expect. Positively=20
> > > > > helpful service is much worse!=20
> > > > >=20
> > > > > Secondly, you're going to send your certificate with the=20
> > > > > message. Why, I=20
> > > > > shall do that too! So I'm still you!=20
> > > > >=20
> > > > > It is interesting you say that the worst that can happen=20
> > > is that you=20
> > > > > receive a certificate you don't trust. How do you know=20
> > > you don't trust=20
> > > > > it? I should think if you already know what certificates you=20
> > > > > trust then=20
> > > > > you don't need PKI at all!=20
> > > > >=20
> > > > > Ron.=20
> > > > > > -----Original Message-----=20
> > > > > > From:=A0=A0=A0=A0=A0=A0 Phillip M Hallam-Baker=20
> [SMTP:pbaker@verisign.com]=20
> > > > > > Sent:=A0=A0=A0=A0=A0=A0 Friday, October 30, 1998 2:38 AM=20
> > > > > > To:Ron Ramsay; Alan Lloyd=20
> > > > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey=20
> > > > > > Subject:=A0=A0=A0 RE: Scale (and the SRV record)=20
> > > > > >=20
> > > > > >=20
> > > > > >=20
> > > > > > > Phillip,=20
> > > > > > >=20
> > > > > > > Thanks for taking time to develop the example.=20
> > > > > > >=20
> > > > > > > Two issues:=20
> > > > > > >=20
> > > > > > > 1. Surely DNS is not secure?=20
> > > > > >=20
> > > > > > Define secure? With the exception of a denial of=20
> > > service attack DNS=20
> > > > > > is 'secure enough' for this purpose since there is no=20
> > > trust placed=20
> > > > > > on the server. The origin of a signed message is=20
> > > irrelevant. Only=20
> > > > > > the signature is relevant.=20
> > > > > >=20
> > > > > > > 2. Your example seems to be based on encryption using=20
> > > public keys.=20
> > > > > > From=20
> > > > > > > what I know of the public key system, it is not used for=20
> > > > > encryption.=20
> > > > > >=20
> > > > > >=20
> > > > > > I think you are confusing DNS security here with PKIX.=20
> > > The two are=20
> > > > > > very=20
> > > > > > separate.=20
> > > > > >=20
> > > > > > If someone spoofed DNS the worst that would happen is=20
> > > that I would=20
> > > > > > recieve a certificate I didn't trust (and would=20
> ignore) or no=20
> > > > > > certificate=20
> > > > > > at all.=20
> > > > > >=20
> > > > > > >Its=20
> > > > > > > purpose is authentication and integrity. To bend your=20
> > > example, you=20
> > > > > > will=20
> > > > > > > be encrypting your message with your own private key.=20
> > > How is an=20
> > > > > > > addressee to verify it was you who sent the message=20
> > > and that the=20
> > > > > > message=20
> > > > > > > was not modified?=20
> > > > > >=20
> > > > > > I send my signing certificate with the message. Or once the =
> > > > > > infrastructure=20
> > > > > > is deployed the recipient could use the SRV pointer=20
> to locate a=20
> > > > > > directory=20
> > > > > > where a copy of the certificate was available.=20
> > > > > >=20
> > > > > >=A0=A0=A0=A0=A0=A0 Phill=20
> > > > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> >=20
>=20
------ =_NextPart_001_01BE041A.06C29E92
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>An interesting thought.</FONT>
</P>
<P><FONT SIZE=3D2>Could purchasing software from Microsoft (or Netscape =
or other) be regarded as an authentication mechanism and secure =
distribution mechanism for certificates.</FONT></P>
<P><FONT SIZE=3D2>It depends on how much you trust the software vendor =
(if at all).</FONT>
</P>
<P><FONT SIZE=3D2>Perhaps free certificates are just good value for =
money.</FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: MHenry [<A HREF=3D"mailto:MHenry@PEC.com" =
TARGET=3D"_blank">mailto:MHenry@PEC.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 30 October 1998 14:57</FONT>
<BR><FONT SIZE=3D2>> To: GBland@zergo.com; aarsenault@spyrus.com; =
ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> al,</FONT>
<BR><FONT SIZE=3D2>> interestingly enough, the largest base of =
existing</FONT>
<BR><FONT SIZE=3D2>> pki users (those that have browsers with a hard =
coded</FONT>
<BR><FONT SIZE=3D2>> certs at time of purchase) do, regularly, =
exactly what you take for</FONT>
<BR><FONT SIZE=3D2>> granted they would never do. </FONT>
<BR><FONT SIZE=3D2>> semper fi,</FONT>
<BR><FONT SIZE=3D2>> mike henry</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> > From: =
GBland@zergo.com [SMTP:GBland@zergo.com]</FONT>
<BR><FONT SIZE=3D2>> > Sent: =
Friday, October 30, 1998 8:41 AM</FONT>
<BR><FONT SIZE=3D2>> > To:aarsenault@spyrus.com; =
ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> > Subject: RE: Scale (and =
the SRV record)</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I had taken it for granted that nobody =
would trust a self signed</FONT>
<BR><FONT SIZE=3D2>> > certificate without having validated it by =
either a secure </FONT>
<BR><FONT SIZE=3D2>> distribution</FONT>
<BR><FONT SIZE=3D2>> > mechanism or verification of the hash from =
a trusted source.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I am pleased to say we are in total =
agreement. </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Graham Bland </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > > -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>> > > From: Al Arsenault [ <<A =
HREF=3D"mailto:aarsenault@spyrus.com" =
TARGET=3D"_blank">mailto:aarsenault@spyrus.com</A>>] </FONT>
<BR><FONT SIZE=3D2>> > > Sent: 30 October 1998 13:29 </FONT>
<BR><FONT SIZE=3D2>> > > To: GBland@zergo.com; =
ietf-pkix@imc.org </FONT>
<BR><FONT SIZE=3D2>> > > Subject: RE: Scale (and the SRV =
record) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Since I agree with most of what Phill =
has to say on this </FONT>
<BR><FONT SIZE=3D2>> > > topic, I'll go against </FONT>
<BR><FONT SIZE=3D2>> > > my better judgement and jump in here. =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > If I'm understanding this correctly, =
the attack of concern is </FONT>
<BR><FONT SIZE=3D2>> > > as follows: </FONT>
<BR><FONT SIZE=3D2>> > > Nothing today stops me from cobbling =
together my own </FONT>
<BR><FONT SIZE=3D2>> > > certificate-generating and </FONT>
<BR><FONT SIZE=3D2>> > > -signing software, and then =
generating a self-signed </FONT>
<BR><FONT SIZE=3D2>> > > certificate for user "US </FONT>
<BR><FONT SIZE=3D2>> > > Verisign Primary Class 3 Public =
Certificate Authority" (or </FONT>
<BR><FONT SIZE=3D2>> > > whatever the magic </FONT>
<BR><FONT SIZE=3D2>> > > string is that will exactly match =
what VeriSign uses).=A0 This </FONT>
<BR><FONT SIZE=3D2>> > > new certificate </FONT>
<BR><FONT SIZE=3D2>> > > will use the public key corresponding =
to a private key that I </FONT>
<BR><FONT SIZE=3D2>> > > know, rather than </FONT>
<BR><FONT SIZE=3D2>> > > the one that VeriSign actually =
uses.=A0 (This ignores the </FONT>
<BR><FONT SIZE=3D2>> > > scenario described by </FONT>
<BR><FONT SIZE=3D2>> > > Graham, in which I've managed to =
obtain VeriSign's private key.) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Given this, can I get you, the =
unsuspecting user, to use MY </FONT>
<BR><FONT SIZE=3D2>> > > certificate (and </FONT>
<BR><FONT SIZE=3D2>> > > any user certificates I then issue =
with it) instead of the </FONT>
<BR><FONT SIZE=3D2>> > > real one?=A0 After </FONT>
<BR><FONT SIZE=3D2>> > > all, once you've retrieved the =
certificate, the DN or </FONT>
<BR><FONT SIZE=3D2>> > > subjectAltName field will </FONT>
<BR><FONT SIZE=3D2>> > > LOOK "right" to you, if you =
bother to check it.=A0 The argument </FONT>
<BR><FONT SIZE=3D2>> > > has been that </FONT>
<BR><FONT SIZE=3D2>> > > given an insecure, spoofable, =
distribution mechanism, I might </FONT>
<BR><FONT SIZE=3D2>> > > be able to fool </FONT>
<BR><FONT SIZE=3D2>> > > you into using the wrong =
"VeriSign certificate".=A0 If, for </FONT>
<BR><FONT SIZE=3D2>> > > example, I can spoof </FONT>
<BR><FONT SIZE=3D2>> > > DNS and make you think that the IP =
address corresponding to </FONT>
<BR><FONT SIZE=3D2>> > > "VeriSign.com" is, </FONT>
<BR><FONT SIZE=3D2>> > > say, 130.85.1.3,=A0 and I control =
that machine (note: I don't </FONT>
<BR><FONT SIZE=3D2>> > > :-) then you'll go </FONT>
<BR><FONT SIZE=3D2>> > > there for the "real =
certificate" and I've got you.=A0 So, to </FONT>
<BR><FONT SIZE=3D2>> > > counter that, you </FONT>
<BR><FONT SIZE=3D2>> > > need a "secure" =
distribution mechanism. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > I frankly don't buy that argument, =
though.=A0 What is required </FONT>
<BR><FONT SIZE=3D2>> > > in a PKI is that I </FONT>
<BR><FONT SIZE=3D2>> > > somehow securely obtain the =
certificate/public key of a CA </FONT>
<BR><FONT SIZE=3D2>> > > that I have chosen </FONT>
<BR><FONT SIZE=3D2>> > > to trust - normally, that's the one =
that issued my </FONT>
<BR><FONT SIZE=3D2>> > > certificate.=A0 If this first </FONT>
<BR><FONT SIZE=3D2>> > > step is broken - I'm fooled into =
accepting a certificate from </FONT>
<BR><FONT SIZE=3D2>> > > a phony CA, or </FONT>
<BR><FONT SIZE=3D2>> > > whatever - then the security of the =
entire PKI is shot, and </FONT>
<BR><FONT SIZE=3D2>> > > no X.500 directory </FONT>
<BR><FONT SIZE=3D2>> > > or other mechanism is going to =
help.=A0 Once I have that public </FONT>
<BR><FONT SIZE=3D2>> > > key, though, I </FONT>
<BR><FONT SIZE=3D2>> > > can detect any faked certificates =
based on the trust my CA </FONT>
<BR><FONT SIZE=3D2>> > > has.=A0 My CA will </FONT>
<BR><FONT SIZE=3D2>> > > have cross-certified with the REAL =
VeriSign Class 3 primary </FONT>
<BR><FONT SIZE=3D2>> > > CA (when WHAT </FONT>
<BR><FONT SIZE=3D2>> > > freezes over? :-)=A0=A0 Thus, even if =
I get your phony VeriSign </FONT>
<BR><FONT SIZE=3D2>> > > cert that looks to </FONT>
<BR><FONT SIZE=3D2>> > > be the right one based on the name, I =
can't build a </FONT>
<BR><FONT SIZE=3D2>> > > certification path back to </FONT>
<BR><FONT SIZE=3D2>> > > a node I trust, because my CA or =
whomever else I trust hasn't </FONT>
<BR><FONT SIZE=3D2>> > > signed your </FONT>
<BR><FONT SIZE=3D2>> > > spoof.=A0 I'm protected against your =
spoof by the certificates </FONT>
<BR><FONT SIZE=3D2>> > > and CRLs, not the </FONT>
<BR><FONT SIZE=3D2>> > > distribution mechanism. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > (Of course, if you can trick the =
people I trust - my CA, for </FONT>
<BR><FONT SIZE=3D2>> > > example - into </FONT>
<BR><FONT SIZE=3D2>> > > cross-certifying your fake =
certificate, I'm hosed.=A0 But that </FONT>
<BR><FONT SIZE=3D2>> > > just means that I </FONT>
<BR><FONT SIZE=3D2>> > > trusted some incompetent fool I =
shouldn't have.=A0 A '"secure" </FONT>
<BR><FONT SIZE=3D2>> > > X.500 directory </FONT>
<BR><FONT SIZE=3D2>> > > won't help at all once my CA has =
botched it.) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > =
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Al Arsenault =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > --- standard disclaimer - my own =
opinions; don't reflect </FONT>
<BR><FONT SIZE=3D2>> > > those of my employer </FONT>
<BR><FONT SIZE=3D2>> > > or of any other organization to which =
I may have a </FONT>
<BR><FONT SIZE=3D2>> > > relationship; etc., etc., ad </FONT>
<BR><FONT SIZE=3D2>> > > infinitum, ad nauseum </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > >=A0=A0=A0=A0=A0=A0=A0=A0 </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > At 11:06 AM 10/30/98 +0000, =
GBland@zergo.com wrote: </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > How are you going to do all this =
? </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > The only way I can think of is =
that either you know or have </FONT>
<BR><FONT SIZE=3D2>> > > compromised the </FONT>
<BR><FONT SIZE=3D2>> > > > CA private keys. </FONT>
<BR><FONT SIZE=3D2>> > > > If you know the private =
signature keys then all information </FONT>
<BR><FONT SIZE=3D2>> > > is compromised </FONT>
<BR><FONT SIZE=3D2>> > > > regardless of source. </FONT>
<BR><FONT SIZE=3D2>> > > > If you don't how will you =
construct the Certificates, CRLs, </FONT>
<BR><FONT SIZE=3D2>> > > OCSP responses </FONT>
<BR><FONT SIZE=3D2>> > > > etc. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > This is an attack based on the =
compromise of the CA, not </FONT>
<BR><FONT SIZE=3D2>> > > the security of DNS </FONT>
<BR><FONT SIZE=3D2>> > > > OCSP etc. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > Graham Bland </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > -----Original Message----- =
</FONT>
<BR><FONT SIZE=3D2>> > > > > From: Ron Ramsay </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > [< <<A =
HREF=3D"mailto:Ron.Ramsay@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Ron.Ramsay@OpenDirectory.com.au</A>>> =
</FONT>
<BR><FONT SIZE=3D2>> <<A HREF=3D"mailto:Ron.Ramsay@Ope" =
TARGET=3D"_blank">mailto:Ron.Ramsay@Ope</A>> </FONT>
<BR><FONT SIZE=3D2>> > > nDirectory.c </FONT>
<BR><FONT SIZE=3D2>> > > > om.au] </FONT>
<BR><FONT SIZE=3D2>> > > > > Sent: 30 October 1998 02:42 =
</FONT>
<BR><FONT SIZE=3D2>> > > > > To: 'Phillip M =
Hallam-Baker'; Ron Ramsay; Alan Lloyd </FONT>
<BR><FONT SIZE=3D2>> > > > > Cc: Stephen Kent; =
ietf-pkix@imc.org; Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > > > Subject: RE: Scale (and the =
SRV record) </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Thanks again. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Let me pick up on two =
points. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Firsly, DNS security. If I =
can spoof DNS (which doesn't look </FONT>
<BR><FONT SIZE=3D2>> > > > > to hard) I </FONT>
<BR><FONT SIZE=3D2>> > > > > can provide the address of =
my server in any of the records of </FONT>
<BR><FONT SIZE=3D2>> > > > > interest. </FONT>
<BR><FONT SIZE=3D2>> > > > > A request for your =
certificate will come to my server and </FONT>
<BR><FONT SIZE=3D2>> > > I will send </FONT>
<BR><FONT SIZE=3D2>> > > > > back the certificate that I =
have constructed for you. If </FONT>
<BR><FONT SIZE=3D2>> > > you ask for a </FONT>
<BR><FONT SIZE=3D2>> > > > > CRL I will give you one =
that doesn't name this </FONT>
<BR><FONT SIZE=3D2>> > > certificate. If you </FONT>
<BR><FONT SIZE=3D2>> > > > > choose to use a validation =
service like OCSP that's OK </FONT>
<BR><FONT SIZE=3D2>> > > because I'll </FONT>
<BR><FONT SIZE=3D2>> > > > > return 'valid' for your/my =
certificate. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Denial of service is the =
best bad behaviour you can </FONT>
<BR><FONT SIZE=3D2>> > > expect. Positively </FONT>
<BR><FONT SIZE=3D2>> > > > > helpful service is much =
worse! </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Secondly, you're going to =
send your certificate with the </FONT>
<BR><FONT SIZE=3D2>> > > > > message. Why, I </FONT>
<BR><FONT SIZE=3D2>> > > > > shall do that too! So I'm =
still you! </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > It is interesting you say =
that the worst that can happen </FONT>
<BR><FONT SIZE=3D2>> > > is that you </FONT>
<BR><FONT SIZE=3D2>> > > > > receive a certificate you =
don't trust. How do you know </FONT>
<BR><FONT SIZE=3D2>> > > you don't trust </FONT>
<BR><FONT SIZE=3D2>> > > > > it? I should think if you =
already know what certificates you </FONT>
<BR><FONT SIZE=3D2>> > > > > trust then </FONT>
<BR><FONT SIZE=3D2>> > > > > you don't need PKI at all! =
</FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Ron. </FONT>
<BR><FONT SIZE=3D2>> > > > > > -----Original =
Message----- </FONT>
<BR><FONT SIZE=3D2>> > > > > > =
From:=A0=A0=A0=A0=A0=A0 Phillip M Hallam-Baker </FONT>
<BR><FONT SIZE=3D2>> [SMTP:pbaker@verisign.com] </FONT>
<BR><FONT SIZE=3D2>> > > > > > =
Sent:=A0=A0=A0=A0=A0=A0 Friday, October 30, 1998 2:38 AM </FONT>
<BR><FONT SIZE=3D2>> > > > > > To:Ron Ramsay; Alan =
Lloyd </FONT>
<BR><FONT SIZE=3D2>> > > > > > Cc:Stephen Kent; =
ietf-pkix@imc.org; Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > > > > Subject:=A0=A0=A0 RE: =
Scale (and the SRV record) </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > Thanks for taking =
time to develop the example. </FONT>
<BR><FONT SIZE=3D2>> > > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > Two issues: =
</FONT>
<BR><FONT SIZE=3D2>> > > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > 1. Surely DNS is =
not secure? </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > Define secure? With =
the exception of a denial of </FONT>
<BR><FONT SIZE=3D2>> > > service attack DNS </FONT>
<BR><FONT SIZE=3D2>> > > > > > is 'secure enough' for =
this purpose since there is no </FONT>
<BR><FONT SIZE=3D2>> > > trust placed </FONT>
<BR><FONT SIZE=3D2>> > > > > > on the server. The =
origin of a signed message is </FONT>
<BR><FONT SIZE=3D2>> > > irrelevant. Only </FONT>
<BR><FONT SIZE=3D2>> > > > > > the signature is =
relevant. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > > 2. Your example =
seems to be based on encryption using </FONT>
<BR><FONT SIZE=3D2>> > > public keys. </FONT>
<BR><FONT SIZE=3D2>> > > > > > From </FONT>
<BR><FONT SIZE=3D2>> > > > > > > what I know of =
the public key system, it is not used for </FONT>
<BR><FONT SIZE=3D2>> > > > > encryption. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > I think you are =
confusing DNS security here with PKIX. </FONT>
<BR><FONT SIZE=3D2>> > > The two are </FONT>
<BR><FONT SIZE=3D2>> > > > > > very </FONT>
<BR><FONT SIZE=3D2>> > > > > > separate. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > If someone spoofed DNS =
the worst that would happen is </FONT>
<BR><FONT SIZE=3D2>> > > that I would </FONT>
<BR><FONT SIZE=3D2>> > > > > > recieve a certificate =
I didn't trust (and would </FONT>
<BR><FONT SIZE=3D2>> ignore) or no </FONT>
<BR><FONT SIZE=3D2>> > > > > > certificate </FONT>
<BR><FONT SIZE=3D2>> > > > > > at all. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > >Its </FONT>
<BR><FONT SIZE=3D2>> > > > > > > purpose is =
authentication and integrity. To bend your </FONT>
<BR><FONT SIZE=3D2>> > > example, you </FONT>
<BR><FONT SIZE=3D2>> > > > > > will </FONT>
<BR><FONT SIZE=3D2>> > > > > > > be encrypting =
your message with your own private key. </FONT>
<BR><FONT SIZE=3D2>> > > How is an </FONT>
<BR><FONT SIZE=3D2>> > > > > > > addressee to =
verify it was you who sent the message </FONT>
<BR><FONT SIZE=3D2>> > > and that the </FONT>
<BR><FONT SIZE=3D2>> > > > > > message </FONT>
<BR><FONT SIZE=3D2>> > > > > > > was not modified? =
</FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > > I send my signing =
certificate with the message. Or once the </FONT>
<BR><FONT SIZE=3D2>> > > > > > infrastructure </FONT>
<BR><FONT SIZE=3D2>> > > > > > is deployed the =
recipient could use the SRV pointer </FONT>
<BR><FONT SIZE=3D2>> to locate a </FONT>
<BR><FONT SIZE=3D2>> > > > > > directory </FONT>
<BR><FONT SIZE=3D2>> > > > > > where a copy of the =
certificate was available. </FONT>
<BR><FONT SIZE=3D2>> > > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > >=A0=A0=A0=A0=A0=A0 =
Phill </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE041A.06C29E92--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23838 for ietf-pkix-bks; Fri, 30 Oct 1998 07:21:43 -0800 (PST)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23834 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:21:42 -0800 (PST)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Fri, 30 Oct 1998 15:22:42 +0000
X-Mailer: exmh version 2.0.2 2/24/98
To: Al Arsenault <aarsenault@spyrus.com>
cc: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Bill Burr'" <william.burr@nist.gov>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Subject: Re: A PKI for the Internet (was RE: Scale (and the SRV record))
In-reply-to: Your message of "Fri, 30 Oct 1998 09:04:20 EST." <4.1.19981030083342.00a26a10@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 30 Oct 1998 15:22:28 +0000
Message-ID: <5421.909760948@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al Arsenault writes:
>>
>> Isnt it odd that X.509 is used for PKI and X.500 is discounted?
>>
>
>AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI
business.
>X.509 is not used for its original, X.500-based purpose, which was
actually
>to control access to the directory for the purpose of limiting who
could
>modify entries.
I'm sorry, Al, but it is factually incorrect to say that X.509 is not
used for its original, X.500-based purpose. There is at least one
commercial implementation of X.500 which supports strong authentication
using X.509 certificates, and makes use of the fact for Access Control
purposes.
I'll grant that X.509 is being used beyond its original purpose, but
that's just a measure of its utility.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23827 for ietf-pkix-bks; Fri, 30 Oct 1998 07:20:20 -0800 (PST)
Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23822 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:20:19 -0800 (PST)
Received: from xedia.com by relay3.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfnir20374; Fri, 30 Oct 1998 10:22:20 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA20684; Fri, 30 Oct 98 10:20:30 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA06562; Fri, 30 Oct 1998 10:22:13 -0500
Date: Fri, 30 Oct 1998 10:22:13 -0500
Message-Id: <199810301522.KAA06562@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Ron.Ramsay@OpenDirectory.com.au
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC0656C6@DSG1>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I continue to be amazed at this thread.
It seems that there's a stream of statements of the form "<disliked
protocol X> is broken because you can open holes by denial of service
attacks on CLRs conveyed by <X>" -- and this is used as an argument
against <X>.
CRLs contain negative statements, so any attack on a CRL turns a
denial of service into a permission of service. That's fundamental in
CRLs, and no fiddling with the underlying directories, transports, or
whatnot will fix this. (Well, maybe if you implement Radia Perlman's
networks with Byzantine robustness you can avoid it.)
paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23785 for ietf-pkix-bks; Fri, 30 Oct 1998 07:16:45 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23781 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 07:16:44 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA29766; Fri, 30 Oct 1998 07:16:00 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA03205; Fri, 30 Oct 1998 07:18:12 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ron Ramsay" <Ron.Ramsay@OpenDirectory.com.au>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>, "Rick Harvey" <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 10:18:42 -0500
Message-ID: <000701be0418$941ff0c0$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-reply-to: <D1A949D4508DD1119C8100400533BEDC0656C6@DSG1>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Firsly, DNS security. If I can spoof DNS (which doesn't look to hard) I
> can provide the address of my server in any of the records of interest.
> A request for your certificate will come to my server and I will send
> back the certificate that I have constructed for you. If you ask for a
> CRL I will give you one that doesn't name this certificate. If you
> choose to use a validation service like OCSP that's OK because I'll
> return 'valid' for your/my certificate.
But I won't trust the signature on the response.
I think you are overplaying the DNS security issue. Although it is a
concern the routers are also subject to attack. This is the case regardless
of whether they are Internet routers or Telephone switches. People tend
to forget that Kevin Mitick was not primarily a cracker, he was a phone
phreak.
Whether the service is OCSP, LDAP or X.500 is irrelevant. They are
all vulnerable to a DNS spoofing attack when routing packets across
the Internet.
The work in DNSSec is useful and important but it is important to
recognize that it is raising the bar for attacks by forcing them to
take place at a lower level. It does not eliminate the risk of attack.
> Secondly, you're going to send your certificate with the message. Why, I
> shall do that too! So I'm still you!
>
> It is interesting you say that the worst that can happen is that you
> receive a certificate you don't trust. How do you know you don't trust
> it? I should think if you already know what certificates you trust then
> you don't need PKI at all!
? I think that your understanding of PKI appears to be so radically
different from the PKIX model as to be unrelated.
PKIX makes trust decisions on the basis of the CONTENT of the signed
objects alone. If you care how you got the signed objects it isn't
PKIX.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23599 for ietf-pkix-bks; Fri, 30 Oct 1998 06:53:58 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23595 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 06:53:57 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP (peer crosschecked as: [204.254.216.13]) id QQfnip14877; Fri, 30 Oct 1998 09:55:50 -0500 (EST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <V6SF02R2>; Fri, 30 Oct 1998 09:57:02 -0500
Message-ID: <3C7EABA3F6F1D1118FD90008C7F450FDB574E8@exchang-fairfax.pec.com>
From: MHenry <MHenry@pec.com>
To: GBland@zergo.com, aarsenault@spyrus.com, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:57:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id GAA23596
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
al,
interestingly enough, the largest base of existing
pki users (those that have browsers with a hard coded
certs at time of purchase) do, regularly, exactly what you take for
granted they would never do.
semper fi,
mike henry
> -----Original Message-----
> From: GBland@zergo.com [SMTP:GBland@zergo.com]
> Sent: Friday, October 30, 1998 8:41 AM
> To: aarsenault@spyrus.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> I had taken it for granted that nobody would trust a self signed
> certificate without having validated it by either a secure distribution
> mechanism or verification of the hash from a trusted source.
>
> I am pleased to say we are in total agreement.
>
> Graham Bland
>
> > -----Original Message-----
> > From: Al Arsenault [ <mailto:aarsenault@spyrus.com>]
> > Sent: 30 October 1998 13:29
> > To: GBland@zergo.com; ietf-pkix@imc.org
> > Subject: RE: Scale (and the SRV record)
> >
> >
> > Since I agree with most of what Phill has to say on this
> > topic, I'll go against
> > my better judgement and jump in here.
> >
> > If I'm understanding this correctly, the attack of concern is
> > as follows:
> > Nothing today stops me from cobbling together my own
> > certificate-generating and
> > -signing software, and then generating a self-signed
> > certificate for user "US
> > Verisign Primary Class 3 Public Certificate Authority" (or
> > whatever the magic
> > string is that will exactly match what VeriSign uses). This
> > new certificate
> > will use the public key corresponding to a private key that I
> > know, rather than
> > the one that VeriSign actually uses. (This ignores the
> > scenario described by
> > Graham, in which I've managed to obtain VeriSign's private key.)
> >
> > Given this, can I get you, the unsuspecting user, to use MY
> > certificate (and
> > any user certificates I then issue with it) instead of the
> > real one? After
> > all, once you've retrieved the certificate, the DN or
> > subjectAltName field will
> > LOOK "right" to you, if you bother to check it. The argument
> > has been that
> > given an insecure, spoofable, distribution mechanism, I might
> > be able to fool
> > you into using the wrong "VeriSign certificate". If, for
> > example, I can spoof
> > DNS and make you think that the IP address corresponding to
> > "VeriSign.com" is,
> > say, 130.85.1.3, and I control that machine (note: I don't
> > :-) then you'll go
> > there for the "real certificate" and I've got you. So, to
> > counter that, you
> > need a "secure" distribution mechanism.
> >
> > I frankly don't buy that argument, though. What is required
> > in a PKI is that I
> > somehow securely obtain the certificate/public key of a CA
> > that I have chosen
> > to trust - normally, that's the one that issued my
> > certificate. If this first
> > step is broken - I'm fooled into accepting a certificate from
> > a phony CA, or
> > whatever - then the security of the entire PKI is shot, and
> > no X.500 directory
> > or other mechanism is going to help. Once I have that public
> > key, though, I
> > can detect any faked certificates based on the trust my CA
> > has. My CA will
> > have cross-certified with the REAL VeriSign Class 3 primary
> > CA (when WHAT
> > freezes over? :-) Thus, even if I get your phony VeriSign
> > cert that looks to
> > be the right one based on the name, I can't build a
> > certification path back to
> > a node I trust, because my CA or whomever else I trust hasn't
> > signed your
> > spoof. I'm protected against your spoof by the certificates
> > and CRLs, not the
> > distribution mechanism.
> >
> > (Of course, if you can trick the people I trust - my CA, for
> > example - into
> > cross-certifying your fake certificate, I'm hosed. But that
> > just means that I
> > trusted some incompetent fool I shouldn't have. A '"secure"
> > X.500 directory
> > won't help at all once my CA has botched it.)
> >
> >
> >
> >
> >
> > Al Arsenault
> >
> > --- standard disclaimer - my own opinions; don't reflect
> > those of my employer
> > or of any other organization to which I may have a
> > relationship; etc., etc., ad
> > infinitum, ad nauseum
> >
> >
> >
> >
> >
> > At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
> >
> > >
> > > How are you going to do all this ?
> > >
> > > The only way I can think of is that either you know or have
> > compromised the
> > > CA private keys.
> > > If you know the private signature keys then all information
> > is compromised
> > > regardless of source.
> > > If you don't how will you construct the Certificates, CRLs,
> > OCSP responses
> > > etc.
> > >
> > > This is an attack based on the compromise of the CA, not
> > the security of DNS
> > > OCSP etc.
> > >
> > > Graham Bland
> > >
> > > > -----Original Message-----
> > > > From: Ron Ramsay
> > >
> > [< <mailto:Ron.Ramsay@OpenDirectory.com.au>> <mailto:Ron.Ramsay@Ope>
> > nDirectory.c
> > > om.au]
> > > > Sent: 30 October 1998 02:42
> > > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > Subject: RE: Scale (and the SRV record)
> > > >
> > > >
> > > > Phillip,
> > > >
> > > > Thanks again.
> > > >
> > > > Let me pick up on two points.
> > > >
> > > > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > > > to hard) I
> > > > can provide the address of my server in any of the records of
> > > > interest.
> > > > A request for your certificate will come to my server and
> > I will send
> > > > back the certificate that I have constructed for you. If
> > you ask for a
> > > > CRL I will give you one that doesn't name this
> > certificate. If you
> > > > choose to use a validation service like OCSP that's OK
> > because I'll
> > > > return 'valid' for your/my certificate.
> > > >
> > > > Denial of service is the best bad behaviour you can
> > expect. Positively
> > > > helpful service is much worse!
> > > >
> > > > Secondly, you're going to send your certificate with the
> > > > message. Why, I
> > > > shall do that too! So I'm still you!
> > > >
> > > > It is interesting you say that the worst that can happen
> > is that you
> > > > receive a certificate you don't trust. How do you know
> > you don't trust
> > > > it? I should think if you already know what certificates you
> > > > trust then
> > > > you don't need PKI at all!
> > > >
> > > > Ron.
> > > > > -----Original Message-----
> > > > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > > > Sent: Friday, October 30, 1998 2:38 AM
> > > > > To:Ron Ramsay; Alan Lloyd
> > > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > > Subject: RE: Scale (and the SRV record)
> > > > >
> > > > >
> > > > >
> > > > > > Phillip,
> > > > > >
> > > > > > Thanks for taking time to develop the example.
> > > > > >
> > > > > > Two issues:
> > > > > >
> > > > > > 1. Surely DNS is not secure?
> > > > >
> > > > > Define secure? With the exception of a denial of
> > service attack DNS
> > > > > is 'secure enough' for this purpose since there is no
> > trust placed
> > > > > on the server. The origin of a signed message is
> > irrelevant. Only
> > > > > the signature is relevant.
> > > > >
> > > > > > 2. Your example seems to be based on encryption using
> > public keys.
> > > > > From
> > > > > > what I know of the public key system, it is not used for
> > > > encryption.
> > > > >
> > > > >
> > > > > I think you are confusing DNS security here with PKIX.
> > The two are
> > > > > very
> > > > > separate.
> > > > >
> > > > > If someone spoofed DNS the worst that would happen is
> > that I would
> > > > > recieve a certificate I didn't trust (and would ignore) or no
> > > > > certificate
> > > > > at all.
> > > > >
> > > > > >Its
> > > > > > purpose is authentication and integrity. To bend your
> > example, you
> > > > > will
> > > > > > be encrypting your message with your own private key.
> > How is an
> > > > > > addressee to verify it was you who sent the message
> > and that the
> > > > > message
> > > > > > was not modified?
> > > > >
> > > > > I send my signing certificate with the message. Or once the
> > > > > infrastructure
> > > > > is deployed the recipient could use the SRV pointer to locate a
> > > > > directory
> > > > > where a copy of the certificate was available.
> > > > >
> > > > > Phill
> > > >
> >
> >
> >
> >
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23409 for ietf-pkix-bks; Fri, 30 Oct 1998 06:24:03 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23405 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 06:24:01 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP (peer crosschecked as: [204.254.216.13]) id QQfnin28918; Fri, 30 Oct 1998 09:25:46 -0500 (EST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <V6SF02MH>; Fri, 30 Oct 1998 09:26:57 -0500
Message-ID: <3C7EABA3F6F1D1118FD90008C7F450FDA65C34@exchang-fairfax.pec.com>
From: WHenry <WHenry@pec.com>
To: "'Al Arsenault'" <aarsenault@spyrus.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:26:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All:
Al Arsenault said:
"What is required in a PKI is that I somehow securely obtain the
certificate/public key of a CA that I have chosen to trust - normally,
that's the one that issued my certificate. If this first
step is broken - I'm fooled into accepting a certificate from a phony CA, or
whatever - then the security of the entire PKI is shot, and no X.500
directory
or other mechanism is going to help."
I couldn't agree more! This is precisely the reason why CA certs that come
embedded in my browser are, from a trust standpoint, worthless.
-Bill Henry
> -----Original Message-----
> From: Al Arsenault [SMTP:aarsenault@spyrus.com]
> Sent: Friday, October 30, 1998 8:29 AM
> To: GBland@zergo.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> Since I agree with most of what Phill has to say on this topic, I'll go
> against
> my better judgement and jump in here.
>
> If I'm understanding this correctly, the attack of concern is as follows:
> Nothing today stops me from cobbling together my own
> certificate-generating and
> -signing software, and then generating a self-signed certificate for user
> "US
> Verisign Primary Class 3 Public Certificate Authority" (or whatever the
> magic
> string is that will exactly match what VeriSign uses). This new
> certificate
> will use the public key corresponding to a private key that I know, rather
> than
> the one that VeriSign actually uses. (This ignores the scenario described
> by
> Graham, in which I've managed to obtain VeriSign's private key.)
>
> Given this, can I get you, the unsuspecting user, to use MY certificate
> (and
> any user certificates I then issue with it) instead of the real one?
> After
> all, once you've retrieved the certificate, the DN or subjectAltName field
> will
> LOOK "right" to you, if you bother to check it. The argument has been
> that
> given an insecure, spoofable, distribution mechanism, I might be able to
> fool
> you into using the wrong "VeriSign certificate". If, for example, I can
> spoof
> DNS and make you think that the IP address corresponding to "VeriSign.com"
> is,
> say, 130.85.1.3, and I control that machine (note: I don't :-) then
> you'll go
> there for the "real certificate" and I've got you. So, to counter that,
> you
> need a "secure" distribution mechanism.
>
> I frankly don't buy that argument, though. What is required in a PKI is
> that I
> somehow securely obtain the certificate/public key of a CA that I have
> chosen
> to trust - normally, that's the one that issued my certificate. If this
> first
> step is broken - I'm fooled into accepting a certificate from a phony CA,
> or
> whatever - then the security of the entire PKI is shot, and no X.500
> directory
> or other mechanism is going to help. Once I have that public key, though,
> I
> can detect any faked certificates based on the trust my CA has. My CA
> will
> have cross-certified with the REAL VeriSign Class 3 primary CA (when WHAT
> freezes over? :-) Thus, even if I get your phony VeriSign cert that
> looks to
> be the right one based on the name, I can't build a certification path
> back to
> a node I trust, because my CA or whomever else I trust hasn't signed your
> spoof. I'm protected against your spoof by the certificates and CRLs, not
> the
> distribution mechanism.
>
> (Of course, if you can trick the people I trust - my CA, for example -
> into
> cross-certifying your fake certificate, I'm hosed. But that just means
> that I
> trusted some incompetent fool I shouldn't have. A '"secure" X.500
> directory
> won't help at all once my CA has botched it.)
>
>
>
>
>
> Al Arsenault
>
> --- standard disclaimer - my own opinions; don't reflect those of my
> employer
> or of any other organization to which I may have a relationship; etc.,
> etc., ad
> infinitum, ad nauseum
>
>
>
>
>
> At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
>
> >
> > How are you going to do all this ?
> >
> > The only way I can think of is that either you know or have compromised
> the
> > CA private keys.
> > If you know the private signature keys then all information is
> compromised
> > regardless of source.
> > If you don't how will you construct the Certificates, CRLs, OCSP
> responses
> > etc.
> >
> > This is an attack based on the compromise of the CA, not the security of
> DNS
> > OCSP etc.
> >
> > Graham Bland
> >
> > > -----Original Message-----
> > > From: Ron Ramsay
> >
> [<mailto:Ron.Ramsay@OpenDirectory.com.au>mailto:Ron.Ramsay@OpenDirectory.c
> > om.au]
> > > Sent: 30 October 1998 02:42
> > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > Subject: RE: Scale (and the SRV record)
> > >
> > >
> > > Phillip,
> > >
> > > Thanks again.
> > >
> > > Let me pick up on two points.
> > >
> > > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > > to hard) I
> > > can provide the address of my server in any of the records of
> > > interest.
> > > A request for your certificate will come to my server and I will send
> > > back the certificate that I have constructed for you. If you ask for a
>
> > > CRL I will give you one that doesn't name this certificate. If you
> > > choose to use a validation service like OCSP that's OK because I'll
> > > return 'valid' for your/my certificate.
> > >
> > > Denial of service is the best bad behaviour you can expect. Positively
>
> > > helpful service is much worse!
> > >
> > > Secondly, you're going to send your certificate with the
> > > message. Why, I
> > > shall do that too! So I'm still you!
> > >
> > > It is interesting you say that the worst that can happen is that you
> > > receive a certificate you don't trust. How do you know you don't trust
>
> > > it? I should think if you already know what certificates you
> > > trust then
> > > you don't need PKI at all!
> > >
> > > Ron.
> > > > -----Original Message-----
> > > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > > Sent: Friday, October 30, 1998 2:38 AM
> > > > To:Ron Ramsay; Alan Lloyd
> > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > Subject: RE: Scale (and the SRV record)
> > > >
> > > >
> > > >
> > > > > Phillip,
> > > > >
> > > > > Thanks for taking time to develop the example.
> > > > >
> > > > > Two issues:
> > > > >
> > > > > 1. Surely DNS is not secure?
> > > >
> > > > Define secure? With the exception of a denial of service attack DNS
> > > > is 'secure enough' for this purpose since there is no trust placed
> > > > on the server. The origin of a signed message is irrelevant. Only
> > > > the signature is relevant.
> > > >
> > > > > 2. Your example seems to be based on encryption using public keys.
>
> > > > From
> > > > > what I know of the public key system, it is not used for
> > > encryption.
> > > >
> > > >
> > > > I think you are confusing DNS security here with PKIX. The two are
> > > > very
> > > > separate.
> > > >
> > > > If someone spoofed DNS the worst that would happen is that I would
> > > > recieve a certificate I didn't trust (and would ignore) or no
> > > > certificate
> > > > at all.
> > > >
> > > > >Its
> > > > > purpose is authentication and integrity. To bend your example, you
>
> > > > will
> > > > > be encrypting your message with your own private key. How is an
> > > > > addressee to verify it was you who sent the message and that the
> > > > message
> > > > > was not modified?
> > > >
> > > > I send my signing certificate with the message. Or once the
> > > > infrastructure
> > > > is deployed the recipient could use the SRV pointer to locate a
> > > > directory
> > > > where a copy of the certificate was available.
> > > >
> > > > Phill
> > >
>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA23284 for ietf-pkix-bks; Fri, 30 Oct 1998 06:07:53 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA23280 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 06:07:53 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA09170; Fri, 30 Oct 1998 06:09:21 -0800 (PST)
Message-Id: <4.1.19981030083342.00a26a10@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 09:04:20 -0500
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Bill Burr'" <william.burr@nist.gov>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
From: Al Arsenault <aarsenault@spyrus.com>
Subject: A PKI for the Internet (was RE: Scale (and the SRV record))
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I tend to agree with Bill Burr on this one. Phill's proposal makes a lot of
sense, as long as we're willing to understand its limits. If we're building
a PKI for the Internet (supposedly, that's PKIX's charter), then it is is
wholly appropriate to think in terms of the Internet paradigm. I have no
problem with names of entities being based on Internet things like domain
names, IP addresses, etc.
This is one of the areas where the SPKI folk make sense. There is not, and
will not ever be, a single, unified, global directory where everything has
a name that fits into the schema. There are instead "directories" of
information that apply to a specific "domain". In PKIX's case, it's the
information that applies to the Internet. The namespace covers those
things that are important in the Internet context, and nothing else. To
me, that's (right now), IP addresses, domain names, port numbers, service
names, user names/mailbox names, and maybe one or two other things. If the
Internet expands to cover toll plazas, then a naming space will have to be
developed for them, and after it's defined and standardized we can figure
out how to put the proper names in certificates.
(You can learn more about my views on this by reading the "naming" section
of the Roadmap document. If you think it's wrong, please let Sean and/or
me know.)
Now, a few specific comments:
<Snip>
>> I think that we would want to think very hard about basing PKI names
>> on
>> domain names. It seems desirable to make names in certificates more
>> directly related to the "real world" than domain names and e-mail
>> addresses
>> often seem to be. But, if we are dong a PKI for the Internet (and
>> isn't
>> this what PKIX is about?), then domain names and the DNS are the
>> foundation
>> that we build the whole Internet on anyhow.
> [Alan Lloyd]
> The Internet has many layers in my book. The physical layer and
>Lans and things, the Internet layer, the domain layer for machine based
>names, and the application layer. DNS deals with Internet addresses and
>Domains. Its history that domains relate to organisations. However, as
>applications over the Internet evolve, then the higher level naming
>constructs relate to real life. Ie. I have a name of Alan, but I may get
>services from many internet domains eg Ozemail, Compuserve, MSN, etc. I
>dont want 10 names because I use 10 domain based services.
>
AWA: I disagree. Last time I counted closely, I had at least six
different Internet access points, in at least five different domains. I
use them for different purposes - one for working on this job; one for
working on this other thing; one for my use at home; one for shared use
with my children; etc. I want them to have different names and different
certificates, with rights/limits/policies that reflect what I use them for.
That's the way things work in real life.
That's what I like about using the existing Internet paradigms for cert
names, etc. The account I let my children use is one that only allows
text-based e-mail, for example. Picture attachments don't work; that's the
way the provider sets it up. Thus, I'm not as worried about spam with
offensive pictures showing up in the mailbox - if such a message does make
it through, it won't be rendered as an image without massive human
intervention. I'd like a certificate for this account that reflects its
capabilities and uses - e.g., since I don't use it for on-line purchases, a
certificate should have a financial limit of 0; and a low trust level. For
other accounts, I'd like more "powerful" certificates.
I'm one of those people who think that the "ideal world" painted by some
(like, some of the DII designers) of one certificate per person is simply
wrong. It may make their system design easier, but it doesn't reflect the
real world. I want different certificates for the different things I do,
just like I have different physical pieces of identification for different
purposes. Following an Internet paradigm is a good thing - just as I have
those different e-mail addresses and different service providers, I'd like
different certificates that match them.
>> If the car, or perhaps the toll road operator, in your toll plaza
>> example,
>> doesn't have a domain name, or an IP address, why is it the concern of
>> PKIX, which is, after all, an Internet standard group. Is it even
>> appropriate for the PKIX group to worry about things that don't relate
>> to
>> the Internet?
> [Alan Lloyd] Thats a view. I tend to think that the Internet
>and Internet style technologies get used where they can. So why not
>build things with the widest capability. Thats what the market wants.
>
AWA: I disagree that that's what the "market wants". Some people do, but
many share my views about separation (at least I think many do. I'm
willing to be corrected.)
>
>> Until now, I have also been saying, does anybody have a believable
>> alternative to the mythological, pervasive X.500 directory service?
>> It
>> seemed almost a rhetorical question. But I think perhaps Phill has
>> outlined an alternative, that looks like it probably ought to work,
>> and is
>> based on something, DNS, that we know works well, scales well, and
>> exists
>> now. Moreover, we should be able to create the service we need
>> incrementally, by just by adding servers as we need them, one at a
>> time.
>> And, If I understand the proposal, all we have to do is agree on some
>> simple naming conventions.
> [Alan Lloyd] I am not against alternative proposals - its all a
>question of how much effort and implementation goes behind it. Phills
>solution has to be backed by all the DNS and PKI suppliers on this
>planet and DNS then has to become secure - with signed operations,
>mutual authentication, access controls, real life naming, and scale a
>lot better and of course be easy to manage and follow Object Oriented
>design. (does this mean turning DNS into X.500?) I would vote for that -
>thats more X.500!
>
AWA: I disagre with these assertions. DNS does not need to be secure,
unless what you're trying to stop is the denial of service problem. If
you're implementing the PKI properly, you can't get fooled into using the
wrong certificate just because DNS is defeated; the worst that will happen
is that you can't get the real certificate or CRL. I'll post another
transaction today that explains my views on that in more detail. (Yes, I
agree with those who argue that a denial of service problem that prevents
you from getting the current CRL can lead to a violation of confidentiality
or integrity, because you won't know that a key has been compromised. The
threat also applies to OCSP services, unless you're operating in a mode
where "no response from the OCSP responder means reject everything".)
>
> Isnt it odd that X.509 is used for PKI and X.500 is discounted?
>
AWA - X.509 (and ASN.1) are used as a lingua franca of the PKI business.
X.509 is not used for its original, X.500-based purpose, which was actually
to control access to the directory for the purpose of limiting who could
modify entries. We - the PKI community - needed a common terminology to
express things. The X.509 syntax existed and seemed to be reasonably well
understood, and thus was adopted. We could have easily gone down a SPKI
path and invented "S expressions" or some other similar thing, but that
seemed to be a waste of time.
Al Arsenault
-- my opinions only; no employer endorsement implied; etc., etc., etc.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23133 for ietf-pkix-bks; Fri, 30 Oct 1998 05:41:26 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23129 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 05:41:20 -0800 (PST)
From: GBland@zergo.com
Message-Id: <199810301509.PAA22673@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
To: aarsenault@spyrus.com, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 13:41:01 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE040A.EF04FF3E"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE040A.EF04FF3E
Content-Type: text/plain;
charset="iso-8859-1"
I had taken it for granted that nobody would trust a self signed
certificate without having validated it by either a secure distribution
mechanism or verification of the hash from a trusted source.
I am pleased to say we are in total agreement.
Graham Bland
> -----Original Message-----
> From: Al Arsenault [mailto:aarsenault@spyrus.com]
> Sent: 30 October 1998 13:29
> To: GBland@zergo.com; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
>
> Since I agree with most of what Phill has to say on this
> topic, I'll go against
> my better judgement and jump in here.
>
> If I'm understanding this correctly, the attack of concern is
> as follows:
> Nothing today stops me from cobbling together my own
> certificate-generating and
> -signing software, and then generating a self-signed
> certificate for user "US
> Verisign Primary Class 3 Public Certificate Authority" (or
> whatever the magic
> string is that will exactly match what VeriSign uses). This
> new certificate
> will use the public key corresponding to a private key that I
> know, rather than
> the one that VeriSign actually uses. (This ignores the
> scenario described by
> Graham, in which I've managed to obtain VeriSign's private key.)
>
> Given this, can I get you, the unsuspecting user, to use MY
> certificate (and
> any user certificates I then issue with it) instead of the
> real one? After
> all, once you've retrieved the certificate, the DN or
> subjectAltName field will
> LOOK "right" to you, if you bother to check it. The argument
> has been that
> given an insecure, spoofable, distribution mechanism, I might
> be able to fool
> you into using the wrong "VeriSign certificate". If, for
> example, I can spoof
> DNS and make you think that the IP address corresponding to
> "VeriSign.com" is,
> say, 130.85.1.3, and I control that machine (note: I don't
> :-) then you'll go
> there for the "real certificate" and I've got you. So, to
> counter that, you
> need a "secure" distribution mechanism.
>
> I frankly don't buy that argument, though. What is required
> in a PKI is that I
> somehow securely obtain the certificate/public key of a CA
> that I have chosen
> to trust - normally, that's the one that issued my
> certificate. If this first
> step is broken - I'm fooled into accepting a certificate from
> a phony CA, or
> whatever - then the security of the entire PKI is shot, and
> no X.500 directory
> or other mechanism is going to help. Once I have that public
> key, though, I
> can detect any faked certificates based on the trust my CA
> has. My CA will
> have cross-certified with the REAL VeriSign Class 3 primary
> CA (when WHAT
> freezes over? :-) Thus, even if I get your phony VeriSign
> cert that looks to
> be the right one based on the name, I can't build a
> certification path back to
> a node I trust, because my CA or whomever else I trust hasn't
> signed your
> spoof. I'm protected against your spoof by the certificates
> and CRLs, not the
> distribution mechanism.
>
> (Of course, if you can trick the people I trust - my CA, for
> example - into
> cross-certifying your fake certificate, I'm hosed. But that
> just means that I
> trusted some incompetent fool I shouldn't have. A '"secure"
> X.500 directory
> won't help at all once my CA has botched it.)
>
>
>
>
>
> Al Arsenault
>
> --- standard disclaimer - my own opinions; don't reflect
> those of my employer
> or of any other organization to which I may have a
> relationship; etc., etc., ad
> infinitum, ad nauseum
>
>
>
>
>
> At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
>
> >
> > How are you going to do all this ?
> >
> > The only way I can think of is that either you know or have
> compromised the
> > CA private keys.
> > If you know the private signature keys then all information
> is compromised
> > regardless of source.
> > If you don't how will you construct the Certificates, CRLs,
> OCSP responses
> > etc.
> >
> > This is an attack based on the compromise of the CA, not
> the security of DNS
> > OCSP etc.
> >
> > Graham Bland
> >
> > > -----Original Message-----
> > > From: Ron Ramsay
> >
> [<mailto:Ron.Ramsay@OpenDirectory.com.au>mailto:Ron.Ramsay@Ope
> nDirectory.c
> > om.au]
> > > Sent: 30 October 1998 02:42
> > > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > Subject: RE: Scale (and the SRV record)
> > >
> > >
> > > Phillip,
> > >
> > > Thanks again.
> > >
> > > Let me pick up on two points.
> > >
> > > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > > to hard) I
> > > can provide the address of my server in any of the records of
> > > interest.
> > > A request for your certificate will come to my server and
> I will send
> > > back the certificate that I have constructed for you. If
> you ask for a
> > > CRL I will give you one that doesn't name this
> certificate. If you
> > > choose to use a validation service like OCSP that's OK
> because I'll
> > > return 'valid' for your/my certificate.
> > >
> > > Denial of service is the best bad behaviour you can
> expect. Positively
> > > helpful service is much worse!
> > >
> > > Secondly, you're going to send your certificate with the
> > > message. Why, I
> > > shall do that too! So I'm still you!
> > >
> > > It is interesting you say that the worst that can happen
> is that you
> > > receive a certificate you don't trust. How do you know
> you don't trust
> > > it? I should think if you already know what certificates you
> > > trust then
> > > you don't need PKI at all!
> > >
> > > Ron.
> > > > -----Original Message-----
> > > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > > Sent: Friday, October 30, 1998 2:38 AM
> > > > To:Ron Ramsay; Alan Lloyd
> > > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > > Subject: RE: Scale (and the SRV record)
> > > >
> > > >
> > > >
> > > > > Phillip,
> > > > >
> > > > > Thanks for taking time to develop the example.
> > > > >
> > > > > Two issues:
> > > > >
> > > > > 1. Surely DNS is not secure?
> > > >
> > > > Define secure? With the exception of a denial of
> service attack DNS
> > > > is 'secure enough' for this purpose since there is no
> trust placed
> > > > on the server. The origin of a signed message is
> irrelevant. Only
> > > > the signature is relevant.
> > > >
> > > > > 2. Your example seems to be based on encryption using
> public keys.
> > > > From
> > > > > what I know of the public key system, it is not used for
> > > encryption.
> > > >
> > > >
> > > > I think you are confusing DNS security here with PKIX.
> The two are
> > > > very
> > > > separate.
> > > >
> > > > If someone spoofed DNS the worst that would happen is
> that I would
> > > > recieve a certificate I didn't trust (and would ignore) or no
> > > > certificate
> > > > at all.
> > > >
> > > > >Its
> > > > > purpose is authentication and integrity. To bend your
> example, you
> > > > will
> > > > > be encrypting your message with your own private key.
> How is an
> > > > > addressee to verify it was you who sent the message
> and that the
> > > > message
> > > > > was not modified?
> > > >
> > > > I send my signing certificate with the message. Or once the
> > > > infrastructure
> > > > is deployed the recipient could use the SRV pointer to locate a
> > > > directory
> > > > where a copy of the certificate was available.
> > > >
> > > > Phill
> > >
>
>
>
>
------ =_NextPart_001_01BE040A.EF04FF3E
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>I had taken it for granted that nobody would trust a =
self signed certificate without having validated it by either a secure =
distribution mechanism or verification of the hash from a trusted =
source.</FONT></P>
<P><FONT SIZE=3D2>I am pleased to say we are in total agreement.</FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Al Arsenault [<A =
HREF=3D"mailto:aarsenault@spyrus.com" =
TARGET=3D"_blank">mailto:aarsenault@spyrus.com</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 30 October 1998 13:29</FONT>
<BR><FONT SIZE=3D2>> To: GBland@zergo.com; ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Since I agree with most of what Phill has to =
say on this </FONT>
<BR><FONT SIZE=3D2>> topic, I'll go against</FONT>
<BR><FONT SIZE=3D2>> my better judgement and jump in here.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> If I'm understanding this correctly, the attack =
of concern is </FONT>
<BR><FONT SIZE=3D2>> as follows:</FONT>
<BR><FONT SIZE=3D2>> Nothing today stops me from cobbling together =
my own </FONT>
<BR><FONT SIZE=3D2>> certificate-generating and</FONT>
<BR><FONT SIZE=3D2>> -signing software, and then generating a =
self-signed </FONT>
<BR><FONT SIZE=3D2>> certificate for user "US</FONT>
<BR><FONT SIZE=3D2>> Verisign Primary Class 3 Public Certificate =
Authority" (or </FONT>
<BR><FONT SIZE=3D2>> whatever the magic</FONT>
<BR><FONT SIZE=3D2>> string is that will exactly match what VeriSign =
uses). This </FONT>
<BR><FONT SIZE=3D2>> new certificate</FONT>
<BR><FONT SIZE=3D2>> will use the public key corresponding to a =
private key that I </FONT>
<BR><FONT SIZE=3D2>> know, rather than</FONT>
<BR><FONT SIZE=3D2>> the one that VeriSign actually uses. =
(This ignores the </FONT>
<BR><FONT SIZE=3D2>> scenario described by</FONT>
<BR><FONT SIZE=3D2>> Graham, in which I've managed to obtain =
VeriSign's private key.)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Given this, can I get you, the unsuspecting =
user, to use MY </FONT>
<BR><FONT SIZE=3D2>> certificate (and</FONT>
<BR><FONT SIZE=3D2>> any user certificates I then issue with it) =
instead of the </FONT>
<BR><FONT SIZE=3D2>> real one? After</FONT>
<BR><FONT SIZE=3D2>> all, once you've retrieved the certificate, the =
DN or </FONT>
<BR><FONT SIZE=3D2>> subjectAltName field will</FONT>
<BR><FONT SIZE=3D2>> LOOK "right" to you, if you bother to =
check it. The argument </FONT>
<BR><FONT SIZE=3D2>> has been that</FONT>
<BR><FONT SIZE=3D2>> given an insecure, spoofable, distribution =
mechanism, I might </FONT>
<BR><FONT SIZE=3D2>> be able to fool</FONT>
<BR><FONT SIZE=3D2>> you into using the wrong "VeriSign =
certificate". If, for </FONT>
<BR><FONT SIZE=3D2>> example, I can spoof</FONT>
<BR><FONT SIZE=3D2>> DNS and make you think that the IP address =
corresponding to </FONT>
<BR><FONT SIZE=3D2>> "VeriSign.com" is,</FONT>
<BR><FONT SIZE=3D2>> say, 130.85.1.3, and I control that =
machine (note: I don't </FONT>
<BR><FONT SIZE=3D2>> :-) then you'll go</FONT>
<BR><FONT SIZE=3D2>> there for the "real certificate" and =
I've got you. So, to </FONT>
<BR><FONT SIZE=3D2>> counter that, you</FONT>
<BR><FONT SIZE=3D2>> need a "secure" distribution =
mechanism.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> I frankly don't buy that argument, =
though. What is required </FONT>
<BR><FONT SIZE=3D2>> in a PKI is that I</FONT>
<BR><FONT SIZE=3D2>> somehow securely obtain the certificate/public =
key of a CA </FONT>
<BR><FONT SIZE=3D2>> that I have chosen</FONT>
<BR><FONT SIZE=3D2>> to trust - normally, that's the one that issued =
my </FONT>
<BR><FONT SIZE=3D2>> certificate. If this first</FONT>
<BR><FONT SIZE=3D2>> step is broken - I'm fooled into accepting a =
certificate from </FONT>
<BR><FONT SIZE=3D2>> a phony CA, or</FONT>
<BR><FONT SIZE=3D2>> whatever - then the security of the entire PKI =
is shot, and </FONT>
<BR><FONT SIZE=3D2>> no X.500 directory</FONT>
<BR><FONT SIZE=3D2>> or other mechanism is going to help. Once =
I have that public </FONT>
<BR><FONT SIZE=3D2>> key, though, I</FONT>
<BR><FONT SIZE=3D2>> can detect any faked certificates based on the =
trust my CA </FONT>
<BR><FONT SIZE=3D2>> has. My CA will</FONT>
<BR><FONT SIZE=3D2>> have cross-certified with the REAL VeriSign =
Class 3 primary </FONT>
<BR><FONT SIZE=3D2>> CA (when WHAT</FONT>
<BR><FONT SIZE=3D2>> freezes over? :-) Thus, even if I =
get your phony VeriSign </FONT>
<BR><FONT SIZE=3D2>> cert that looks to</FONT>
<BR><FONT SIZE=3D2>> be the right one based on the name, I can't =
build a </FONT>
<BR><FONT SIZE=3D2>> certification path back to</FONT>
<BR><FONT SIZE=3D2>> a node I trust, because my CA or whomever else =
I trust hasn't </FONT>
<BR><FONT SIZE=3D2>> signed your</FONT>
<BR><FONT SIZE=3D2>> spoof. I'm protected against your spoof =
by the certificates </FONT>
<BR><FONT SIZE=3D2>> and CRLs, not the</FONT>
<BR><FONT SIZE=3D2>> distribution mechanism.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> (Of course, if you can trick the people I trust =
- my CA, for </FONT>
<BR><FONT SIZE=3D2>> example - into</FONT>
<BR><FONT SIZE=3D2>> cross-certifying your fake certificate, I'm =
hosed. But that </FONT>
<BR><FONT SIZE=3D2>> just means that I</FONT>
<BR><FONT SIZE=3D2>> trusted some incompetent fool I shouldn't =
have. A '"secure" </FONT>
<BR><FONT SIZE=3D2>> X.500 directory</FONT>
<BR><FONT SIZE=3D2>> won't help at all once my CA has botched =
it.)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT =
SIZE=3D2>>  =
;  =
;  =
; Al Arsenault</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> --- standard disclaimer - my own opinions; =
don't reflect </FONT>
<BR><FONT SIZE=3D2>> those of my employer</FONT>
<BR><FONT SIZE=3D2>> or of any other organization to which I may =
have a </FONT>
<BR><FONT SIZE=3D2>> relationship; etc., etc., ad</FONT>
<BR><FONT SIZE=3D2>> infinitum, ad nauseum</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> =
</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> At 11:06 AM 10/30/98 +0000, GBland@zergo.com =
wrote: </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > How are you going to do all this ? </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > The only way I can think of is that either =
you know or have </FONT>
<BR><FONT SIZE=3D2>> compromised the</FONT>
<BR><FONT SIZE=3D2>> > CA private keys. </FONT>
<BR><FONT SIZE=3D2>> > If you know the private signature keys =
then all information </FONT>
<BR><FONT SIZE=3D2>> is compromised</FONT>
<BR><FONT SIZE=3D2>> > regardless of source. </FONT>
<BR><FONT SIZE=3D2>> > If you don't how will you construct the =
Certificates, CRLs, </FONT>
<BR><FONT SIZE=3D2>> OCSP responses</FONT>
<BR><FONT SIZE=3D2>> > etc. </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > This is an attack based on the compromise =
of the CA, not </FONT>
<BR><FONT SIZE=3D2>> the security of DNS</FONT>
<BR><FONT SIZE=3D2>> > OCSP etc. </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > Graham Bland </FONT>
<BR><FONT SIZE=3D2>> ></FONT>
<BR><FONT SIZE=3D2>> > > -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>> > > From: Ron Ramsay</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> [<<A =
HREF=3D"mailto:Ron.Ramsay@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Ron.Ramsay@OpenDirectory.com.au</A>><A =
HREF=3D"mailto:Ron.Ramsay@Ope" =
TARGET=3D"_blank">mailto:Ron.Ramsay@Ope</A></FONT>
<BR><FONT SIZE=3D2>> nDirectory.c</FONT>
<BR><FONT SIZE=3D2>> > om.au] </FONT>
<BR><FONT SIZE=3D2>> > > Sent: 30 October 1998 02:42 </FONT>
<BR><FONT SIZE=3D2>> > > To: 'Phillip M Hallam-Baker'; Ron =
Ramsay; Alan Lloyd </FONT>
<BR><FONT SIZE=3D2>> > > Cc: Stephen Kent; ietf-pkix@imc.org; =
Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > Subject: RE: Scale (and the SRV =
record) </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Thanks again. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Let me pick up on two points. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Firsly, DNS security. If I can spoof =
DNS (which doesn't look </FONT>
<BR><FONT SIZE=3D2>> > > to hard) I </FONT>
<BR><FONT SIZE=3D2>> > > can provide the address of my server =
in any of the records of </FONT>
<BR><FONT SIZE=3D2>> > > interest. </FONT>
<BR><FONT SIZE=3D2>> > > A request for your certificate will =
come to my server and </FONT>
<BR><FONT SIZE=3D2>> I will send </FONT>
<BR><FONT SIZE=3D2>> > > back the certificate that I have =
constructed for you. If </FONT>
<BR><FONT SIZE=3D2>> you ask for a </FONT>
<BR><FONT SIZE=3D2>> > > CRL I will give you one that doesn't =
name this </FONT>
<BR><FONT SIZE=3D2>> certificate. If you </FONT>
<BR><FONT SIZE=3D2>> > > choose to use a validation service =
like OCSP that's OK </FONT>
<BR><FONT SIZE=3D2>> because I'll </FONT>
<BR><FONT SIZE=3D2>> > > return 'valid' for your/my =
certificate. </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Denial of service is the best bad =
behaviour you can </FONT>
<BR><FONT SIZE=3D2>> expect. Positively </FONT>
<BR><FONT SIZE=3D2>> > > helpful service is much worse! =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Secondly, you're going to send your =
certificate with the </FONT>
<BR><FONT SIZE=3D2>> > > message. Why, I </FONT>
<BR><FONT SIZE=3D2>> > > shall do that too! So I'm still you! =
</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > It is interesting you say that the =
worst that can happen </FONT>
<BR><FONT SIZE=3D2>> is that you </FONT>
<BR><FONT SIZE=3D2>> > > receive a certificate you don't =
trust. How do you know </FONT>
<BR><FONT SIZE=3D2>> you don't trust </FONT>
<BR><FONT SIZE=3D2>> > > it? I should think if you already =
know what certificates you </FONT>
<BR><FONT SIZE=3D2>> > > trust then </FONT>
<BR><FONT SIZE=3D2>> > > you don't need PKI at all! </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Ron. </FONT>
<BR><FONT SIZE=3D2>> > > > -----Original Message----- =
</FONT>
<BR><FONT SIZE=3D2>> > > > =
From: Phillip M Hallam-Baker =
[SMTP:pbaker@verisign.com] </FONT>
<BR><FONT SIZE=3D2>> > > > =
Sent: Friday, October 30, 1998 2:38 =
AM </FONT>
<BR><FONT SIZE=3D2>> > > > To:Ron Ramsay; Alan Lloyd =
</FONT>
<BR><FONT SIZE=3D2>> > > > Cc:Stephen Kent; =
ietf-pkix@imc.org; Rick Harvey </FONT>
<BR><FONT SIZE=3D2>> > > > Subject: RE: =
Scale (and the SRV record) </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Phillip, </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Thanks for taking time to =
develop the example. </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > Two issues: </FONT>
<BR><FONT SIZE=3D2>> > > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > 1. Surely DNS is not =
secure? </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > Define secure? With the =
exception of a denial of </FONT>
<BR><FONT SIZE=3D2>> service attack DNS </FONT>
<BR><FONT SIZE=3D2>> > > > is 'secure enough' for this =
purpose since there is no </FONT>
<BR><FONT SIZE=3D2>> trust placed </FONT>
<BR><FONT SIZE=3D2>> > > > on the server. The origin of a =
signed message is </FONT>
<BR><FONT SIZE=3D2>> irrelevant. Only </FONT>
<BR><FONT SIZE=3D2>> > > > the signature is relevant. =
</FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > > 2. Your example seems to be =
based on encryption using </FONT>
<BR><FONT SIZE=3D2>> public keys. </FONT>
<BR><FONT SIZE=3D2>> > > > From </FONT>
<BR><FONT SIZE=3D2>> > > > > what I know of the public =
key system, it is not used for </FONT>
<BR><FONT SIZE=3D2>> > > encryption. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > I think you are confusing DNS =
security here with PKIX. </FONT>
<BR><FONT SIZE=3D2>> The two are </FONT>
<BR><FONT SIZE=3D2>> > > > very </FONT>
<BR><FONT SIZE=3D2>> > > > separate. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > If someone spoofed DNS the worst =
that would happen is </FONT>
<BR><FONT SIZE=3D2>> that I would </FONT>
<BR><FONT SIZE=3D2>> > > > recieve a certificate I didn't =
trust (and would ignore) or no </FONT>
<BR><FONT SIZE=3D2>> > > > certificate </FONT>
<BR><FONT SIZE=3D2>> > > > at all. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > >Its </FONT>
<BR><FONT SIZE=3D2>> > > > > purpose is authentication =
and integrity. To bend your </FONT>
<BR><FONT SIZE=3D2>> example, you </FONT>
<BR><FONT SIZE=3D2>> > > > will </FONT>
<BR><FONT SIZE=3D2>> > > > > be encrypting your message =
with your own private key. </FONT>
<BR><FONT SIZE=3D2>> How is an </FONT>
<BR><FONT SIZE=3D2>> > > > > addressee to verify it was =
you who sent the message </FONT>
<BR><FONT SIZE=3D2>> and that the </FONT>
<BR><FONT SIZE=3D2>> > > > message </FONT>
<BR><FONT SIZE=3D2>> > > > > was not modified? </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > > I send my signing certificate =
with the message. Or once the </FONT>
<BR><FONT SIZE=3D2>> > > > infrastructure </FONT>
<BR><FONT SIZE=3D2>> > > > is deployed the recipient could =
use the SRV pointer to locate a </FONT>
<BR><FONT SIZE=3D2>> > > > directory </FONT>
<BR><FONT SIZE=3D2>> > > > where a copy of the certificate =
was available. </FONT>
<BR><FONT SIZE=3D2>> > > > </FONT>
<BR><FONT SIZE=3D2>> > > =
> Phill </FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE040A.EF04FF3E--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA23083 for ietf-pkix-bks; Fri, 30 Oct 1998 05:33:57 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA23078 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 05:33:56 -0800 (PST)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id FAA08850; Fri, 30 Oct 1998 05:34:25 -0800 (PST)
Message-Id: <4.1.19981030074722.00a2d6f0@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 30 Oct 1998 08:29:14 -0500
To: GBland@zergo.com, ietf-pkix@imc.org
From: Al Arsenault <aarsenault@spyrus.com>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <199810301234.MAA22292@ns0.zergo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Since I agree with most of what Phill has to say on this topic, I'll go against
my better judgement and jump in here.
If I'm understanding this correctly, the attack of concern is as follows:
Nothing today stops me from cobbling together my own certificate-generating and
-signing software, and then generating a self-signed certificate for user "US
Verisign Primary Class 3 Public Certificate Authority" (or whatever the magic
string is that will exactly match what VeriSign uses). This new certificate
will use the public key corresponding to a private key that I know, rather than
the one that VeriSign actually uses. (This ignores the scenario described by
Graham, in which I've managed to obtain VeriSign's private key.)
Given this, can I get you, the unsuspecting user, to use MY certificate (and
any user certificates I then issue with it) instead of the real one? After
all, once you've retrieved the certificate, the DN or subjectAltName field will
LOOK "right" to you, if you bother to check it. The argument has been that
given an insecure, spoofable, distribution mechanism, I might be able to fool
you into using the wrong "VeriSign certificate". If, for example, I can spoof
DNS and make you think that the IP address corresponding to "VeriSign.com" is,
say, 130.85.1.3, and I control that machine (note: I don't :-) then you'll go
there for the "real certificate" and I've got you. So, to counter that, you
need a "secure" distribution mechanism.
I frankly don't buy that argument, though. What is required in a PKI is that I
somehow securely obtain the certificate/public key of a CA that I have chosen
to trust - normally, that's the one that issued my certificate. If this first
step is broken - I'm fooled into accepting a certificate from a phony CA, or
whatever - then the security of the entire PKI is shot, and no X.500 directory
or other mechanism is going to help. Once I have that public key, though, I
can detect any faked certificates based on the trust my CA has. My CA will
have cross-certified with the REAL VeriSign Class 3 primary CA (when WHAT
freezes over? :-) Thus, even if I get your phony VeriSign cert that looks to
be the right one based on the name, I can't build a certification path back to
a node I trust, because my CA or whomever else I trust hasn't signed your
spoof. I'm protected against your spoof by the certificates and CRLs, not the
distribution mechanism.
(Of course, if you can trick the people I trust - my CA, for example - into
cross-certifying your fake certificate, I'm hosed. But that just means that I
trusted some incompetent fool I shouldn't have. A '"secure" X.500 directory
won't help at all once my CA has botched it.)
Al Arsenault
--- standard disclaimer - my own opinions; don't reflect those of my employer
or of any other organization to which I may have a relationship; etc., etc., ad
infinitum, ad nauseum
At 11:06 AM 10/30/98 +0000, GBland@zergo.com wrote:
>
> How are you going to do all this ?
>
> The only way I can think of is that either you know or have compromised the
> CA private keys.
> If you know the private signature keys then all information is compromised
> regardless of source.
> If you don't how will you construct the Certificates, CRLs, OCSP responses
> etc.
>
> This is an attack based on the compromise of the CA, not the security of DNS
> OCSP etc.
>
> Graham Bland
>
> > -----Original Message-----
> > From: Ron Ramsay
> [<mailto:Ron.Ramsay@OpenDirectory.com.au>mailto:Ron.Ramsay@OpenDirectory.c
> om.au]
> > Sent: 30 October 1998 02:42
> > To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > Subject: RE: Scale (and the SRV record)
> >
> >
> > Phillip,
> >
> > Thanks again.
> >
> > Let me pick up on two points.
> >
> > Firsly, DNS security. If I can spoof DNS (which doesn't look
> > to hard) I
> > can provide the address of my server in any of the records of
> > interest.
> > A request for your certificate will come to my server and I will send
> > back the certificate that I have constructed for you. If you ask for a
> > CRL I will give you one that doesn't name this certificate. If you
> > choose to use a validation service like OCSP that's OK because I'll
> > return 'valid' for your/my certificate.
> >
> > Denial of service is the best bad behaviour you can expect. Positively
> > helpful service is much worse!
> >
> > Secondly, you're going to send your certificate with the
> > message. Why, I
> > shall do that too! So I'm still you!
> >
> > It is interesting you say that the worst that can happen is that you
> > receive a certificate you don't trust. How do you know you don't trust
> > it? I should think if you already know what certificates you
> > trust then
> > you don't need PKI at all!
> >
> > Ron.
> > > -----Original Message-----
> > > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > > Sent: Friday, October 30, 1998 2:38 AM
> > > To:Ron Ramsay; Alan Lloyd
> > > Cc:Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > > Subject: RE: Scale (and the SRV record)
> > >
> > >
> > >
> > > > Phillip,
> > > >
> > > > Thanks for taking time to develop the example.
> > > >
> > > > Two issues:
> > > >
> > > > 1. Surely DNS is not secure?
> > >
> > > Define secure? With the exception of a denial of service attack DNS
> > > is 'secure enough' for this purpose since there is no trust placed
> > > on the server. The origin of a signed message is irrelevant. Only
> > > the signature is relevant.
> > >
> > > > 2. Your example seems to be based on encryption using public keys.
> > > From
> > > > what I know of the public key system, it is not used for
> > encryption.
> > >
> > >
> > > I think you are confusing DNS security here with PKIX. The two are
> > > very
> > > separate.
> > >
> > > If someone spoofed DNS the worst that would happen is that I would
> > > recieve a certificate I didn't trust (and would ignore) or no
> > > certificate
> > > at all.
> > >
> > > >Its
> > > > purpose is authentication and integrity. To bend your example, you
> > > will
> > > > be encrypting your message with your own private key. How is an
> > > > addressee to verify it was you who sent the message and that the
> > > message
> > > > was not modified?
> > >
> > > I send my signing certificate with the message. Or once the
> > > infrastructure
> > > is deployed the recipient could use the SRV pointer to locate a
> > > directory
> > > where a copy of the certificate was available.
> > >
> > > Phill
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA22557 for ietf-pkix-bks; Fri, 30 Oct 1998 04:34:45 -0800 (PST)
Received: from smtp.udac.net (smtp.udac.net [193.44.79.123]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA22553 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 04:34:43 -0800 (PST)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by smtp.udac.net (8.9.1/8.9.1) with ESMTP id NAA17357 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 13:36:58 +0100
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id NAA38420; Fri, 30 Oct 1998 13:36:52 +0100
Received: by HYDRA with Microsoft Mail id <01BE0409.59059F30@HYDRA>; Fri, 30 Oct 1998 13:29:40 +0100
Message-ID: <01BE0409.59059F30@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'SEIS-List'" <list@seis.nc-forum.com>, "'Stefan Santesson'" <stefan@accurata.se>
Cc: "ietf-pkix@imc.org" <ietf-pkix@imc.org>
Subject: QC - civicRegistrationNumber
Date: Fri, 30 Oct 1998 13:29:39 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Regarding Qualified Certificates:
civicRegistrationNumber
should IMHO be altered to
civicRegistrationCode
as it does not have to be numeric
Anders Rundgren
Senior Internet E-commerce Architect
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA19218 for ietf-pkix-bks; Fri, 30 Oct 1998 03:06:18 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA19214 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 03:06:13 -0800 (PST)
From: GBland@zergo.com
Message-Id: <199810301234.MAA22292@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
To: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 11:06:06 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE03F5.4A711B70"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE03F5.4A711B70
Content-Type: text/plain
How are you going to do all this ?
The only way I can think of is that either you know or have compromised
the CA private keys.
If you know the private signature keys then all information is
compromised regardless of source.
If you don't how will you construct the Certificates, CRLs, OCSP
responses etc.
This is an attack based on the compromise of the CA, not the security of
DNS OCSP etc.
Graham Bland
> -----Original Message-----
> From: Ron Ramsay [mailto:Ron.Ramsay@OpenDirectory.com.au]
> Sent: 30 October 1998 02:42
> To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> Subject: RE: Scale (and the SRV record)
>
>
> Phillip,
>
> Thanks again.
>
> Let me pick up on two points.
>
> Firsly, DNS security. If I can spoof DNS (which doesn't look
> to hard) I
> can provide the address of my server in any of the records of
> interest.
> A request for your certificate will come to my server and I will send
> back the certificate that I have constructed for you. If you ask for a
> CRL I will give you one that doesn't name this certificate. If you
> choose to use a validation service like OCSP that's OK because I'll
> return 'valid' for your/my certificate.
>
> Denial of service is the best bad behaviour you can expect. Positively
> helpful service is much worse!
>
> Secondly, you're going to send your certificate with the
> message. Why, I
> shall do that too! So I'm still you!
>
> It is interesting you say that the worst that can happen is that you
> receive a certificate you don't trust. How do you know you don't trust
> it? I should think if you already know what certificates you
> trust then
> you don't need PKI at all!
>
> Ron.
> > -----Original Message-----
> > From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> > Sent: Friday, October 30, 1998 2:38 AM
> > To: Ron Ramsay; Alan Lloyd
> > Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> > Subject: RE: Scale (and the SRV record)
> >
> >
> >
> > > Phillip,
> > >
> > > Thanks for taking time to develop the example.
> > >
> > > Two issues:
> > >
> > > 1. Surely DNS is not secure?
> >
> > Define secure? With the exception of a denial of service attack DNS
> > is 'secure enough' for this purpose since there is no trust placed
> > on the server. The origin of a signed message is irrelevant. Only
> > the signature is relevant.
> >
> > > 2. Your example seems to be based on encryption using public keys.
> > From
> > > what I know of the public key system, it is not used for
> encryption.
> >
> >
> > I think you are confusing DNS security here with PKIX. The two are
> > very
> > separate.
> >
> > If someone spoofed DNS the worst that would happen is that I would
> > recieve a certificate I didn't trust (and would ignore) or no
> > certificate
> > at all.
> >
> > >Its
> > > purpose is authentication and integrity. To bend your example, you
> > will
> > > be encrypting your message with your own private key. How is an
> > > addressee to verify it was you who sent the message and that the
> > message
> > > was not modified?
> >
> > I send my signing certificate with the message. Or once the
> > infrastructure
> > is deployed the recipient could use the SRV pointer to locate a
> > directory
> > where a copy of the certificate was available.
> >
> > Phill
>
------ =_NextPart_001_01BE03F5.4A711B70
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>How are you going to do all this ?</FONT>
</P>
<P><FONT SIZE=3D2>The only way I can think of is that either you know =
or have compromised the CA private keys.</FONT>
<BR><FONT SIZE=3D2>If you know the private signature keys then all =
information is compromised regardless of source.</FONT>
<BR><FONT SIZE=3D2>If you don't how will you construct the =
Certificates, CRLs, OCSP responses etc.</FONT>
</P>
<P><FONT SIZE=3D2>This is an attack based on the compromise of the CA, =
not the security of DNS OCSP etc.</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Ron Ramsay [<A =
HREF=3D"mailto:Ron.Ramsay@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Ron.Ramsay@OpenDirectory.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 30 October 1998 02:42</FONT>
<BR><FONT SIZE=3D2>> To: 'Phillip M Hallam-Baker'; Ron Ramsay; Alan =
Lloyd</FONT>
<BR><FONT SIZE=3D2>> Cc: Stephen Kent; ietf-pkix@imc.org; Rick =
Harvey</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Phillip,</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Thanks again.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Let me pick up on two points.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Firsly, DNS security. If I can spoof DNS (which =
doesn't look </FONT>
<BR><FONT SIZE=3D2>> to hard) I</FONT>
<BR><FONT SIZE=3D2>> can provide the address of my server in any of =
the records of </FONT>
<BR><FONT SIZE=3D2>> interest.</FONT>
<BR><FONT SIZE=3D2>> A request for your certificate will come to my =
server and I will send</FONT>
<BR><FONT SIZE=3D2>> back the certificate that I have constructed =
for you. If you ask for a</FONT>
<BR><FONT SIZE=3D2>> CRL I will give you one that doesn't name this =
certificate. If you</FONT>
<BR><FONT SIZE=3D2>> choose to use a validation service like OCSP =
that's OK because I'll</FONT>
<BR><FONT SIZE=3D2>> return 'valid' for your/my certificate.</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Denial of service is the best bad behaviour you =
can expect. Positively</FONT>
<BR><FONT SIZE=3D2>> helpful service is much worse!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Secondly, you're going to send your certificate =
with the </FONT>
<BR><FONT SIZE=3D2>> message. Why, I</FONT>
<BR><FONT SIZE=3D2>> shall do that too! So I'm still you!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> It is interesting you say that the worst that =
can happen is that you</FONT>
<BR><FONT SIZE=3D2>> receive a certificate you don't trust. How do =
you know you don't trust</FONT>
<BR><FONT SIZE=3D2>> it? I should think if you already know what =
certificates you </FONT>
<BR><FONT SIZE=3D2>> trust then</FONT>
<BR><FONT SIZE=3D2>> you don't need PKI at all!</FONT>
<BR><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> Ron.</FONT>
<BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> > From: =
Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]</FONT>
<BR><FONT SIZE=3D2>> > Sent: =
Friday, October 30, 1998 2:38 AM</FONT>
<BR><FONT SIZE=3D2>> > To:Ron Ramsay; Alan Lloyd</FONT>
<BR><FONT SIZE=3D2>> > Cc:Stephen Kent; ietf-pkix@imc.org; Rick =
Harvey</FONT>
<BR><FONT SIZE=3D2>> > Subject: RE: Scale (and =
the SRV record)</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > > Phillip,</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Thanks for taking time to develop the =
example.</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > Two issues:</FONT>
<BR><FONT SIZE=3D2>> > > </FONT>
<BR><FONT SIZE=3D2>> > > 1. Surely DNS is not secure?</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Define secure? With the exception of a =
denial of service attack DNS</FONT>
<BR><FONT SIZE=3D2>> > is 'secure enough' for this purpose since =
there is no trust placed</FONT>
<BR><FONT SIZE=3D2>> > on the server. The origin of a signed =
message is irrelevant. Only</FONT>
<BR><FONT SIZE=3D2>> > the signature is relevant.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > > 2. Your example seems to be based on =
encryption using public keys.</FONT>
<BR><FONT SIZE=3D2>> > From</FONT>
<BR><FONT SIZE=3D2>> > > what I know of the public key system, =
it is not used for </FONT>
<BR><FONT SIZE=3D2>> encryption.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I think you are confusing DNS security =
here with PKIX. The two are</FONT>
<BR><FONT SIZE=3D2>> > very</FONT>
<BR><FONT SIZE=3D2>> > separate.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > If someone spoofed DNS the worst that =
would happen is that I would </FONT>
<BR><FONT SIZE=3D2>> > recieve a certificate I didn't trust (and =
would ignore) or no</FONT>
<BR><FONT SIZE=3D2>> > certificate</FONT>
<BR><FONT SIZE=3D2>> > at all.</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > >Its</FONT>
<BR><FONT SIZE=3D2>> > > purpose is authentication and =
integrity. To bend your example, you</FONT>
<BR><FONT SIZE=3D2>> > will</FONT>
<BR><FONT SIZE=3D2>> > > be encrypting your message with your =
own private key. How is an</FONT>
<BR><FONT SIZE=3D2>> > > addressee to verify it was you who =
sent the message and that the</FONT>
<BR><FONT SIZE=3D2>> > message</FONT>
<BR><FONT SIZE=3D2>> > > was not modified?</FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > I send my signing certificate with the =
message. Or once the</FONT>
<BR><FONT SIZE=3D2>> > infrastructure</FONT>
<BR><FONT SIZE=3D2>> > is deployed the recipient could use the =
SRV pointer to locate a</FONT>
<BR><FONT SIZE=3D2>> > directory</FONT>
<BR><FONT SIZE=3D2>> > where a copy of the certificate was =
available. </FONT>
<BR><FONT SIZE=3D2>> > </FONT>
<BR><FONT SIZE=3D2>> > Phill</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE03F5.4A711B70--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA17840 for ietf-pkix-bks; Fri, 30 Oct 1998 01:33:13 -0800 (PST)
Received: from ns0.zergo.com (ns0.zergo.com [194.159.81.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA17832 for <ietf-pkix@imc.org>; Fri, 30 Oct 1998 01:33:10 -0800 (PST)
Message-Id: <199810301101.LAA21997@ns0.zergo.com>
Received: forwarded by SMTP 3.0.9.
From: Graham Bland <GBland@zergo.com>
To: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:32:51 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: multipart/alternative; boundary="---- =_NextPart_001_01BE03E8.438B173C"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
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_01BE03E8.438B173C
Content-Type: text/plain;
charset="iso-8859-1"
Large portions of original message deleted for readability, relevant
sections only maintained with comments in line.
Graham Bland
> -----Original Message-----
> From: Alan Lloyd [mailto:Alan.Lloyd@OpenDirectory.com.au]
> Sent: 29 October 1998 21:37
> To: 'Bill Burr'; Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
...deleted
> > I have been saying for some time that don't know of anybody who has
> > built
> > an X.500 directory of a size that convinces me that it is a viable
> > technology to base a US national PKI, or even a US Federal
> > government-wide
> > PKI on. I keep asking the question, where are the really big
> > distributed
> > X.500 directories? Particularly multivendor directories.
> But I don't
> > seem
> > to get any answers. What I hear are horror stories about the
> > difficulties
> > of getting any two X.500 products to work together.
> [Alan Lloyd]
> No horror stories from us. 20 million entries, 1000s of searches
> a second, distributed, multi master, etc We have very scaleable,
> distributed technology - that also integrates LDAP servers, etc We are
> very busy deploying X.500 into major corporate infrastructures who are
> following the themes I described. Including those in the US.
> Please read
> our WEB site. "Uses of Directory Services"
>
Can I access these directories or are they private islands. If they are
private islands then they might as well not exist.
> > If the X.500 directory industry builds products that interoperate
> > and scale
> > well, it has done a really bad job of getting the word out.
> [Alan Lloyd]
> My view here is that the LDAP hype has done a really good job of
> damaging X.500. However, now the LDAP hype has dissipated and reality
> has set in we are left with a protocol that can only ACCESS a
> directory
> service ? is twice as big as DAP and has half the functionality. In
> addition, getting LDAP only solutions is proving to many that X.500 is
> the way to go because of LDAPs NO distribution and a model
> that demands
> Replicate everything to everywhere. LDAP has high operational
> costs and
> gets to a point where it is unworkable.
> So LDAP accessed X.500 in my book is the way to go and is being
> deployed globally.
I think you meant to say DAP accessed X.500 from the flow of the text
>
> > Until now, I have also been saying, does anybody have a believable
> > alternative to the mythological, pervasive X.500 directory service?
> > It
> > seemed almost a rhetorical question. But I think perhaps Phill has
> > outlined an alternative, that looks like it probably ought to work,
> > and is
> > based on something, DNS, that we know works well, scales well, and
> > exists
> > now. Moreover, we should be able to create the service we need
> > incrementally, by just by adding servers as we need them, one at a
> > time.
> > And, If I understand the proposal, all we have to do is
> agree on some
> > simple naming conventions.
> [Alan Lloyd] I am not against alternative proposals - its all a
> question of how much effort and implementation goes behind it. Phills
> solution has to be backed by all the DNS and PKI suppliers on this
> planet and DNS then has to become secure - with signed operations,
> mutual authentication, access controls, real life naming, and scale a
> lot better and of course be easy to manage and follow Object Oriented
> design. (does this mean turning DNS into X.500?) I would vote
> for that -
> thats more X.500!
Why would DNS need to be more secure with signed operations mutual
authentication etc. Certificates and CRLs are signed objects and their
security is inherent. Ignoring denial of service I cannot see any
attacks from an insecure distribution method. The whole point of the
distribution method is that I have no trust relationship with it and
have no need of a trust relationship be it email, X.500 or anything
else.
How is it relevant if DNS follows OO design, why should it. While I
agree that OO design and methods have many advantages the relevant
questions are does it work and how much will it cost, not what its
internal structure is.
What is the problem with the scalability of DNS (How many users does it
support now ?)
X.500 is easy to manage? later you say "But LDAP did prove that
directorys are difficult
and complex and X.500 got most things right."
Graham Bland
------ =_NextPart_001_01BE03E8.438B173C
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.1960.3">
<TITLE>RE: Scale (and the SRV record)</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=3D2>Large portions of original message deleted for =
readability, relevant sections only maintained with comments in =
line.</FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
<P><FONT SIZE=3D2>> -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>> From: Alan Lloyd [<A =
HREF=3D"mailto:Alan.Lloyd@OpenDirectory.com.au" =
TARGET=3D"_blank">mailto:Alan.Lloyd@OpenDirectory.com.au</A>]</FONT>
<BR><FONT SIZE=3D2>> Sent: 29 October 1998 21:37</FONT>
<BR><FONT SIZE=3D2>> To: 'Bill Burr'; Alan Lloyd; 'Phillip M =
Hallam-Baker'; Russ Housley;</FONT>
<BR><FONT SIZE=3D2>> ietf-pkix@imc.org</FONT>
<BR><FONT SIZE=3D2>> Subject: RE: Scale (and the SRV record)</FONT>
</P>
<P><FONT SIZE=3D2>...deleted</FONT>
<BR><FONT SIZE=3D2>> > I have been saying for some time that =
don't know of anybody who has</FONT>
<BR><FONT SIZE=3D2>> > built</FONT>
<BR><FONT SIZE=3D2>> > an X.500 directory of a size that =
convinces me that it is a viable</FONT>
<BR><FONT SIZE=3D2>> > technology to base a US national PKI, or =
even a US Federal</FONT>
<BR><FONT SIZE=3D2>> > government-wide</FONT>
<BR><FONT SIZE=3D2>> > PKI on. I keep asking the question, where =
are the really big</FONT>
<BR><FONT SIZE=3D2>> > distributed</FONT>
<BR><FONT SIZE=3D2>> > X.500 directories? Particularly =
multivendor directories. </FONT>
<BR><FONT SIZE=3D2>> But I don't</FONT>
<BR><FONT SIZE=3D2>> > seem</FONT>
<BR><FONT SIZE=3D2>> > to get any answers. What I hear are =
horror stories about the</FONT>
<BR><FONT SIZE=3D2>> > difficulties</FONT>
<BR><FONT SIZE=3D2>> > of getting any two X.500 products to work =
together.</FONT>
<BR><FONT SIZE=3D2>> [Alan =
Lloyd] </FONT>
<BR><FONT SIZE=3D2>> No horror =
stories from us. 20 million entries, 1000s of searches</FONT>
<BR><FONT SIZE=3D2>> a second, distributed, multi master, etc We =
have very scaleable,</FONT>
<BR><FONT SIZE=3D2>> distributed technology - that also integrates =
LDAP servers, etc We are</FONT>
<BR><FONT SIZE=3D2>> very busy deploying X.500 into major corporate =
infrastructures who are</FONT>
<BR><FONT SIZE=3D2>> following the themes I described. Including =
those in the US. </FONT>
<BR><FONT SIZE=3D2>> Please read</FONT>
<BR><FONT SIZE=3D2>> our WEB site. "Uses of Directory =
Services"</FONT>
<BR><FONT SIZE=3D2>> </FONT>
</P>
<P><FONT SIZE=3D2>Can I access these directories or are they private =
islands. If they are private islands then they might as well not =
exist.</FONT></P>
<BR>
<P><FONT SIZE=3D2>> > If the X.500 directory industry =
builds products that interoperate</FONT>
<BR><FONT SIZE=3D2>> > and scale</FONT>
<BR><FONT SIZE=3D2>> > well, it has done a really bad job of =
getting the word out. </FONT>
<BR><FONT SIZE=3D2>> [Alan =
Lloyd] </FONT>
<BR><FONT SIZE=3D2>> My view here is =
that the LDAP hype has done a really good job of</FONT>
<BR><FONT SIZE=3D2>> damaging X.500. However, now the LDAP hype has =
dissipated and reality</FONT>
<BR><FONT SIZE=3D2>> has set in we are left with a protocol that can =
only ACCESS a </FONT>
<BR><FONT SIZE=3D2>> directory</FONT>
<BR><FONT SIZE=3D2>> service ? is twice as big as DAP and has half =
the functionality. In</FONT>
<BR><FONT SIZE=3D2>> addition, getting LDAP only solutions is =
proving to many that X.500 is</FONT>
<BR><FONT SIZE=3D2>> the way to go because of LDAPs NO distribution =
and a model </FONT>
<BR><FONT SIZE=3D2>> that demands</FONT>
<BR><FONT SIZE=3D2>> Replicate everything to everywhere. LDAP has =
high operational </FONT>
<BR><FONT SIZE=3D2>> costs and</FONT>
<BR><FONT SIZE=3D2>> gets to a point where it is unworkable.</FONT>
<BR><FONT SIZE=3D2>> So LDAP accessed =
X.500 in my book is the way to go and is being</FONT>
<BR><FONT SIZE=3D2>> deployed globally.</FONT>
</P>
<P><FONT SIZE=3D2>I think you meant to say DAP accessed X.500 from the =
flow of the text</FONT>
</P>
<P><FONT SIZE=3D2>> </FONT>
<BR><FONT SIZE=3D2>> > Until now, I have also been saying, =
does anybody have a believable</FONT>
<BR><FONT SIZE=3D2>> > alternative to the mythological, pervasive =
X.500 directory service?</FONT>
<BR><FONT SIZE=3D2>> > It</FONT>
<BR><FONT SIZE=3D2>> > seemed almost a rhetorical question. =
But I think perhaps Phill has</FONT>
<BR><FONT SIZE=3D2>> > outlined an alternative, that looks like =
it probably ought to work,</FONT>
<BR><FONT SIZE=3D2>> > and is</FONT>
<BR><FONT SIZE=3D2>> > based on something, DNS, that we know =
works well, scales well, and</FONT>
<BR><FONT SIZE=3D2>> > exists</FONT>
<BR><FONT SIZE=3D2>> > now. Moreover, we should be able to create =
the service we need</FONT>
<BR><FONT SIZE=3D2>> > incrementally, by just by adding servers =
as we need them, one at a</FONT>
<BR><FONT SIZE=3D2>> > time.</FONT>
<BR><FONT SIZE=3D2>> > And, If I understand the proposal, all we =
have to do is </FONT>
<BR><FONT SIZE=3D2>> agree on some</FONT>
<BR><FONT SIZE=3D2>> > simple naming conventions.</FONT>
<BR><FONT SIZE=3D2>> [Alan =
Lloyd] I am not against alternative proposals - its all a</FONT>
<BR><FONT SIZE=3D2>> question of how much effort and implementation =
goes behind it. Phills</FONT>
<BR><FONT SIZE=3D2>> solution has to be backed by all the DNS and =
PKI suppliers on this</FONT>
<BR><FONT SIZE=3D2>> planet and DNS then has to become secure - with =
signed operations,</FONT>
<BR><FONT SIZE=3D2>> mutual authentication, access controls, real =
life naming, and scale a</FONT>
<BR><FONT SIZE=3D2>> lot better and of course be easy to manage and =
follow Object Oriented</FONT>
<BR><FONT SIZE=3D2>> design. (does this mean turning DNS into =
X.500?) I would vote </FONT>
<BR><FONT SIZE=3D2>> for that -</FONT>
<BR><FONT SIZE=3D2>> thats more X.500!</FONT>
</P>
<P><FONT SIZE=3D2>Why would DNS need to be more secure with signed =
operations mutual authentication etc. Certificates and CRLs are signed =
objects and their security is inherent. Ignoring denial of =
service I cannot see any attacks from an insecure distribution =
method. The whole point of the distribution method is that I have =
no trust relationship with it and have no need of a trust relationship =
be it email, X.500 or anything else.</FONT></P>
<P><FONT SIZE=3D2>How is it relevant if DNS follows OO design, why =
should it. While I agree that OO design and methods have many =
advantages the relevant questions are does it work and how much will it =
cost, not what its internal structure is.</FONT></P>
<P><FONT SIZE=3D2>What is the problem with the scalability of DNS (How =
many users does it support now ?)</FONT>
</P>
<P><FONT SIZE=3D2>X.500 is easy to manage? later you say "But LDAP =
did prove that directorys are difficult</FONT>
<BR><FONT SIZE=3D2> and complex and X.500 got most things =
right." </FONT>
</P>
<P><FONT SIZE=3D2>Graham Bland</FONT>
</P>
</BODY>
</HTML>
------ =_NextPart_001_01BE03E8.438B173C--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA27821 for ietf-pkix-bks; Thu, 29 Oct 1998 18:44:29 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA27815 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 18:44:21 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PNR>; Fri, 30 Oct 1998 13:42:14 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0656C6@DSG1>
From: Ron Ramsay <Ron.Ramsay@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Ron Ramsay <Ron.Ramsay@OpenDirectory.com.au>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org, Rick Harvey <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 13:42:13 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phillip,
Thanks again.
Let me pick up on two points.
Firsly, DNS security. If I can spoof DNS (which doesn't look to hard) I
can provide the address of my server in any of the records of interest.
A request for your certificate will come to my server and I will send
back the certificate that I have constructed for you. If you ask for a
CRL I will give you one that doesn't name this certificate. If you
choose to use a validation service like OCSP that's OK because I'll
return 'valid' for your/my certificate.
Denial of service is the best bad behaviour you can expect. Positively
helpful service is much worse!
Secondly, you're going to send your certificate with the message. Why, I
shall do that too! So I'm still you!
It is interesting you say that the worst that can happen is that you
receive a certificate you don't trust. How do you know you don't trust
it? I should think if you already know what certificates you trust then
you don't need PKI at all!
Ron.
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, October 30, 1998 2:38 AM
> To: Ron Ramsay; Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org; Rick Harvey
> Subject: RE: Scale (and the SRV record)
>
>
>
> > Phillip,
> >
> > Thanks for taking time to develop the example.
> >
> > Two issues:
> >
> > 1. Surely DNS is not secure?
>
> Define secure? With the exception of a denial of service attack DNS
> is 'secure enough' for this purpose since there is no trust placed
> on the server. The origin of a signed message is irrelevant. Only
> the signature is relevant.
>
> > 2. Your example seems to be based on encryption using public keys.
> From
> > what I know of the public key system, it is not used for encryption.
>
>
> I think you are confusing DNS security here with PKIX. The two are
> very
> separate.
>
> If someone spoofed DNS the worst that would happen is that I would
> recieve a certificate I didn't trust (and would ignore) or no
> certificate
> at all.
>
> >Its
> > purpose is authentication and integrity. To bend your example, you
> will
> > be encrypting your message with your own private key. How is an
> > addressee to verify it was you who sent the message and that the
> message
> > was not modified?
>
> I send my signing certificate with the message. Or once the
> infrastructure
> is deployed the recipient could use the SRV pointer to locate a
> directory
> where a copy of the certificate was available.
>
> Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27269 for ietf-pkix-bks; Thu, 29 Oct 1998 17:45:20 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27265 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 17:45:17 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PNH>; Fri, 30 Oct 1998 12:43:04 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4D7@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: More - RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 12:43:03 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill in the email I sent I did ask some questions re OCSP and its
information model and how it does work with recipents who get many
messages for anywhere. No answers to these questions make OCSP a
mechanism, not a solution.
And the reason for all this debate is how we easily support the multi
domain validation process in a way that scales, keeps client software as
simple as possible and from a conceptual point of view provides CAs/PKI
suppliers with a way that enables them to upgrade their information
models and services without affecting all the client software concerned.
In addition most have recognised that a large scale PKI function must
align to business information systems and service delivery requirements.
The issue is still open I believe.
However, the proposals to investigate the use of directory matching
rules in support of a validation service and directory enable PKI
validation functions are still on the table.
Any one want to progress these views?
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, 30 October 1998 11:19
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA27074 for ietf-pkix-bks; Thu, 29 Oct 1998 17:15:07 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA27067 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 17:14:58 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PNC>; Fri, 30 Oct 1998 12:12:49 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4D3@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 12:12:48 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill - this one jumped to light speed eh? Comments as usual follow.
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, 30 October 1998 11:19
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> > > Hence the motivation for an Online Status service like OCSP.
> > [Alan Lloyd] Please enlighten me.
> > Companies make telephones based on the fact that there is a
> > distributed telephone network (switching infrastructure) out there
> that
> > supports global numbering and common protocols.
>
> The Internet is not like a telephone service. It is a network of
> networks
> and not a network.
[Alan Lloyd] So is the phone service - see BT, AT&T, NTT, I
wonder what the P in PABX means.
> The differences between the circuit switching infrastructure of the
> telephone system and the packet switching infrastructure of the
> Internet
> are significant and fundamental. The telephone system is optimized for
> voice, not data. As the role of data networks increases it is the
> telephone infrastructure which is being absorbed into the data network
> and not vice versa.
[Alan Lloyd] The telephone paradigm is used to indicate an
infrastructure which is distributed, owned by many, applies universal
numbering plans and scales efficiently.
It was not used in the debate to talk of bits and bytes.
> Don't try to re-fight the OSI vs IP protocol stack wars. This is not
> the place to do that. You might as well advocate gun control in
> talk.guns
> or go to a Klu-Klux-Klanbake and advocate racial tollerance. Nobody is
>
> arguing that directories do not have an important role in the
> Internet.
> But you seem to have to insist that everything that could be done by
> a directory SHOULD indeed MUST be done by one or it will fail to meet
> the catalog of noise word criteria you state.
[Alan Lloyd] Warp 7 on this one. I just say that when
directories are applied as the information infrastructure then PKIs are
much better and collectively they suit service provisioning for
businesses more efficiently. This is natural and expected being that
X.509 and PKIs is part of the X.500 directory standards.
(But isnt it odd that ASN.1 was defined as the tool for creating
presentation layers (layer 6 in OSI) and now its in many
specifications.)
> I don't think you are doing a very good job of being an advocate for
> directories. When you lump them together with terms that are so
> overused
> as to be meaningless marketing noise I suspect that many people will
> dismiss directories as another sales pitch hype
[Alan Lloyd] But there are many that arent - to their benefit.
> which will promise
> everything but deliver little: Object oriented - Isn't everything?
> Scale - in whose laboratory? Oh its a pitch for a directory and it
> will solve all my problems - I'll buy 3, make that 4 if it will also
> solve my Y2K. Do you support OpenGenera?
[Alan Lloyd] You obviously have one world, I have another. I
help design large scale distributed (secure) information systems that
work across continents so my views might be different to yours.
> The directory plays a very specific role in a PKI as a repository of
> signed objects. It does not create signed objects, it does not vouch
> for their trustworthiness.
[Alan Lloyd] Never said it did.
> It does not replace DNS.
[Alan Lloyd] But it could and may be it will.
> How the directory
> system manages its bits is its own affair. It is not the concern of
> the PKI except that the PKI must not rely on the directory service to
> fulfil expectations it is not capable of meeting.
[Alan Lloyd] Thats a view again. Not mine.
> There are roles for other types of PKI components but they are not
> called directories. They may share parts of the code base, they may
> re-use the protocols but it is not usefull to call everything a
> directory just because as Dilbert and Wally said 'we always build
> a directory', 'we like directories'[1].
[Alan Lloyd] Never said that a directory does everything. Just
said that a PKI is a Directory enabled function, so that distribution,
scaleability and a common information service paradigm can be applied -
rather that bespoke protocols and mechanisms that seem to provide
mystery and misery and limited functionality.
High functionality distributed infrastructure provides a
capability eg a telephone service or a directory service. Why not use it
rather than try to re-invent it?
regards alan
> Phill
>
> [1] I know it was actually a database.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26618 for ietf-pkix-bks; Thu, 29 Oct 1998 16:16:26 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26614 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 16:16:25 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id QAA22307; Thu, 29 Oct 1998 16:15:57 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id QAA06056; Thu, 29 Oct 1998 16:18:10 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 19:19:02 -0500
Message-ID: <004601be039a$e5c20fe0$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <D1A949D4508DD1119C8100400533BEDC05D4D1@DSG1>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> > Hence the motivation for an Online Status service like OCSP.
> [Alan Lloyd] Please enlighten me.
> Companies make telephones based on the fact that there is a
> distributed telephone network (switching infrastructure) out there that
> supports global numbering and common protocols.
The Internet is not like a telephone service. It is a network of networks
and not a network.
The differences between the circuit switching infrastructure of the
telephone system and the packet switching infrastructure of the Internet
are significant and fundamental. The telephone system is optimized for
voice, not data. As the role of data networks increases it is the
telephone infrastructure which is being absorbed into the data network
and not vice versa.
Don't try to re-fight the OSI vs IP protocol stack wars. This is not
the place to do that. You might as well advocate gun control in talk.guns
or go to a Klu-Klux-Klanbake and advocate racial tollerance. Nobody is
arguing that directories do not have an important role in the Internet.
But you seem to have to insist that everything that could be done by
a directory SHOULD indeed MUST be done by one or it will fail to meet
the catalog of noise word criteria you state.
I don't think you are doing a very good job of being an advocate for
directories. When you lump them together with terms that are so overused
as to be meaningless marketing noise I suspect that many people will
dismiss directories as another sales pitch hype which will promise
everything but deliver little: Object oriented - Isn't everything?
Scale - in whose laboratory? Oh its a pitch for a directory and it
will solve all my problems - I'll buy 3, make that 4 if it will also
solve my Y2K. Do you support OpenGenera?
The directory plays a very specific role in a PKI as a repository of
signed objects. It does not create signed objects, it does not vouch
for their trustworthiness. It does not replace DNS. How the directory
system manages its bits is its own affair. It is not the concern of
the PKI except that the PKI must not rely on the directory service to
fulfil expectations it is not capable of meeting.
There are roles for other types of PKI components but they are not
called directories. They may share parts of the code base, they may
re-use the protocols but it is not usefull to call everything a
directory just because as Dilbert and Wally said 'we always build
a directory', 'we like directories'[1].
Phill
[1] I know it was actually a database.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA25943 for ietf-pkix-bks; Thu, 29 Oct 1998 14:18:57 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA25939 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 14:18:50 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PMT>; Fri, 30 Oct 1998 09:16:43 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4D1@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 09:16:41 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
HMMMMMMMMMMMMMMMM!
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Friday, 30 October 1998 6:55
> To: salzr@certco.com
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
>
>
> > >If someone spoofed DNS the worst that would happen is that I would
> > >recieve a certificate I didn't trust (and would ignore) or no
> > >certificate
> > at all.
> >
> > Well, if you're only fetching certificates, probably.
> >
> > But if you're fetching CRL's, then no. Suppose a cert is
> compromised,
> > and CRLn is issued before the "next update" time purely because of
> > that compromise. The adversary could spoof DNS and just send out
> > the valid, but outdated CRL(n-1) and potentially have quite a
> > window of opportunity.
>
> Hence the motivation for an Online Status service like OCSP.
[Alan Lloyd] Please enlighten me.
Companies make telephones based on the fact that there is a
distributed telephone network (switching infrastructure) out there that
supports global numbering and common protocols.
I thought that as X.509, certs, crls and CAs as used in PKIs are
part of globally named (or within a domain) named objects that reside in
a directory service (X.500), that those building PKIs would use the
distributed information infrastucture to support such functions. Not re
invent the infrastucture by disjoint mechanisms.
I hear the words Meta certs, OCSP, but what is the distributed
information infrastructure that supports it?
How is this modelled, how does it scale, who builds the clients,
what is the knowledge and configuration issues. How does a recipient
client know when it receives a signed message that one of the many OCSP
servers it knows about is responsible for validation or validation is
via the directory service. Do OCSP servers connect to the directory
service.... What is the SYSTEM (that scales) and whats the Business
level Information design . How does the OCSP architecture (what ever
that is) fit in with business service delivery?
There is a difference between a "protocol mechanism" to a
"server" and a directory service.
regards alan
> Alternatively use the OCDP mechanism to provide a 'meta CRL'. A
> master
> CRL can be issued every minute which would contain a list (CRLList) of
>
> the most current CRLs in each partition.
>
> This issue is orthogonal to the issue of directory discovery however.
> Any infrastructure for distributing CRLs has the same problem. I don't
> see that the solution is to attempt to guarantee delivery of the CRLs
> by hypothesizing secure infrastructures will be installed. I believe
> we should address the issue by removing the dependence.
>
>
> Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA25765 for ietf-pkix-bks; Thu, 29 Oct 1998 13:39:37 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA25760 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 13:39:24 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PMK>; Fri, 30 Oct 1998 08:37:16 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4CC@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Bill Burr'" <william.burr@nist.gov>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Fri, 30 Oct 1998 08:37:13 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line.
> -----Original Message-----
> From: Bill Burr [SMTP:william.burr@nist.gov]
> Sent: Friday, 30 October 1998 2:34
> To: Alan Lloyd; 'Phillip M Hallam-Baker'; Russ Housley;
> ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> Alan,
>
> I'm more than a little confused about what it is that makes X.500
> directories particularly OO things. Is mashing the world into an
> X.500 DIT
> an object oriented approach? There is a level of OO theology here
> that
> seems beyond my grasp.
[Alan Lloyd] X.500 defines an information model that uses
Object Classes, Attributes, in a distributed Named Tree. A X.509 CA is
in fact an auxilliary Object Class, A certificate is an attribute of an
object class. A CRL Distribution Point is an Object Class. A country
entry in the DIT is an Object Class. All things in X.500 are identified
with Object Identifiers and when instanciated in a DIB they are named.
Operations on X.500 entries are atomic - ie a property of object
processing.....
> I think that we would want to think very hard about basing PKI names
> on
> domain names. It seems desirable to make names in certificates more
> directly related to the "real world" than domain names and e-mail
> addresses
> often seem to be. But, if we are dong a PKI for the Internet (and
> isn't
> this what PKIX is about?), then domain names and the DNS are the
> foundation
> that we build the whole Internet on anyhow.
[Alan Lloyd]
The Internet has many layers in my book. The physical layer and
Lans and things, the Internet layer, the domain layer for machine based
names, and the application layer. DNS deals with Internet addresses and
Domains. Its history that domains relate to organisations. However, as
applications over the Internet evolve, then the higher level naming
constructs relate to real life. Ie. I have a name of Alan, but I may get
services from many internet domains eg Ozemail, Compuserve, MSN, etc. I
dont want 10 names because I use 10 domain based services.
> If the car, or perhaps the toll road operator, in your toll plaza
> example,
> doesn't have a domain name, or an IP address, why is it the concern of
> PKIX, which is, after all, an Internet standard group. Is it even
> appropriate for the PKIX group to worry about things that don't relate
> to
> the Internet?
[Alan Lloyd] Thats a view. I tend to think that the Internet
and Internet style technologies get used where they can. So why not
build things with the widest capability. Thats what the market wants.
> I have been saying for some time that don't know of anybody who has
> built
> an X.500 directory of a size that convinces me that it is a viable
> technology to base a US national PKI, or even a US Federal
> government-wide
> PKI on. I keep asking the question, where are the really big
> distributed
> X.500 directories? Particularly multivendor directories. But I don't
> seem
> to get any answers. What I hear are horror stories about the
> difficulties
> of getting any two X.500 products to work together.
[Alan Lloyd]
No horror stories from us. 20 million entries, 1000s of searches
a second, distributed, multi master, etc We have very scaleable,
distributed technology - that also integrates LDAP servers, etc We are
very busy deploying X.500 into major corporate infrastructures who are
following the themes I described. Including those in the US. Please read
our WEB site. "Uses of Directory Services"
> If the X.500 directory industry builds products that interoperate
> and scale
> well, it has done a really bad job of getting the word out.
[Alan Lloyd]
My view here is that the LDAP hype has done a really good job of
damaging X.500. However, now the LDAP hype has dissipated and reality
has set in we are left with a protocol that can only ACCESS a directory
service ? is twice as big as DAP and has half the functionality. In
addition, getting LDAP only solutions is proving to many that X.500 is
the way to go because of LDAPs NO distribution and a model that demands
Replicate everything to everywhere. LDAP has high operational costs and
gets to a point where it is unworkable.
So LDAP accessed X.500 in my book is the way to go and is being
deployed globally.
> Until now, I have also been saying, does anybody have a believable
> alternative to the mythological, pervasive X.500 directory service?
> It
> seemed almost a rhetorical question. But I think perhaps Phill has
> outlined an alternative, that looks like it probably ought to work,
> and is
> based on something, DNS, that we know works well, scales well, and
> exists
> now. Moreover, we should be able to create the service we need
> incrementally, by just by adding servers as we need them, one at a
> time.
> And, If I understand the proposal, all we have to do is agree on some
> simple naming conventions.
[Alan Lloyd] I am not against alternative proposals - its all a
question of how much effort and implementation goes behind it. Phills
solution has to be backed by all the DNS and PKI suppliers on this
planet and DNS then has to become secure - with signed operations,
mutual authentication, access controls, real life naming, and scale a
lot better and of course be easy to manage and follow Object Oriented
design. (does this mean turning DNS into X.500?) I would vote for that -
thats more X.500!
> That seems very, very appealing.
>
> Once we accept domain names as the basis PKI naming, we are probably
> stuck
> with it forever. Folks who aren't even on the Internet themselves,
> may
> wind up getting domain names for PKI purposes. Perhaps the world
> would, in
> the end, be a better place if we waited for X.500 directory technology
> to
> mature, and then built a pervasive PKI DIT that has nothing to do with
> Internet domain names. But solutions that we can get to work
> reasonably
> well now, with a fairly small effort, usually seem to beat arguably
> better,
> but more distant solutions.
>
[Alan Lloyd] Thats a view but its not mine or the major
organisations that I work with.
I think the best way forward is for who want to build
distributed information systems for business purposes to use X.500 and
for those who want high configuration, low trust, high operational costs
and wait for 5 years go down the DNS route.
Isnt it odd that X.509 is used for PKI and X.500 is discounted?
In addition X.500 solves a complex problem - ie. distributed,
object oriented, name based transaction systems that scale and provide
business information infrastructures. Yet as we have seen with LDAP,
trying to address a complex problem with a simple solution just does not
work. LDAP has taken three years to re invent 10% of a standard that was
released 10 years ago. But LDAP did prove that directorys are difficult
and complex and X.500 got most things right. Is this DNS approach about
to set off on the same track. Ie if distributed PKI is a complex problem
its going to take the same time?
regards alan
> At 10:52 AM 10/29/98 +1100, Alan Lloyd wrote:
> >But why do this - this is yet more configuration and operational cost
> to
> >large systems - and it means relating certificates and CAs to DNS
> when
> >they are in fact (from an OO perspective) just attributes of
> >objects/functions in real life. Ie a Car might have a key and
> >certificate issued by a traffic controller or toll plaza - to deal
> with
> >acqisition, identification and charging of the vehicle through Toll
> >sections on a freeway. Where does DNS fit here? The "DNS SRV
> configure
> >everything" route just seems to denegrate the , real life OO
> principles
> >of directories - which are there so that we can get away from these
> >machine level plumbing issues.
> >
> >I think of CAs as functions and certs that are applied to real life
> >entities which are represented as attributes of objects in a business
> >level directory system.
> >
> >Bashing DNS records into certs and CA operations and validation paths
> >just complicates life with a higher operational costs and does not
> use
> >the utility of distributed information infrastructures. Its like
> >configuring every phone with every one elses phone number. When in
> fact
> >we use the distributed telephone network and its directory system to
> >avoid that.
> >
> >
> >regards alan
> >
> >> -----Original Message-----
> >> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> >> Sent: Thursday, 29 October 1998 6:02
> >> To: Russ Housley; ietf-pkix@imc.org
> >> Subject: RE: Scale (and the SRV record)
> >>
> >> Russ,
> >>
> >> You are right of course! Note that the scheme I propose allows a
> >> certificate repository whose naming scheme is PKIX compatible to
> also
> >> be
> >> advertised. We might have:
> >>
> >> __pkix._http._tcp.arius.com
> >> __pkix._ldap._tcp.arius.com
> >> __pkix._finger._tcp.arius.com
> >>
> >> or even!
> >>
> >> __pkix._verynewprotocol.arius.com
> >>
> >> And since an SRV record is simply an MX record on steroids each
> >> can define server priorities and preferences.
> >>
> >> What would then be required is a draft describing the naming
> >> conventions such a server would conform to and how clients should
> >> interpret the scope of the statement. __pkix._http._tcp.arius.com
> >> is essentially saying "look at the corresponding server where you
> >> will find a PKIX repository whose scope includes (all?)
> certificates
> >> issued which are bound to DNS names within the scope 'arius.com'."
> >>
> >> Alan will have a directory there (we presume) as I would expect
> >> would most enterprises. There might be a move in favour of an HTTP
> >> service acting as a border directory and an LDAP server providing
> >> a more flexible, searchable service inside the enterprise.
> >>
> >> Phill
> >>
> >> > -----Original Message-----
> >> > From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On
> >> Behalf
> >> > Of Russ Housley
> >> > Sent: Wednesday, October 28, 1998 1:29 PM
> >> > To: Alan Lloyd
> >> > Cc: ietf-pkix@imc.org
> >> > Subject: Scale (and the SRV record)
> >> >
> >> >
> >> > Alan asks:
> >> >
> >> > > I need to be enlightened - How does one deploy a large scale
> >> distributed
> >> > > PKI without a large scale object oriented distributed (and
> >> protected by
> >> > > ACI, etc) directory system?
> >> >
> >> > Directory is the preferred certificate repository, but it is not
> the
> >> only
> >> > repository that will scale. People have used FTP, Finger, HTTP,
> and
> >> other
> >> > mechanisms to distribute certificates.
> >> >
> >> > The PKI is not dependent on the deployment of a Directory, as
> these
> >> other
> >> > mechanism can be used until the Directory become widely
> available.
> >> >
> >> > Further, a trusted repository is not a requirement. Since
> >> > certificates and
> >> > CRLs are signed, the repository cannot make undetected
> modification
> >> to the
> >> > data structures. Denial of service is allways an issue; it is a
> >> > concern in
> >> > all of the possible repository alternatives.
> >> >
> >> > Russ
> >> >
> >> >
> >
> >
> Regards,
>
> Bill Burr
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25081 for ietf-pkix-bks; Thu, 29 Oct 1998 11:52:40 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25077 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 11:52:39 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id LAA15572; Thu, 29 Oct 1998 11:52:06 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA15172; Thu, 29 Oct 1998 11:54:20 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: <salzr@certco.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 14:55:11 -0500
Message-ID: <001601be0376$0972df20$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <29E0A6D39ABED111A36000A0C99609CA18D2FA@macertco-srv1.ma.certco.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> >If someone spoofed DNS the worst that would happen is that I would
> >recieve a certificate I didn't trust (and would ignore) or no
> >certificate
> at all.
>
> Well, if you're only fetching certificates, probably.
>
> But if you're fetching CRL's, then no. Suppose a cert is compromised,
> and CRLn is issued before the "next update" time purely because of
> that compromise. The adversary could spoof DNS and just send out
> the valid, but outdated CRL(n-1) and potentially have quite a
> window of opportunity.
Hence the motivation for an Online Status service like OCSP.
Alternatively use the OCDP mechanism to provide a 'meta CRL'. A master
CRL can be issued every minute which would contain a list (CRLList) of
the most current CRLs in each partition.
This issue is orthogonal to the issue of directory discovery however.
Any infrastructure for distributing CRLs has the same problem. I don't
see that the solution is to attempt to guarantee delivery of the CRLs
by hypothesizing secure infrastructures will be installed. I believe
we should address the issue by removing the dependence.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24756 for ietf-pkix-bks; Thu, 29 Oct 1998 10:57:01 -0800 (PST)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24752 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 10:56:59 -0800 (PST)
From: salzr@certco.com
Received: (from uucp@localhost) by fwma1.certco.com (8.8.8/8.8.8) id NAA17758; Thu, 29 Oct 1998 13:59:15 -0500 (EST)
Received: from smtp.ma.certco.com(10.200.200.11) by fwma1.certco.com via smap (V2.1) id xma017756; Thu, 29 Oct 98 13:59:10 -0500
Received: from stig (stig.ma.certco.com [10.200.200.45]) by smtp.ma.certco.com (8.8.5/8.8.5) with SMTP id NAA12302; Thu, 29 Oct 1998 13:59:05 -0500 (EST)
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 13:59:04 -0500
Message-ID: <29E0A6D39ABED111A36000A0C99609CA18D2FA@macertco-srv1.ma.certco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <000a01be0352$2b946660$c807a8c0@pbaker-pc.verisign.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>If someone spoofed DNS the worst that would happen is that I would
>recieve a certificate I didn't trust (and would ignore) or no >certificate
at all.
Well, if you're only fetching certificates, probably.
But if you're fetching CRL's, then no. Suppose a cert is compromised,
and CRLn is issued before the "next update" time purely because of
that compromise. The adversary could spoof DNS and just send out
the valid, but outdated CRL(n-1) and potentially have quite a
window of opportunity.
/r$
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA23068 for ietf-pkix-bks; Thu, 29 Oct 1998 07:36:01 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA23064 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 07:36:00 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA08551; Thu, 29 Oct 1998 07:35:23 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA25873; Thu, 29 Oct 1998 07:37:35 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ron Ramsay" <Ron.Ramsay@OpenDirectory.com.au>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>, "Rick Harvey" <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:38:26 -0500
Message-ID: <000a01be0352$2b946660$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <D1A949D4508DD1119C8100400533BEDC0656BE@DSG1>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Phillip,
>
> Thanks for taking time to develop the example.
>
> Two issues:
>
> 1. Surely DNS is not secure?
Define secure? With the exception of a denial of service attack DNS
is 'secure enough' for this purpose since there is no trust placed
on the server. The origin of a signed message is irrelevant. Only
the signature is relevant.
> 2. Your example seems to be based on encryption using public keys. From
> what I know of the public key system, it is not used for encryption.
I think you are confusing DNS security here with PKIX. The two are very
separate.
If someone spoofed DNS the worst that would happen is that I would
recieve a certificate I didn't trust (and would ignore) or no certificate
at all.
>Its
> purpose is authentication and integrity. To bend your example, you will
> be encrypting your message with your own private key. How is an
> addressee to verify it was you who sent the message and that the message
> was not modified?
I send my signing certificate with the message. Or once the infrastructure
is deployed the recipient could use the SRV pointer to locate a directory
where a copy of the certificate was available.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22988 for ietf-pkix-bks; Thu, 29 Oct 1998 07:31:05 -0800 (PST)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA22984 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 07:31:04 -0800 (PST)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id KAA28665; Thu, 29 Oct 1998 10:32:31 -0500
Message-Id: <3.0.5.32.19981029103331.039352b0@csmes.ncsl.nist.gov>
X-Sender: burr@csmes.ncsl.nist.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 29 Oct 1998 10:33:31 -0500
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
From: Bill Burr <william.burr@nist.gov>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4BC@DSG1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
I'm more than a little confused about what it is that makes X.500
directories particularly OO things. Is mashing the world into an X.500 DIT
an object oriented approach? There is a level of OO theology here that
seems beyond my grasp.
I think that we would want to think very hard about basing PKI names on
domain names. It seems desirable to make names in certificates more
directly related to the "real world" than domain names and e-mail addresses
often seem to be. But, if we are dong a PKI for the Internet (and isn't
this what PKIX is about?), then domain names and the DNS are the foundation
that we build the whole Internet on anyhow.
If the car, or perhaps the toll road operator, in your toll plaza example,
doesn't have a domain name, or an IP address, why is it the concern of
PKIX, which is, after all, an Internet standard group. Is it even
appropriate for the PKIX group to worry about things that don't relate to
the Internet?
I have been saying for some time that don't know of anybody who has built
an X.500 directory of a size that convinces me that it is a viable
technology to base a US national PKI, or even a US Federal government-wide
PKI on. I keep asking the question, where are the really big distributed
X.500 directories? Particularly multivendor directories. But I don't seem
to get any answers. What I hear are horror stories about the difficulties
of getting any two X.500 products to work together.
If the X.500 directory industry builds products that interoperate and scale
well, it has done a really bad job of getting the word out.
Until now, I have also been saying, does anybody have a believable
alternative to the mythological, pervasive X.500 directory service? It
seemed almost a rhetorical question. But I think perhaps Phill has
outlined an alternative, that looks like it probably ought to work, and is
based on something, DNS, that we know works well, scales well, and exists
now. Moreover, we should be able to create the service we need
incrementally, by just by adding servers as we need them, one at a time.
And, If I understand the proposal, all we have to do is agree on some
simple naming conventions.
That seems very, very appealing.
Once we accept domain names as the basis PKI naming, we are probably stuck
with it forever. Folks who aren't even on the Internet themselves, may
wind up getting domain names for PKI purposes. Perhaps the world would, in
the end, be a better place if we waited for X.500 directory technology to
mature, and then built a pervasive PKI DIT that has nothing to do with
Internet domain names. But solutions that we can get to work reasonably
well now, with a fairly small effort, usually seem to beat arguably better,
but more distant solutions.
At 10:52 AM 10/29/98 +1100, Alan Lloyd wrote:
>But why do this - this is yet more configuration and operational cost to
>large systems - and it means relating certificates and CAs to DNS when
>they are in fact (from an OO perspective) just attributes of
>objects/functions in real life. Ie a Car might have a key and
>certificate issued by a traffic controller or toll plaza - to deal with
>acqisition, identification and charging of the vehicle through Toll
>sections on a freeway. Where does DNS fit here? The "DNS SRV configure
>everything" route just seems to denegrate the , real life OO principles
>of directories - which are there so that we can get away from these
>machine level plumbing issues.
>
>I think of CAs as functions and certs that are applied to real life
>entities which are represented as attributes of objects in a business
>level directory system.
>
>Bashing DNS records into certs and CA operations and validation paths
>just complicates life with a higher operational costs and does not use
>the utility of distributed information infrastructures. Its like
>configuring every phone with every one elses phone number. When in fact
>we use the distributed telephone network and its directory system to
>avoid that.
>
>
>regards alan
>
>> -----Original Message-----
>> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
>> Sent: Thursday, 29 October 1998 6:02
>> To: Russ Housley; ietf-pkix@imc.org
>> Subject: RE: Scale (and the SRV record)
>>
>> Russ,
>>
>> You are right of course! Note that the scheme I propose allows a
>> certificate repository whose naming scheme is PKIX compatible to also
>> be
>> advertised. We might have:
>>
>> __pkix._http._tcp.arius.com
>> __pkix._ldap._tcp.arius.com
>> __pkix._finger._tcp.arius.com
>>
>> or even!
>>
>> __pkix._verynewprotocol.arius.com
>>
>> And since an SRV record is simply an MX record on steroids each
>> can define server priorities and preferences.
>>
>> What would then be required is a draft describing the naming
>> conventions such a server would conform to and how clients should
>> interpret the scope of the statement. __pkix._http._tcp.arius.com
>> is essentially saying "look at the corresponding server where you
>> will find a PKIX repository whose scope includes (all?) certificates
>> issued which are bound to DNS names within the scope 'arius.com'."
>>
>> Alan will have a directory there (we presume) as I would expect
>> would most enterprises. There might be a move in favour of an HTTP
>> service acting as a border directory and an LDAP server providing
>> a more flexible, searchable service inside the enterprise.
>>
>> Phill
>>
>> > -----Original Message-----
>> > From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On
>> Behalf
>> > Of Russ Housley
>> > Sent: Wednesday, October 28, 1998 1:29 PM
>> > To: Alan Lloyd
>> > Cc: ietf-pkix@imc.org
>> > Subject: Scale (and the SRV record)
>> >
>> >
>> > Alan asks:
>> >
>> > > I need to be enlightened - How does one deploy a large scale
>> distributed
>> > > PKI without a large scale object oriented distributed (and
>> protected by
>> > > ACI, etc) directory system?
>> >
>> > Directory is the preferred certificate repository, but it is not the
>> only
>> > repository that will scale. People have used FTP, Finger, HTTP, and
>> other
>> > mechanisms to distribute certificates.
>> >
>> > The PKI is not dependent on the deployment of a Directory, as these
>> other
>> > mechanism can be used until the Directory become widely available.
>> >
>> > Further, a trusted repository is not a requirement. Since
>> > certificates and
>> > CRLs are signed, the repository cannot make undetected modification
>> to the
>> > data structures. Denial of service is allways an issue; it is a
>> > concern in
>> > all of the possible repository alternatives.
>> >
>> > Russ
>> >
>> >
>
>
Regards,
Bill Burr
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA22878 for ietf-pkix-bks; Thu, 29 Oct 1998 07:21:36 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA22874 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 07:21:35 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA08302; Thu, 29 Oct 1998 07:21:05 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA25200; Thu, 29 Oct 1998 07:23:16 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Bill Burr" <william.burr@nist.gov>, "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:24:07 -0500
Message-ID: <000801be0350$2b396000$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-reply-to: <3.0.5.32.19981028172103.03924b80@csmes.ncsl.nist.gov>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Phill,
>
> I'm in a bit over my head here now (arguably I have been all along),
> because I don't understand SRVs very well, and I had the impression that
> they're more a proposal than a reality. Would we be betting on the come
> here? Or is support SRVs really in DNS servers and resolvers now?
The proposal is actually quite old - the RFC has been out for two years
as 'experimental'. But the code is widely deployed in the bind code, not
surprising sinc Paul Vixie was the author of the SRV draft and the re-author
of bind.
The Vixie-bind code is greatly preferred over its predecessors in any
case since it has considerable proofing against DNS spoofing attacks added.
Irresprective of whether a site was to use SRV they should upgrade to
the latest release of bind.
The Microsoft situation is slightly different. I could not persuade my
NT DNS server to accept an SRV record, but as Microsoft stated at the TWG
they are awfully keen on it. Basically the SRV record is the glue between
the DNS system and active directory it appears.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22590 for ietf-pkix-bks; Thu, 29 Oct 1998 06:41:10 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id GAA22586 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 06:41:09 -0800 (PST)
Received: id JAA19380; Thu, 29 Oct 1998 09:34:00 -0500
Received: by gateway id <V6M8VRQC>; Thu, 29 Oct 1998 09:31:25 -0500
Message-ID: <D789F71F24B4D111955D00A0C99B4F5001789133@sothmxs01.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: ietf-pkix@imc.org, "'Robert Klerer'" <klerer@xhair.com>
Subject: RE: email oid
Date: Thu, 29 Oct 1998 09:29:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi,
> ----------
> From: Robert Klerer[SMTP:klerer@xhair.com]
> Sent: Thursday, October 29, 1998 8:18 AM
> To: ietf-pkix@imc.org
> Subject: email oid
>
> The other day in trying to accommodate a legacy pki, I ran into a
> problem
> with an oid specified in draft-ietf-pkix-ipki-part1-11...
>
"Legacy PKI". There's a term I haven't heard before.
PKIX has certainly come a long way in a short time... :-)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22379 for ietf-pkix-bks; Thu, 29 Oct 1998 06:15:06 -0800 (PST)
Received: from Sonnet.GSC.GTE.Com (Sonnet.GSC.GTE.Com [131.131.251.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22375 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 06:15:04 -0800 (PST)
Received: from gscex01.gsc.gte.com ("port 1313"@gscex01.ndhm.gtegsc.com [155.95.162.170]) by Sonnet.GSC.GTE.Com (PMDF V5.2-27 #29038) with ESMTP id <01J3JDBCIBMQ000DBO@Sonnet.GSC.GTE.Com> for ietf-pkix@imc.org; Thu, 29 Oct 1998 09:16:57 -0400 (EDT)
Received: by gscex01.ndhm.gtegsc.com with Internet Mail Service (5.0.1460.8) id <VNQY4F6A>; Thu, 29 Oct 1998 09:14:09 -0500
Content-return: allowed
Date: Thu, 29 Oct 1998 09:17:15 -0500
From: "Wang, John" <John.Wang@CyberTrust.GTE.Com>
Subject: RE: email oid
To: "'Robert Klerer'" <klerer@xhair.com>, ietf-pkix@imc.org
Message-id: <F97906F6A12CD211AF5D00805F0DB87814D790@ndhm08.ndhm.gtegsc.com>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
It was my understanding that the RSA-pkcs-9 email address OID
(1.2.840.113549.1.9.1) was the more commonly used OID. I don't
think you can remove the RSA oid but perhaps add the RFC1274 oid
if there is a demand for it.
-----Original Message-----
From: Robert Klerer [mailto:klerer@xhair.com]
Sent: Thursday, October 29, 1998 8:19 AM
To: ietf-pkix@imc.org
Subject: email oid
The other day in trying to accommodate a legacy pki, I ran into a problem
with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
that the oid used for an email address in the distinguished name is
1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
as specified in RFC1274.
Since I believe that the intention is for both of these oids are meant to
represent attributes that hold the same information, this discrepancy may
cause confusion and failures in the future. My suggestion would be to
change part1 to refer to the more commonly used OID.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA22075 for ietf-pkix-bks; Thu, 29 Oct 1998 05:16:21 -0800 (PST)
Received: from mailsvr.basit.com (mailsvr-gw.basit.com [128.209.1.213] (may be forged)) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA22071 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 05:16:19 -0800 (PST)
Received: from klerer.basit.com (shiva112 [128.209.144.112]) by mailsvr.basit.com (Guess_again/1.8) with SMTP id IAA18504 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 08:18:04 -0500 (EST)
Message-ID: <001201be033e$a3e06380$010ed180@klerer.basit.com>
From: "Robert Klerer" <klerer@xhair.com>
To: <ietf-pkix@imc.org>
Subject: email oid
Date: Thu, 29 Oct 1998 08:18:37 -0500
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 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
The other day in trying to accommodate a legacy pki, I ran into a problem
with an oid specified in draft-ietf-pkix-ipki-part1-11. The ASN.1 specifies
that the oid used for an email address in the distinguished name is
1.2.840.113549.1.9.1, which refers to a RSA-pkcs-9 email address. I and
others have been using 0.9.2342.19200300.100.1.3 which is for internet mail
as specified in RFC1274.
Since I believe that the intention is for both of these oids are meant to
represent attributes that hold the same information, this discrepancy may
cause confusion and failures in the future. My suggestion would be to
change part1 to refer to the more commonly used OID.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA19448 for ietf-pkix-bks; Thu, 29 Oct 1998 02:33:04 -0800 (PST)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA19444 for <ietf-pkix@imc.org>; Thu, 29 Oct 1998 02:33:02 -0800 (PST)
Received: from stefans (t1o68p32.telia.com [62.20.138.32]) by maila.telia.com (8.8.8/8.8.8) with SMTP id LAA18941; Thu, 29 Oct 1998 11:35:09 +0100 (CET)
Message-Id: <3.0.32.19981029113047.00a11bd0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 29 Oct 1998 11:31:27 +0100
To: Anders Rundgren <anders.rundgren@jaybis.com>, "'SEIS-List'" <list@seis.nc-forum.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: Unmistakable Identity (Was: Internet draft for Qualified Certificates.)
Cc: ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA19445
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Anders,
I see your problems but fail to see in what way they are unique to digital
agreements.
Many long term contracts are drawn up using "non static" ID-attributes.
They work so I'm convinced that they would work if they are signed through
digital mechanisms.
Clearly the requirements on a supporting infrastructure will differ
dependent on which ID-attributes that are used. But that's outside the
scope of this draft.
Secondly all ID-attributes have different characteristics. I wouldn't know
how to categorize them in a way that is internationally meaningful. You are
free though to propose any writing in this sense.
/Stefan
At 10:15 AM 10/29/98 +0100, Anders Rundgren wrote:
>Stefan,
>New try with this Unmistakable business:
>
>Assumptions
> Users have SEIS EID certificates (qualified I assume) based on the
proposed CP
> The certificate-relaying party is a computer program
> The certificate-relaying part and the certificate-subject have a
long-term relation
>
>Now I try to apply the algorithm from the I-D that says that an
*unmistakable* name
>should be created by combining Name, civicRegNr etc..
>
>Statement 1: By combining the name of physical persons in Sweden with other
>attributes to form an unmistakable identity, the chance that some future
certificate
>for a certain person will fail during authentication due to name changes
is around *20%*!
>Unless of course the certificate-relying party is free to ask the CA
>questions like: Was XYX formerly known as DFT?
>
>Statement 2: By only using civicRegNr (which departs from the I-D
definition) this risk
>goes down to a mere *0.001%*.
>
>Do I smell interoperability problems and confusion? Lots of it. I was
actually recommended
>by one major EID-vendor (who's identity will remain in secret) to use the
entire certificate (!!!)
>as a key in authentication so even the s.c professionals have problems
with this part.
>
>
>Now to this *static* thing. That there is currently no room in the I-D
for the definition
>of such a characteristic is a serious omission. This is as you pointed
out a market and
>legislative issue so it is very important for certificate-subjects and
certificate-relying
>parties to know what they can expect. And for issuers to point out in
their marketing.
>Note that this has nothing to do with recommendations
>
>Anders
>
>----------
>From: Stefan Santesson [SMTP:stefan@accurata.se]
>Sent: Wednesday, October 28, 1998 17:07
>To: 'SEIS-List'
>Subject: RE: Internet draft for Qualified Certificates.
>
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Anders,
>
>An unmistakable name doesn't have to be static. It is unmitakable as long
>as the relying party can use the name to identiy the subject for as long as
>the certificate is valid and not revoked.
>
>It is at this moment outside the scope of this I-D to make any requirements
>on how static a name should be. This is up to the CA to decide and up to
>the relying party to accept.
>
>/Stefan
>
>
>At 04:17 PM 10/28/98 +0100, Anders Rundgren wrote:
>>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>>
>>Stefan, I still have some serious problems with the definitions and
>interpretations.
>>
>>>>How does a certificate-relying party know what fields form
>>>>an unmistakable name of the subject?
>>>>
>>>>Unmistakable is different from static identity I guess?
>>>>
>>>>Anders
>>
>>>An unmistakable name of the subject SHALL be obtained by combining the
>value of the subjects
>>>registered name attributes or pseudonym attributes, with the values of
>the following attribute
>>>types;
>>>countryName
>>>civicRegistrationNumber
>>>serialNumber
>>>organizationName
>>>organizationalUnitName
>>>postalAddress
>>
>>To me a Swedish EID forms an unmistakable subject identity (99.999%) by just
>>using civicRegistrationNumber.
>>
>>By using the other (non-static) attributes you loose unmistakable. You
>just have to change
>>employer to break it!
>>
>>I would also like to see the *static* identity possibility covered by the
>draft. I.e. it should
>>be clear for a certificate-relaying party if is unmistakable in the way
>you use that
>>word in other contexts.
>>
>>Anders
>>
>>
>>
>>----------------- SEIS mailing list (list@seis.nc-forum.com)
>>Info about this list: http://www.nc-forum.com/seis
>>SEIS Contact: info@seis.se
>>
>>
>>
>-------------------------------------------------------------------
>Stefan Santesson <stefan@accurata.se>
>Accurata Systemsäkerhet AB
>Lotsgatan 27 D Tel. +46-40 152211
>216 42 Malmö Fax. +46-40 150790
>Sweden Mobile +46-70 5247799
>
>PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
>-------------------------------------------------------------------
>
>
>----------------- SEIS mailing list (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA29403 for ietf-pkix-bks; Wed, 28 Oct 1998 20:55:19 -0800 (PST)
Received: from mail.innetix.com (oldmail.innetix.com [207.126.108.12]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA29398 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 20:55:17 -0800 (PST)
Received: from iris (user46.sj.dialup.innetix.com [209.172.68.109]) by mail.innetix.com (8.8.7/8.8.5) with SMTP id UAA11246; Wed, 28 Oct 1998 20:49:32 -0800 (PST)
Message-Id: <3.0.2.32.19981028205654.006dfab8@innetix.com>
X-Sender: bruceg@innetix.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32)
Date: Wed, 28 Oct 1998 20:56:54 -0800
To: Bill Burr <william.burr@nist.gov>, "Phillip M Hallam-Baker" <pbaker@verisign.com>, "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
From: Bruce Greenblatt <bruceg@innetix.com>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <3.0.5.32.19981028172103.03924b80@csmes.ncsl.nist.gov>
References: <001501be02a5$77fd4920$c807a8c0@pbaker-pc.verisign.com> <4.1.19981028132138.009c32b0@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I know the answer to this one... SRV records are a reality, and are
supported in the current version of Bind (the most common implementation).
It is also my understanding that several other implementations have support
for SRV records. Another interesting DNS resource record that could be
useful in this area is the NAPTR record. Note that SRV records are defined
in RFC 2052, and NAPTR records are defined in RFC 2168.
Bruce
At 05:21 PM 10/28/98 -0500, Bill Burr wrote:
>Phill,
>
>I'm in a bit over my head here now (arguably I have been all along),
>because I don't understand SRVs very well, and I had the impression that
>they're more a proposal than a reality. Would we be betting on the come
>here? Or is support SRVs really in DNS servers and resolvers now?
>
>
>Regards,
>
>Bill Burr
>
>
================================================
Bruce Greenblatt bruceg@innetix.com
http://www.innetix.com/~bruceg
================================================
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27961 for ietf-pkix-bks; Wed, 28 Oct 1998 16:13:19 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27955 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 16:13:11 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PJM>; Thu, 29 Oct 1998 11:10:59 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC0656BE@DSG1>
From: Ron Ramsay <Ron.Ramsay@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org, Rick Harvey <Rick.Harvey@OpenDirectory.com.au>
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 11:10:57 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phillip,
Thanks for taking time to develop the example.
Two issues:
1. Surely DNS is not secure?
2. Your example seems to be based on encryption using public keys. From
what I know of the public key system, it is not used for encryption. Its
purpose is authentication and integrity. To bend your example, you will
be encrypting your message with your own private key. How is an
addressee to verify it was you who sent the message and that the message
was not modified?
Ron.
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Thursday, October 29, 1998 3:37 AM
> To: Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan issued the following challenge,
>
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
>
> Seems like a good question, it occured to me that now is a good time
> to
> raise it.
>
> Look at the one already deployed and work it out. The SSL secured part
> of
> the Web does not stop working if directory.verisign.com goes down.
>
> I have had this arguement before with the hypertext establishment.
> They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were
> completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L
> to
> give the keynote!
>
> The greater the scale the less weight a base information system can
> carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of
> consistency
> across transactions. Finally at global scale it is not practical to
> deal in
> data, we must deal in names instead, names in this case being of
> Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live)
> to
> make the DNS sytem tractable, precisely because they have Sebok's
> 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
>
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
>
> Making PKI scale to global reach is no more than a matter of naming.
> Bind
> the network level directory infrastructures to the internet naming
> system
> which is and will continue to be DNS.
>
> There is already a DNS resource record defined for the purpose - SRV.
> If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
>
> Email client is to send to fred@arius.com, there is no cert in the
> address
> book:
>
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> _ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> _ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> _ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest
> priority
> number which offers a directory protocol that is understood,
> in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> fred@arius.com
> 5) The client retrieves the certificates for the entry, there are
> three
> of which one is a currently valid one for fred@arius.com
> 6) The client encrypts the email
> 7) The client sends the email
>
>
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
>
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
>
>
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
>
>
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
>
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
>
> __pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> __pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> __pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
>
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
>
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
>
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have
> deployed.
>
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
>
>
> Phill
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27953 for ietf-pkix-bks; Wed, 28 Oct 1998 16:13:03 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27948 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 16:12:59 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PJL>; Thu, 29 Oct 1998 11:10:41 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4BE@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Paul Koning'" <pkoning@xedia.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 11:10:39 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I think the response I gave was about denial/system integrity re getting
CRLs or not with master/replicas.
As LDAP is now much bigger than DAP (with half the functionality) I
would rather call LDAP HDAP and DAP EDAP (efficient DAP) :-)
I agree that no matter what protocol you use, denial of service is an
issue as protocols cannot prevent hogging by other or someone switching
the machine off.
The real issue is that some protocols (not simple or lightweight ones)
provide system selection features (chaining/replication selection
control) and the use of these assist with system operation and
information integrity ie. improve reliability and trust.
regards alan
> -----Original Message-----
> From: Paul Koning [SMTP:pkoning@xedia.com]
> Sent: Thursday, 29 October 1998 11:02
> To: Alan.Lloyd@OpenDirectory.com.au
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> >>>>> "Alan" == Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> writes:
>
> >> -----Original Message----- From: salzr@certco.com
> >> [SMTP:salzr@certco.com] Sent: Thursday, 29 October 1998 5:56 To:
> >> 'Russ Housley'; Alan Lloyd Cc: ietf-pkix@imc.org Subject: RE:
> >> Scale (and the SRV record)
> >>
> >> >Denial of service is allways an issue; it is a concern in >all of
> >> the possible repository alternatives.
> >>
> >> At the risk of stating the obvious, a denial of service that
> >> prevents you from getting revocation information (such as a CRL)
> >> can be Very Bad, given the implementation quality of most network
> >> services that I've seen...
> Alan> [Alan Lloyd] Yes, and we enforce that risk by saying LDAP is
> Alan> the way to go. :-)
>
> How so? I've never heard of a protocol that's immune to denial of
> service attack. Why would replacing LDAP by HDAP help?
>
> paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27850 for ietf-pkix-bks; Wed, 28 Oct 1998 16:00:06 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27845 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 16:00:05 -0800 (PST)
Received: from xedia.com by relay1.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfncq13061; Wed, 28 Oct 1998 19:01:33 -0500 (EST)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01892; Wed, 28 Oct 98 18:59:51 EST
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id TAA04116; Wed, 28 Oct 1998 19:01:31 -0500
Date: Wed, 28 Oct 1998 19:01:31 -0500
Message-Id: <199810290001.TAA04116@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Alan.Lloyd@OpenDirectory.com.au
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC05D4B6@DSG1>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>>>>> "Alan" == Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au> writes:
>> -----Original Message----- From: salzr@certco.com
>> [SMTP:salzr@certco.com] Sent: Thursday, 29 October 1998 5:56 To:
>> 'Russ Housley'; Alan Lloyd Cc: ietf-pkix@imc.org Subject: RE:
>> Scale (and the SRV record)
>>
>> >Denial of service is allways an issue; it is a concern in >all of
>> the possible repository alternatives.
>>
>> At the risk of stating the obvious, a denial of service that
>> prevents you from getting revocation information (such as a CRL)
>> can be Very Bad, given the implementation quality of most network
>> services that I've seen...
Alan> [Alan Lloyd] Yes, and we enforce that risk by saying LDAP is
Alan> the way to go. :-)
How so? I've never heard of a protocol that's immune to denial of
service attack. Why would replacing LDAP by HDAP help?
paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27812 for ietf-pkix-bks; Wed, 28 Oct 1998 15:54:44 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27808 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:54:36 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3PJD>; Thu, 29 Oct 1998 10:52:23 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4BC@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Russ Housley <housley@spyrus.com>, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:52:22 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
But why do this - this is yet more configuration and operational cost to
large systems - and it means relating certificates and CAs to DNS when
they are in fact (from an OO perspective) just attributes of
objects/functions in real life. Ie a Car might have a key and
certificate issued by a traffic controller or toll plaza - to deal with
acqisition, identification and charging of the vehicle through Toll
sections on a freeway. Where does DNS fit here? The "DNS SRV configure
everything" route just seems to denegrate the , real life OO principles
of directories - which are there so that we can get away from these
machine level plumbing issues.
I think of CAs as functions and certs that are applied to real life
entities which are represented as attributes of objects in a business
level directory system.
Bashing DNS records into certs and CA operations and validation paths
just complicates life with a higher operational costs and does not use
the utility of distributed information infrastructures. Its like
configuring every phone with every one elses phone number. When in fact
we use the distributed telephone network and its directory system to
avoid that.
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Thursday, 29 October 1998 6:02
> To: Russ Housley; ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> Russ,
>
> You are right of course! Note that the scheme I propose allows a
> certificate repository whose naming scheme is PKIX compatible to also
> be
> advertised. We might have:
>
> __pkix._http._tcp.arius.com
> __pkix._ldap._tcp.arius.com
> __pkix._finger._tcp.arius.com
>
> or even!
>
> __pkix._verynewprotocol.arius.com
>
> And since an SRV record is simply an MX record on steroids each
> can define server priorities and preferences.
>
> What would then be required is a draft describing the naming
> conventions such a server would conform to and how clients should
> interpret the scope of the statement. __pkix._http._tcp.arius.com
> is essentially saying "look at the corresponding server where you
> will find a PKIX repository whose scope includes (all?) certificates
> issued which are bound to DNS names within the scope 'arius.com'."
>
> Alan will have a directory there (we presume) as I would expect
> would most enterprises. There might be a move in favour of an HTTP
> service acting as a border directory and an LDAP server providing
> a more flexible, searchable service inside the enterprise.
>
> Phill
>
> > -----Original Message-----
> > From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On
> Behalf
> > Of Russ Housley
> > Sent: Wednesday, October 28, 1998 1:29 PM
> > To: Alan Lloyd
> > Cc: ietf-pkix@imc.org
> > Subject: Scale (and the SRV record)
> >
> >
> > Alan asks:
> >
> > > I need to be enlightened - How does one deploy a large scale
> distributed
> > > PKI without a large scale object oriented distributed (and
> protected by
> > > ACI, etc) directory system?
> >
> > Directory is the preferred certificate repository, but it is not the
> only
> > repository that will scale. People have used FTP, Finger, HTTP, and
> other
> > mechanisms to distribute certificates.
> >
> > The PKI is not dependent on the deployment of a Directory, as these
> other
> > mechanism can be used until the Directory become widely available.
> >
> > Further, a trusted repository is not a requirement. Since
> > certificates and
> > CRLs are signed, the repository cannot make undetected modification
> to the
> > data structures. Denial of service is allways an issue; it is a
> > concern in
> > all of the possible repository alternatives.
> >
> > Russ
> >
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27669 for ietf-pkix-bks; Wed, 28 Oct 1998 15:22:52 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27665 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:22:49 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P20>; Thu, 29 Oct 1998 10:20:36 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4BA@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Sean Turner'" <turners@ieca.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 10:20:36 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sean, I agree. But there are windows - ie, if a master gets a CRL when
one does not already exist and it has not propagated to the replicas -
then there is a window in which a cert could be deemed valid when it
isnt. ie. We can chose to accept replication delays or we can get higher
trust by requesting cert path objects from the master DSA (using DAP).
Its just a timing hole that system designers with LDAP should watch out
for.
regards alan
> -----Original Message-----
> From: Sean Turner [SMTP:turners@ieca.com]
> Sent: Thursday, 29 October 1998 10:10
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: Re: Scale (and the SRV record)
>
> Alan Lloyd wrote:
> >
> > > -----Original Message-----
> > > From: salzr@certco.com [SMTP:salzr@certco.com]
> > > Sent: Thursday, 29 October 1998 5:56
> > > To: 'Russ Housley'; Alan Lloyd
> > > Cc: ietf-pkix@imc.org
> > > Subject: RE: Scale (and the SRV record)
> > >
> > > >Denial of service is allways an issue; it is a concern in
> > > >all of the possible repository alternatives.
> > >
> > > At the risk of stating the obvious, a denial of service that
> > > prevents you from getting revocation information (such as a
> > > CRL) can be Very Bad, given the implementation quality of most
> > > network services that I've seen...
> > [Alan Lloyd]
> > Yes, and we enforce that risk by saying LDAP is the way to
> go.
> > :-)
> > "Dont Use Copy" - see X.511 (DAP) and knowing master DSAs
> is
> > good.
> >
> > regards
>
> Alan,
>
> You can use a shadowed copy of a CRL or a master copy it doesn't
> matter it's a signed object.
>
> spt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27618 for ietf-pkix-bks; Wed, 28 Oct 1998 15:18:18 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27614 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:18:09 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P27>; Thu, 29 Oct 1998 10:15:56 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B9@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>
Cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 29 Oct 1998 10:15:55 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Agree Lynn. We (OpenDirectory) are obviously directory centric and its
that view that sees the issues you describe. Most organisations have
high cost information islands for all sorts of reasons - and as they try
to reduce operating costs and optimise information management then the
directory approach works well. In fact its designed exactly for that.
One cannot add to information islands supporting service delivery a PKI
unless one wants more costs and more risk. So its "consolidate (into OO)
and then authenticate" is the way to go.
We see directories as the new wave in distributed OO engineering for all
forms of business information infrastructures. I think there has been a
view that directories are about email address books, white pages and
DNS. And this of course is just a limited subset of the directory
capability.
regards alan
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Thursday, 29 October 1998 3:28
> To: Alan Lloyd
> Cc: 'Phillip M Hallam-Baker'; Al Arsenault; Stephen Kent;
> ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> small note ... from business standpoint ... it might be better
> explained
> that no directories no authentication infrastructure (which is the
> business
> process/requirement) ... a PKI is then a method of implementing that
> infrastructure. Part of the problem with starting with PKI as a
> solution
> and then asking what the problem is .... one might might be led into
> presuming that some of the existing PKIs deployed for independent
> pilots
> are the structure one would automatically use as an integrated
> business
> solution.
>
> directories actually have other business needs independent of the
> authentication infrastructure. in past life, looked at one customer
> that
> had on the order of 6000 RDBMS where 90% of the data was common.
> schema
> integration directory was needed just so that simple things like
> changing
> the name on an account is consistently done thruout the business (side
> problem was wide variety of different terms that were used in schemas
> for
> common things like name).
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA27548 for ietf-pkix-bks; Wed, 28 Oct 1998 15:12:22 -0800 (PST)
Received: from hq.vni.net (hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA27544 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 15:12:20 -0800 (PST)
Received: from ieca.com (nova-aaa-016.vni.net [205.177.115.16]) by hq.vni.net (8.8.8/8.8.5) with ESMTP id SAA00993; Wed, 28 Oct 1998 18:13:44 -0500 (EST)
Message-ID: <3637A43D.933C47D4@ieca.com>
Date: Wed, 28 Oct 1998 18:09:50 -0500
From: Sean Turner <turners@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.5 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
CC: ietf-pkix@imc.org
Subject: Re: Scale (and the SRV record)
References: <D1A949D4508DD1119C8100400533BEDC05D4B6@DSG1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan Lloyd wrote:
>
> > -----Original Message-----
> > From: salzr@certco.com [SMTP:salzr@certco.com]
> > Sent: Thursday, 29 October 1998 5:56
> > To: 'Russ Housley'; Alan Lloyd
> > Cc: ietf-pkix@imc.org
> > Subject: RE: Scale (and the SRV record)
> >
> > >Denial of service is allways an issue; it is a concern in
> > >all of the possible repository alternatives.
> >
> > At the risk of stating the obvious, a denial of service that
> > prevents you from getting revocation information (such as a
> > CRL) can be Very Bad, given the implementation quality of most
> > network services that I've seen...
> [Alan Lloyd]
> Yes, and we enforce that risk by saying LDAP is the way to go.
> :-)
> "Dont Use Copy" - see X.511 (DAP) and knowing master DSAs is
> good.
>
> regards
Alan,
You can use a shadowed copy of a CRL or a master copy it doesn't
matter it's a signed object.
spt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27194 for ietf-pkix-bks; Wed, 28 Oct 1998 14:38:13 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27188 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:38:02 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2V>; Thu, 29 Oct 1998 09:35:45 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B8@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 09:35:45 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill - you have missed the point I think. Its not a DNS issue or an SSL
issue or a certificate structure issue.
PKI from many people's perspective is about applying cryptographic
techniques to current business information systems. These information
systems support services to the masses over a wider environment. ie the
generic business model is to authenticate uses at a number of levels,
allow service profiles to be applied to those users and verify
transactions by those users at the originating and the recipient end of
the business. And this must occur across a multi domain environment. The
foundation of all this is information sets related to Users and Services
and because these need to be globally named, distributed and protected
(and evolving to OO paradigms) then the directory serves this
requirement. PKIs are applied to this evolution. They DONT create it.
ie. DNS is about host / domain names for computers to relate IP
addresses .ie machiney level things. Its not OO in my book.
X.500 is about OO application to real life entities such as ships,
people, workflow applications, library books, Media content, Users, etc.
real named items with real life attributes with real life privileges.
X.500 is being deployed in masses....with PKIs and a lot faster than
PKIs on their own - reason already stated.
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Thursday, 29 October 1998 3:37
> To: Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan issued the following challenge,
>
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
>
> Seems like a good question, it occured to me that now is a good time
> to
> raise it.
>
> Look at the one already deployed and work it out. The SSL secured part
> of
> the Web does not stop working if directory.verisign.com goes down.
>
> I have had this arguement before with the hypertext establishment.
> They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were
> completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L
> to
> give the keynote!
>
> The greater the scale the less weight a base information system can
> carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of
> consistency
> across transactions. Finally at global scale it is not practical to
> deal in
> data, we must deal in names instead, names in this case being of
> Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live)
> to
> make the DNS sytem tractable, precisely because they have Sebok's
> 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
>
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
>
> Making PKI scale to global reach is no more than a matter of naming.
> Bind
> the network level directory infrastructures to the internet naming
> system
> which is and will continue to be DNS.
>
> There is already a DNS resource record defined for the purpose - SRV.
> If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
>
> Email client is to send to fred@arius.com, there is no cert in the
> address
> book:
>
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> _ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> _ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> _ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest
> priority
> number which offers a directory protocol that is understood,
> in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> fred@arius.com
> 5) The client retrieves the certificates for the entry, there are
> three
> of which one is a currently valid one for fred@arius.com
> 6) The client encrypts the email
> 7) The client sends the email
>
>
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
>
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
>
>
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
>
>
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
>
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
>
> __pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> __pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> __pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
>
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
>
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
>
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have
> deployed.
>
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
>
>
> Phill
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27036 for ietf-pkix-bks; Wed, 28 Oct 1998 14:24:35 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27032 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:24:32 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2T>; Thu, 29 Oct 1998 09:22:20 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B7@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>
Cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 29 Oct 1998 09:22:17 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Perhaps one of the approaches here is to put public information into
"Border" or Public DSAs that serve the external interactions of an
organisation - as Read Only systems.
These DSAs are used to protect aggregation threats and possibly
name/semantic dissemination. Some systems being designed explicitly
state such devices with trusted oneway/mapping replication unctions from
the core internal systems.
regards alan
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Thursday, 29 October 1998 4:21
> To: Alan Lloyd
> Cc: 'Phillip M Hallam-Baker'; Al Arsenault; Stephen Kent;
> ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> ... and the other serious problem that is starting to show up is the
> privacy issues related to information that might be in a directory
> ....
> even a name field might represent a privacy concern.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26999 for ietf-pkix-bks; Wed, 28 Oct 1998 14:21:27 -0800 (PST)
Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA26995 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:21:26 -0800 (PST)
Received: from thunderbolt.ncsl.nist.gov (thunderbolt.ncsl.nist.gov [129.6.54.130]) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) with SMTP id RAA22220; Wed, 28 Oct 1998 17:20:04 -0500
Message-Id: <3.0.5.32.19981028172103.03924b80@csmes.ncsl.nist.gov>
X-Sender: burr@csmes.ncsl.nist.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Wed, 28 Oct 1998 17:21:03 -0500
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>, "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
From: Bill Burr <william.burr@nist.gov>
Subject: RE: Scale (and the SRV record)
In-Reply-To: <001501be02a5$77fd4920$c807a8c0@pbaker-pc.verisign.com>
References: <4.1.19981028132138.009c32b0@mail.spyrus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill,
I'm in a bit over my head here now (arguably I have been all along),
because I don't understand SRVs very well, and I had the impression that
they're more a proposal than a reality. Would we be betting on the come
here? Or is support SRVs really in DNS servers and resolvers now?
Regards,
Bill Burr
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26975 for ietf-pkix-bks; Wed, 28 Oct 1998 14:19:41 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26971 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:19:39 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2S>; Thu, 29 Oct 1998 09:17:26 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B6@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'salzr@certco.com'" <salzr@certco.com>, "'Russ Housley'" <housley@spyrus.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 09:17:25 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> -----Original Message-----
> From: salzr@certco.com [SMTP:salzr@certco.com]
> Sent: Thursday, 29 October 1998 5:56
> To: 'Russ Housley'; Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: Scale (and the SRV record)
>
> >Denial of service is allways an issue; it is a concern in
> >all of the possible repository alternatives.
>
> At the risk of stating the obvious, a denial of service that
> prevents you from getting revocation information (such as a
> CRL) can be Very Bad, given the implementation quality of most
> network services that I've seen...
[Alan Lloyd]
Yes, and we enforce that risk by saying LDAP is the way to go.
:-)
"Dont Use Copy" - see X.511 (DAP) and knowing master DSAs is
good.
regards
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA26953 for ietf-pkix-bks; Wed, 28 Oct 1998 14:17:35 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA26949 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 14:17:32 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P2R>; Thu, 29 Oct 1998 09:15:16 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4B5@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Russ Housley'" <housley@spyrus.com>
Cc: ietf-pkix@imc.org
Subject: RE: Scale (and the SRV record)
Date: Thu, 29 Oct 1998 09:15:15 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> -----Original Message-----
> From: Russ Housley [SMTP:housley@spyrus.com]
> Sent: Thursday, 29 October 1998 5:29
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan asks:
>
> > I need to be enlightened - How does one deploy a large scale
> distributed
> > PKI without a large scale object oriented distributed (and protected
> by
> > ACI, etc) directory system?
>
> Directory is the preferred certificate repository, but it is not the
> only
> repository that will scale. People have used FTP, Finger, HTTP, and
> other
> mechanisms to distribute certificates.
[Alan Lloyd]
Distribution of certificates is not the issue.
How as a recipient of signed messages follow multiplecertificate
paths - without a directory?.
> The PKI is not dependent on the deployment of a Directory, as these
> other
> mechanism can be used until the Directory become widely available.
[Alan Lloyd] But as I have said, they are bespoke, do not tie
well to business and customer management/ service delivery models or
distributed , transaction based information systems over a wide scale -
efficiently.
> Further, a trusted repository is not a requirement. Since
> certificates and
> CRLs are signed, the repository cannot make undetected modification to
> the
> data structures. Denial of service is allways an issue; it is a
> concern in
> all of the possible repository alternatives.
[Alan Lloyd] Agree
> Russ
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25206 for ietf-pkix-bks; Wed, 28 Oct 1998 10:59:50 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25202 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:59:49 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id KAA21485; Wed, 28 Oct 1998 10:59:15 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id LAA00840; Wed, 28 Oct 1998 11:01:27 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Russ Housley" <housley@spyrus.com>, <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 14:02:11 -0500
Message-ID: <001501be02a5$77fd4920$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <4.1.19981028132138.009c32b0@mail.spyrus.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Russ,
You are right of course! Note that the scheme I propose allows a
certificate repository whose naming scheme is PKIX compatible to also be
advertised. We might have:
__pkix._http._tcp.arius.com
__pkix._ldap._tcp.arius.com
__pkix._finger._tcp.arius.com
or even!
__pkix._verynewprotocol.arius.com
And since an SRV record is simply an MX record on steroids each
can define server priorities and preferences.
What would then be required is a draft describing the naming
conventions such a server would conform to and how clients should
interpret the scope of the statement. __pkix._http._tcp.arius.com
is essentially saying "look at the corresponding server where you
will find a PKIX repository whose scope includes (all?) certificates
issued which are bound to DNS names within the scope 'arius.com'."
Alan will have a directory there (we presume) as I would expect
would most enterprises. There might be a move in favour of an HTTP
service acting as a border directory and an LDAP server providing
a more flexible, searchable service inside the enterprise.
Phill
> -----Original Message-----
> From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org]On Behalf
> Of Russ Housley
> Sent: Wednesday, October 28, 1998 1:29 PM
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
>
> Alan asks:
>
> > I need to be enlightened - How does one deploy a large scale distributed
> > PKI without a large scale object oriented distributed (and protected by
> > ACI, etc) directory system?
>
> Directory is the preferred certificate repository, but it is not the only
> repository that will scale. People have used FTP, Finger, HTTP, and other
> mechanisms to distribute certificates.
>
> The PKI is not dependent on the deployment of a Directory, as these other
> mechanism can be used until the Directory become widely available.
>
> Further, a trusted repository is not a requirement. Since
> certificates and
> CRLs are signed, the repository cannot make undetected modification to the
> data structures. Denial of service is allways an issue; it is a
> concern in
> all of the possible repository alternatives.
>
> Russ
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25184 for ietf-pkix-bks; Wed, 28 Oct 1998 10:57:34 -0800 (PST)
Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25180 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:57:33 -0800 (PST)
Received: from jekyll (localhost [[UNIX: localhost]]) by jekyll.piermont.com (8.8.8/8.6.12) with ESMTP id NAA00269; Wed, 28 Oct 1998 13:59:19 -0500 (EST)
Message-Id: <199810281859.NAA00269@jekyll.piermont.com>
To: WHenry <WHenry@pec.com>
cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Re: Scale (and the SRV record)
In-reply-to: Your message of "Wed, 28 Oct 1998 12:42:33 EST." <3C7EABA3F6F1D1118FD90008C7F450FDA65C16@exchang-fairfax.pec.com>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 28 Oct 1998 13:59:19 -0500
From: "Perry E. Metzger" <perry@piermont.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
WHenry writes:
> The problem with this remark is that 9/10 of all SSL sites are using SSLv2,
> and there is no "real" authentication happening here.
>
> Example... just because Verisign's cert is posted in my browser doesn't
> mean:
> 1. I should trust that this embedded cert is valid, and
> 2. I should trust an online vendor that he/she is who they say they
> are.
>
> Verisign's own Certification Practice Statement (CPS) says it all: Versign
> is not liable for verifying the identity of certificate users.
Reminds me of four different talks given at the Usenix E.C. conference
a couple of months ago, all of which were of the substance "third
party certificates with liability disclaimers are worthless..."
.pm
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25166 for ietf-pkix-bks; Wed, 28 Oct 1998 10:54:42 -0800 (PST)
Received: from fwma1.certco.com (fwma1.certco.com [208.222.33.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25162 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:54:41 -0800 (PST)
From: salzr@certco.com
Received: (from uucp@localhost) by fwma1.certco.com (8.8.8/8.8.8) id NAA01272; Wed, 28 Oct 1998 13:56:38 -0500 (EST)
Received: from smtp.ma.certco.com(10.200.200.11) by fwma1.certco.com via smap (V2.1) id xma001267; Wed, 28 Oct 98 13:56:24 -0500
Received: from stig (stig.ma.certco.com [10.200.200.45]) by smtp.ma.certco.com (8.8.5/8.8.5) with SMTP id NAA04846; Wed, 28 Oct 1998 13:56:24 -0500 (EST)
To: "'Russ Housley'" <housley@spyrus.com>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 13:56:23 -0500
Message-ID: <29E0A6D39ABED111A36000A0C99609CA18D2E5@macertco-srv1.ma.certco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <4.1.19981028132138.009c32b0@mail.spyrus.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>Denial of service is allways an issue; it is a concern in
>all of the possible repository alternatives.
At the risk of stating the obvious, a denial of service that
prevents you from getting revocation information (such as a
CRL) can be Very Bad, given the implementation quality of most
network services that I've seen...
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA25035 for ietf-pkix-bks; Wed, 28 Oct 1998 10:34:56 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA25031 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:34:55 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.66.65.231]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id KAA10033; Wed, 28 Oct 1998 10:36:26 -0800 (PST)
Message-Id: <4.1.19981028132138.009c32b0@mail.spyrus.com>
X-Sender: rhousley@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 28 Oct 1998 13:28:48 -0500
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
From: Russ Housley <housley@spyrus.com>
Subject: Scale (and the SRV record)
Cc: ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan asks:
> I need to be enlightened - How does one deploy a large scale distributed
> PKI without a large scale object oriented distributed (and protected by
> ACI, etc) directory system?
Directory is the preferred certificate repository, but it is not the only
repository that will scale. People have used FTP, Finger, HTTP, and other
mechanisms to distribute certificates.
The PKI is not dependent on the deployment of a Directory, as these other
mechanism can be used until the Directory become widely available.
Further, a trusted repository is not a requirement. Since certificates and
CRLs are signed, the repository cannot make undetected modification to the
data structures. Denial of service is allways an issue; it is a concern in
all of the possible repository alternatives.
Russ
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA24886 for ietf-pkix-bks; Wed, 28 Oct 1998 10:13:11 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA24882 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 10:13:09 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id NAA19358; Wed, 28 Oct 1998 13:15:19 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA14076; Wed, 28 Oct 1998 13:15:15 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AB.0063ED3E ; Wed, 28 Oct 1998 13:11:27 -0500
X-Lotus-FromDomain: FDC
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>
cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Stephen Kent" <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566AB.0062D617.00@lnsunr02.firstdata.com>
Date: Wed, 28 Oct 1998 10:13:23 -0800
Subject: Re: Scale (and the SRV record)
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
spent a lot of time on the SSL portion of the web ... 94/95 working out how
to do/deploy electronic commerce operations. Current SSL infrastructure
uses server certificate for key exchange ... not for authentication. To the
extent that there is authentication done ... it consists of checking the
certificate issuer against a list that has typically pre-installed in the
browser (not checking on the certificate owner). It is one of the reasons
that I coined the term certificate manufactoring .... to highlight
manufactoring and distributing certificates is typically only a small part
of what has become to be considered part of a PKI infrastructure.
I got possibly the first mutual authentication SSL deployed ... before it
was called SSL3. Again authentication was limited to verifying the
certificate issuer. The server certificate was essentially a comfort device
for all the clients ... the client certificates started out essentially
being "relying party" certificates .... but to do more than simple
certificate issuer authenitcation ... i had to check the certificate owner
information against an account database. At that point it became evident
that even relying party certificates were superfulous in the transaction
since I needed to reference the account record (which already had copy of
the public key, lots of attribute binding ... as well as up-to-date
real-time status).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24626 for ietf-pkix-bks; Wed, 28 Oct 1998 09:39:31 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24622 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 09:39:30 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP (peer crosschecked as: [204.254.216.13]) id QQfnbq26760; Wed, 28 Oct 1998 12:41:05 -0500 (EST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <VL2FG9LQ>; Wed, 28 Oct 1998 12:42:34 -0500
Message-ID: <3C7EABA3F6F1D1118FD90008C7F450FDA65C16@exchang-fairfax.pec.com>
From: WHenry <WHenry@pec.com>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 12:42:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phillip,
The problem with this remark is that 9/10 of all SSL sites are using SSLv2,
and there is no "real" authentication happening here.
Example... just because Verisign's cert is posted in my browser doesn't
mean:
1. I should trust that this embedded cert is valid, and
2. I should trust an online vendor that he/she is who they say they
are.
Verisign's own Certification Practice Statement (CPS) says it all: Versign
is not liable for verifying the identity of certificate users.
Bill Henry
Fairfax, VA
"Look at the one already deployed and work it out. The SSL secured
part of
the Web does not stop working if directory.verisign.com goes down."
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Wednesday, October 28, 1998 11:37 AM
> To: Alan Lloyd
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: Scale (and the SRV record)
>
> Alan issued the following challenge,
>
> > I need to be enlightened - How does one deploy a large scale distributed
> > PKI without a large scale object oriented distributed (and protected by
> > ACI, etc) directory system?
>
> Seems like a good question, it occured to me that now is a good time to
> raise it.
>
> Look at the one already deployed and work it out. The SSL secured part of
> the Web does not stop working if directory.verisign.com goes down.
>
> I have had this arguement before with the hypertext establishment. They
> could never figure out how it was possible to have global network
> hypertext
> without an 'object oriented distributed' database. They were completely
> wrong but that did not stop them from rejecting every conference paper
> on the Web, until the time came when they were clamouring for Tim B-L to
> give the keynote!
>
> The greater the scale the less weight a base information system can carry.
> A transactional database can scale to tens of hosts at best - and even
> then
> this requires carefull choice of the transactions allowed. A directory
> system
> scales further because it guarantees so much less in terms of consistency
> across transactions. Finally at global scale it is not practical to deal
> in
> data, we must deal in names instead, names in this case being of Pierce's
> 'thirdness' quality and whose persistence can defined (Time To Live) to
> make the DNS sytem tractable, precisely because they have Sebok's 'Name'
> property - the relationship between the symbol and the designatum is
> purely conventional.
>
> Compare this approach to what we do with PKI, we use public key to
> establish a trust framework we then leverage with private key. Or as
> an analogy consider the task of throwing a heavy rope across a chasm,
> starting with a thin, light piece of string and working up.
>
> Making PKI scale to global reach is no more than a matter of naming. Bind
> the network level directory infrastructures to the internet naming system
> which is and will continue to be DNS.
>
> There is already a DNS resource record defined for the purpose - SRV. If
> we assume that every enterprise has deployed a border LDAP directory
> populated with the certificates of its employees we can send encrypted
> S/MIME messages to any certificate holder as follows:
>
> Email client is to send to fred@arius.com, there is no cert in the address
> book:
>
> 1) The client obtains the DNS RR's for arius.com
> 2) The client examines the SRV records, there are three
> _ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> _ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> _ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
> 3) The client attempts to connect to the server with the lowest priority
> number which offers a directory protocol that is understood,
> in this case directory.arius.com offers LDAP over TCP/IP
> 4) The client does a search for an entry with a mail atribute of
> fred@arius.com
> 5) The client retrieves the certificates for the entry, there are three
> of which one is a currently valid one for fred@arius.com
> 6) The client encrypts the email
> 7) The client sends the email
>
>
> Note that we have only one large scale infrastructure and it is DNS. I
> don't know if that meets the definition of 'object oriented' or not.
>
> Note also that this could equally well be achieved using some other
> type of server since as far as the client is concerned it is making
> an unambiguous query to a server. The question of the ideal server
> to server protocol is irrelevant to the client.
>
>
> The question of whether the certificate returned is one that can be
> trusted is orthogonal. Note that it is not one which in this case
> may be made by the server since it is most unlikely the client will
> in the general case be willing to share its trust criteria with an
> untrusted service.
>
>
> There is just one minor change we might want to make to the current
> SRV proposal. It would be useful to have a means of differentiating
> directories on the basis of the information held. Specifically it
> would be useful to be able to differentiate a directory acting as a
> PKIX repository for a particular domain.
>
> I would suggest that we ask that the SRV naming convention be extended
> a single level to provide a 'category' modifier, in this case PKIX.
> The above RRs would therefore be :-
>
> __pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
> __pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
> __pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
>
> The same convention could be reused in other areas, for example
> there is an urgent need for the universities to have some kind of
> protocol for discovery of journal articles, pre-publications and
> such. Say a working group sets up a set of conventions and a schema
> for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
> and __LIBRY._http._tcp SRVs defined. And of course there would be
> __ocsp._http._tcp.
>
> The point here is that we can leverage a widely deployed
> infrastructure. Paul Vixie modified the bind code three years ago and
> the upgrade has largely percollated.
>
> We can either spend time arguing what a global X.500 infrastructure
> will do fo us when it arrives or we can build on what we have deployed.
>
> So before proposing a change to the DNS/namedroppers folk what is the
> PKIX list view?
>
>
> Phill
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA24476 for ietf-pkix-bks; Wed, 28 Oct 1998 09:20:23 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA24472 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 09:20:22 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id MAA05229; Wed, 28 Oct 1998 12:22:33 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id MAA11968; Wed, 28 Oct 1998 12:22:32 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AB.005F19F8 ; Wed, 28 Oct 1998 12:18:45 -0500
X-Lotus-FromDomain: FDC
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566AB.005F4647.00@lnsunr02.firstdata.com>
Date: Wed, 28 Oct 1998 09:20:39 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
... and the other serious problem that is starting to show up is the
privacy issues related to information that might be in a directory ....
even a name field might represent a privacy concern.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24187 for ietf-pkix-bks; Wed, 28 Oct 1998 08:35:03 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24183 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 08:35:03 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA17572; Wed, 28 Oct 1998 08:34:27 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id IAA19175; Wed, 28 Oct 1998 08:36:41 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>
Subject: Scale (and the SRV record)
Date: Wed, 28 Oct 1998 11:37:21 -0500
Message-ID: <000401be0291$3c8dec00$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan issued the following challenge,
> I need to be enlightened - How does one deploy a large scale distributed
> PKI without a large scale object oriented distributed (and protected by
> ACI, etc) directory system?
Seems like a good question, it occured to me that now is a good time to
raise it.
Look at the one already deployed and work it out. The SSL secured part of
the Web does not stop working if directory.verisign.com goes down.
I have had this arguement before with the hypertext establishment. They
could never figure out how it was possible to have global network hypertext
without an 'object oriented distributed' database. They were completely
wrong but that did not stop them from rejecting every conference paper
on the Web, until the time came when they were clamouring for Tim B-L to
give the keynote!
The greater the scale the less weight a base information system can carry.
A transactional database can scale to tens of hosts at best - and even then
this requires carefull choice of the transactions allowed. A directory
system
scales further because it guarantees so much less in terms of consistency
across transactions. Finally at global scale it is not practical to deal in
data, we must deal in names instead, names in this case being of Pierce's
'thirdness' quality and whose persistence can defined (Time To Live) to
make the DNS sytem tractable, precisely because they have Sebok's 'Name'
property - the relationship between the symbol and the designatum is
purely conventional.
Compare this approach to what we do with PKI, we use public key to
establish a trust framework we then leverage with private key. Or as
an analogy consider the task of throwing a heavy rope across a chasm,
starting with a thin, light piece of string and working up.
Making PKI scale to global reach is no more than a matter of naming. Bind
the network level directory infrastructures to the internet naming system
which is and will continue to be DNS.
There is already a DNS resource record defined for the purpose - SRV. If
we assume that every enterprise has deployed a border LDAP directory
populated with the certificates of its employees we can send encrypted
S/MIME messages to any certificate holder as follows:
Email client is to send to fred@arius.com, there is no cert in the address
book:
1) The client obtains the DNS RR's for arius.com
2) The client examines the SRV records, there are three
_ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
_ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
_ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
3) The client attempts to connect to the server with the lowest priority
number which offers a directory protocol that is understood,
in this case directory.arius.com offers LDAP over TCP/IP
4) The client does a search for an entry with a mail atribute of
fred@arius.com
5) The client retrieves the certificates for the entry, there are three
of which one is a currently valid one for fred@arius.com
6) The client encrypts the email
7) The client sends the email
Note that we have only one large scale infrastructure and it is DNS. I
don't know if that meets the definition of 'object oriented' or not.
Note also that this could equally well be achieved using some other
type of server since as far as the client is concerned it is making
an unambiguous query to a server. The question of the ideal server
to server protocol is irrelevant to the client.
The question of whether the certificate returned is one that can be
trusted is orthogonal. Note that it is not one which in this case
may be made by the server since it is most unlikely the client will
in the general case be willing to share its trust criteria with an
untrusted service.
There is just one minor change we might want to make to the current
SRV proposal. It would be useful to have a means of differentiating
directories on the basis of the information held. Specifically it
would be useful to be able to differentiate a directory acting as a
PKIX repository for a particular domain.
I would suggest that we ask that the SRV naming convention be extended
a single level to provide a 'category' modifier, in this case PKIX.
The above RRs would therefore be :-
__pkix._ldap._tcp.arius.com SRV 0 0 389 directory.arius.com
__pkix._ldap._tcp.arius.com SRV 1 3 389 fast.backup-site.net
__pkix._ldap._tcp.arius.com SRV 1 1 389 slow.backup-site.net
The same convention could be reused in other areas, for example
there is an urgent need for the universities to have some kind of
protocol for discovery of journal articles, pre-publications and
such. Say a working group sets up a set of conventions and a schema
for such stuff called 'LIBRY', they might have __LIBRY._ldap._tcp
and __LIBRY._http._tcp SRVs defined. And of course there would be
__ocsp._http._tcp.
The point here is that we can leverage a widely deployed
infrastructure. Paul Vixie modified the bind code three years ago and
the upgrade has largely percollated.
We can either spend time arguing what a global X.500 infrastructure
will do fo us when it arrives or we can build on what we have deployed.
So before proposing a change to the DNS/namedroppers folk what is the
PKIX list view?
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24122 for ietf-pkix-bks; Wed, 28 Oct 1998 08:28:42 -0800 (PST)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24118 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 08:28:40 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id LAA18146; Wed, 28 Oct 1998 11:30:43 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id LAA09296; Wed, 28 Oct 1998 11:30:41 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566AB.005A5650 ; Wed, 28 Oct 1998 11:26:43 -0500
X-Lotus-FromDomain: FDC
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
cc: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566AB.005A6EB8.00@lnsunr02.firstdata.com>
Date: Wed, 28 Oct 1998 08:27:45 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
small note ... from business standpoint ... it might be better explained
that no directories no authentication infrastructure (which is the business
process/requirement) ... a PKI is then a method of implementing that
infrastructure. Part of the problem with starting with PKI as a solution
and then asking what the problem is .... one might might be led into
presuming that some of the existing PKIs deployed for independent pilots
are the structure one would automatically use as an integrated business
solution.
directories actually have other business needs independent of the
authentication infrastructure. in past life, looked at one customer that
had on the order of 6000 RDBMS where 90% of the data was common. schema
integration directory was needed just so that simple things like changing
the name on an account is consistently done thruout the business (side
problem was wide variety of different terms that were used in schemas for
common things like name).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24022 for ietf-pkix-bks; Wed, 28 Oct 1998 08:06:21 -0800 (PST)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24018 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 08:06:19 -0800 (PST)
Received: from stefans (t1o68p120.telia.com [62.20.138.120]) by maila.telia.com (8.8.8/8.8.8) with SMTP id RAA09568 for <ietf-pkix@imc.org>; Wed, 28 Oct 1998 17:08:13 +0100 (CET)
Message-Id: <3.0.32.19981028170254.00a11db0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Wed, 28 Oct 1998 17:04:40 +0100
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: Internet draft for Qualified Certificates.
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA24019
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Anders,
An unmistakable name doesn't have to be static. It is unmitakable as long
as the relying party can use the name to identiy the subject for as long as
the certificate is valid and not revoked.
It is at this moment outside the scope of this I-D to make any requirements
on how static a name should be. This is up to the CA to decide and up to
the relying party to accept.
/Stefan
At 04:17 PM 10/28/98 +0100, Anders Rundgren wrote:
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Stefan, I still have some serious problems with the definitions and
interpretations.
>
>>>How does a certificate-relying party know what fields form
>>>an unmistakable name of the subject?
>>>
>>>Unmistakable is different from static identity I guess?
>>>
>>>Anders
>
>>An unmistakable name of the subject SHALL be obtained by combining the
value of the subjects
>>registered name attributes or pseudonym attributes, with the values of
the following attribute
>>types;
>>countryName
>>civicRegistrationNumber
>>serialNumber
>>organizationName
>>organizationalUnitName
>>postalAddress
>
>To me a Swedish EID forms an unmistakable subject identity (99.999%) by just
>using civicRegistrationNumber.
>
>By using the other (non-static) attributes you loose unmistakable. You
just have to change
>employer to break it!
>
>I would also like to see the *static* identity possibility covered by the
draft. I.e. it should
>be clear for a certificate-relaying party if is unmistakable in the way
you use that
>word in other contexts.
>
>Anders
>
>
>
>----------------- SEIS mailing list (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA28145 for ietf-pkix-bks; Tue, 27 Oct 1998 16:52:56 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA28140 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 16:52:46 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P1P>; Wed, 28 Oct 1998 11:50:28 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4A6@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Lynn.Wheeler@firstdata.com
Cc: Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Wed, 28 Oct 1998 11:50:27 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Phill - again you promote a separation - in an abstract way. But I
question why would one implement 509 without X.500? What is the
separation in terms of distributed information system engineering and
what is your solution of dealing with the need to have single logon on
to distributed services and single information entities representing
customers, staff and assets - that have certificates applied.?
Many organisations have many customer databases - islands of "may be
replicated" information. This equals high operational costs, high risks
to business because of inconsistency, inability to scale, long service
provisioning times - ie. a high cost mess. Directory technologies
provide a damn good vehicle to consolidate these information systems.
It seems you are proposing to put PKIs over a fragmented and legacy
information pradigm. Wont this add to the mess?
Your words
"In other words you do not want to have a directory
intermediating
between the PKI and your application."
Can you tell us how you do this? given that the application has to chase
across the planet in a standard way for an object that represents the a
certficate user (or CA)- and that such an object will have other
business details and attributes, will have to exist somewhere in a
distributed environment - and for the sake of efficiency and cost and
the integrity of service provisioning (by large corporates) should exist
in one place -- by NAME.
I need to be enlightened - How does one deploy a large scale distributed
PKI without a large scale object oriented distributed (and protected by
ACI, etc) directory system?
Isnt this a bit like deploying secure telephones (with customised wires)
without a telephone network?
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Tuesday, 27 October 1998 8:25
> To: Lynn.Wheeler@firstdata.com
> Cc: Alan Lloyd; Al Arsenault; Stephen Kent; ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
>
>
> > there are business operations with account-based systems with
> >100million
> > entries and raw
> > data in tens of terabytes. for business process that have to access
> the
> > account record to complete the transaction, splitting responsibility
> for
> > the transaction between an account infrastructure and a PKI
> infrastructure
> > ... doesn't improve availability ... it actually lowers it since now
> there
> > has to be two things that are operational for transaction completion
>
> I would not propose such a split. In fact I think it argues to my
> point.
>
> Perhaps I have been unclear, the functional division I see as
> essential
> is at a somewhat abstract level. I want to avoid bluring the
> distinctions
> between PKI functions and information distribution functions precisely
> so that applications such as Lynn's can be supported.
>
>
> You want the authentication information from the PKI to directly mesh
> into the authorization information supplied by your application.
>
> In other words you do not want to have a directory intermediating
> between the PKI and your application.
>
> The question to ask is 'what box (program etc.) have I just added
> that can break?'
>
> If there is a per-transaction protocol connection required for PKI
> use, it will as you said reduce your availability. But PKI is not
> inherently protocol oriented. Nor is it necessarily a 'box to
> break'. It would be more accurate to view being 'PKI aware' as being
> a quality of systems rather than "THE PKI" being a discrete system
> in its own right that can be pointed out in the control room and
> thumped with a hammer when it breaks:-)
>
> In other words the PKI should not mandate a 'coherent directory
> infrastructure' since the PKI abstraction should not care how the
> bits arrived so long as they are properly signed. But what the PKI
> suite of standards MUST do is to state how to link to a directory
> to obtain such information in the case where one is available.
>
>
> To permit scale your PKI protocol infrastructure needs to be entirely
> integrated within your transaction protocol infrastructure - at least
> for that *particular* application. That does not mean however that
> there is no 'PKI' component or indeed that every piece of the
> infrastructure must be integrated at that level - certificate
> issue could well be independent.
>
> A good reason to be ruthless when insisting on separation of function!
> It is very easy to propose tweaks that look very good in a limited
> context but fail in a larger one.
>
> Phill
>
>
> [PS OK I'll admit that it is much the same once you get up to
> Terabytes
> of data but I was talking about input bandwidth, not just static
> storage :-) I think that you Steve and myself are essentially arguing
> the same point though.]
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27798 for ietf-pkix-bks; Tue, 27 Oct 1998 16:35:05 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27794 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 16:35:01 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P1N>; Wed, 28 Oct 1998 11:32:45 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4A5@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>, Phillip M Hallam-Baker <pbaker@verisign.com>
Cc: Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Wed, 28 Oct 1998 11:32:44 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Totally agree.
PKI is not a God on High, it is a security function that is applied to
a business (with various levels of trust) commensurate and in line with
the service provisioning and investments (of IT systems) of that
business. And first and foremost in that application process, the PKI
and the business information concepts and models have to integrate. Ie.
if databases integrate with the directory systems (or become them), the
PKI functions can be applied.
A key system is there to protect the delivery of IT services - and the
investments in the implementation, delivery and management those
services in a global market will probably be 20 times that of any PKI
expenditure. And generally experience is showing that the PKI function
is applied to existing services. Not the other way round.
regards alan
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Tuesday, 27 October 1998 6:16
> To: Phillip M Hallam-Baker
> Cc: Alan Lloyd; Al Arsenault; Stephen Kent; ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> there are business operations with account-based systems with
> >100million
> entries and raw
> data in tens of terabytes. for business process that have to access
> the
> account record to complete the transaction, splitting responsibility
> for
> the transaction between an account infrastructure and a PKI
> infrastructure
> ... doesn't improve availability ... it actually lowers it since now
> there
> has to be two things that are operational for transaction completion
> i.e.
> availability to complete is the product of the availability of the two
> infrastructures; for availability to improve, transaction would have
> to be
> able to complete even if the whole PKI infrastructure or the whole
> account
> infrastructure was not operational (and since the original premise was
> that
> at least the account infrastructure has to be operational for the
> transaction to complete; adding a PKI infrastructure can't improve the
> availibitliy)
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27747 for ietf-pkix-bks; Tue, 27 Oct 1998 16:26:28 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27743 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 16:26:11 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW3P1L>; Wed, 28 Oct 1998 11:22:54 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D4A4@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Phillip M Hallam-Baker'" <pbaker@verisign.com>, Lynn.Wheeler@firstdata.com, Al Arsenault <aarsenault@spyrus.com>
Cc: Stephen Kent <kent@bbn.com>, ietf-pkix@imc.org
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Wed, 28 Oct 1998 11:22:53 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
You may disagree Phill - but do you have an alternative
information/services solution for organisations who want to represent
and manage their customers, 10s if not 100's of millions of customers in
a distributed way across this planet.
The bottom line is that a "PKI" technologies on their own with
customised databases and odd validation protocols do not scale well.
Also a free standing PKI does not represent a complete service
provisioning system for dealing with customers over a distributed
environment. Also PKI on its own does not provide a consistent approach
the business or operational issues which usually dominate real, large
scale information systems.
Please note, that when I say a coherent directory strategy is needed, I
dont mean that there is one directory for the whole world or for a
complete organisation. There will be directory system (s) aligned to
specific vertical markets (WP, retail, defence, transport, libraries,
etc), there will also be WEB systems, there will also be databases, etc.
and there will be integration between these information functions
through tools, etc. And companies will apply directory technology to
support a service over a sphere of influence. eg. Customer
authentication and access.
My comment is that, one cannot put, IMHO, attributes such as
certificates, that relate to objects (X.500 style) into a serviceable
environment without a directory system - if you want to add business
related information to such objects and you want scaleability (ie.
distribution - with distributed acccess and administration).
The other way of doing this is via a dedicated database and bespoke
validation protocols onto bespoke information models. ie. no
scaleability and and one cannot add business information. Where would
such a system be used? Well only limited, very complex enclaves with
"small" (10k) numbers of users with limited services.
The world is moving toward a directory infrastructure - ie. the
evolution is from customised databases--> WEB based for browsing
text---> and additionally distributed object texhnologies (directories).
The DEN initiative and many vendors "directory enabling" their
applications prove this - eg. see SAP and Peoplesoft announcements re
directory enabling...
I think that PKIX wont go far without considering the fundamental issues
of being directory enabled or supported.
And to date - all I hear is that PKI can happen without
directories...Well I travel the planet and work with big organisations
and in my book, no directories = no PKI.
So perhaps there is a market for small dedicated PKIs but what is the
PKIX list's view in providing a PKI for the Internet - ie. 100m users? a
customised central database?
regards alan
> -----Original Message-----
> From: Phillip M Hallam-Baker [SMTP:pbaker@verisign.com]
> Sent: Tuesday, 27 October 1998 4:01
> To: Alan Lloyd; Lynn.Wheeler@firstdata.com; Al Arsenault
> Cc: Stephen Kent; ietf-pkix@imc.org
> Subject: RE: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> > ie. The direction today is to consolidate business information
> models in
> > line with current systems be it "internal" for Staff and "external"
> > Customers with X.500 directory systems ....
>
> I disagree.
>
> The idea that there is one 'direction' that is appropriate for the
> market as a whole is simply ridiculous. There are directions that
> will be more appropriate for some applications than others.
>
> There are many organizations in which the deployment of a PKI will
> never happen if the precondition is the deployment of a coherent
> directory strategy. The 'consolidated approach' to information
> systems has been tried and the current CIO got where he did by
> dismantling it.
>
>
> As Steve said, been there, done that.
>
> Having built systems which by anyone's definition are 'extreeme'
> scale-wise (anyone else here commissioned machines dealing with
> 6Tb/sec raw data?) the major lesson I have drawn from this
> experience is the need to insist on tight compartmentalization
> of functionality. The interdependencies between complex
> infrastructure must be ruthlessly pruned to the bare minimum.
>
> The 'directory-centric' PKI that Alan is promoting is simply
> a further step in a direction that is already causing severe
> scaling problems. Directory dependent PKI can only scale as
> far as the directory. Where is the global X.500 directory?
>
> A PKI should be able to take advantage of a directory if it is
> there (call it directory linkable?) - but collapse in a quivering
> heap if the directory has a bad day? - NEVER!
>
>
> Until someone can show me a directory system with 100 million
> users that is deployed the 'directories scale hypothesis' is
> unproven in my view.
>
> More seriously however the ability of directories to scale
> rests upon a very tightly circumscribed set of duties which
> they respond to. After all the difference between a directory
> and a database is simply that the transaction coherency
> requirements which are costly to implement in conjunction
> with replication are not supported by a directory.
>
> In other words a directory might scale to 100 million users,
> but not if we start tampering with the assumptions on which
> that scalability depends. The scaling of Web servers became
> much more difficult once they became stateful.
>
>
> Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA27986 for ietf-pkix-bks; Mon, 26 Oct 1998 16:12:41 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA27979 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 16:12:38 -0800 (PST)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id BAA25663 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 01:14:36 +0100 (CET)
Received: from stefans (t3o68p32.telia.com [62.20.139.32]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id BAA04897 for <ietf-pkix@imc.org>; Tue, 27 Oct 1998 01:14:28 +0100 (CET)
Message-Id: <3.0.32.19981027005928.00979400@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 27 Oct 1998 01:10:51 +0100
To: ietf-pkix@imc.org
From: Stefan Santesson <stefan@accurata.se>
Subject: Draft for Qualified Certificates
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id QAA27980
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
As a result from the Chicago meeting I have formed a first preliminary
version of an Internet draft for Qualified Certificates.
The ambition is that this draft shall be developed as a PKIX work item and
finally go the standards track.
The need for this specification is called for by the legal and technical
debate concerning digital signatures which are considered legally
compatible with handwritten signatures.
I will just very shortly give a condensed outline of the preliminary
results and last I copy the complete draft.
Condensed outline:
------------------
The draft is based on PKIX part 1, which in the draft is referred to as
RFCxxxx
The draft focus on a harmonized definition on names (issuer and subject).
It also mandate some extensions to be present and critical.
Issuer name:
Issuer name shall form an unmistakable name of the issuer by examining the
present values of the following attributes:
countryName
stateOrProvinceName
organizationName
commonName
Subject name:
Subject name can be based on a registered name or a pseudonym.
A registered name shall be hold in the attributes surname and givenName
Pseudonyms shall be hold in a newly defined pseudonym attribute
In addition to this the present pseudonym or registered name may be
reflected in the commonName attribute. This represent the subjects name in
a preferred presentation format.
An umistakable name shall be formed by the pseudonym or registered names in
combination with the present values of the following attributes:
countryName (defines the context of other attributes)
civicRegistrationNumber (newly defined)
serialNumber (added to the preferredAttributes list)
organizationName
organizationalUnitName
postalAddress
Other:
Some useful additional attributes are defined (countryOfCitizenship and
countryOfResidence )
The policy extension shall be present and marked critical. The purpose of
the certificate should be defined directly or indirectly by the policy
(including conformance to this profile).
Key usage shall exclusively be marked for non-repudiation.
Key identifier extension shall be present but shall NOT be marked critical.
--------------------------------------------------------
Below follows the complete draft (preliminary version)
All comments are highly appreciated.
/Stefan
PKIX Working group S.Santesson (SEIS)
Internet Draft
October 26, 1998
Expires six in months
Internet X.509 Public Key Infrastructure
Qualified Certificates
<draft-ietf-santesson-qc-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet- Drafts as reference material or to cite
them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This Internet-Draft forms a certificate profile for Qualified Certificates,
based on RFCxxxx, for use in the Internet. In this document the term
Qualified Certificate is used to describe a certificate which is aimed to
support digital signatures in a context which is considered functionally
equivalent to the use of handwritten signatures.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Please send comments on this document to the ietf-pkix@imc.org mail list.
1 Introduction
This standard is one part of a family of standards for the X.509 Public Key
Infrastructure (PKI) for the Internet. The standard is based on RFC xxxx,
which defines underlying certificate formats and semantics needed for full
implementation of this standard.
The standard profiles the format and semantics for a specific type of
certificates named Qualified Certificates. The term Qualified Certificates,
its functional relations to legal frameworks and the assumptions that
affects the scope of this document are defined in section 2.
Section 3 defines requirements on information content in Qualified
Certificates.
In Appendix A some security considerations are discussed in order to
clarify the security context in which Qualified Certificates are assumed to
be utilized.
Finally Appendix B contains all relevant ASN.1 structures which are not
already defined in RFCxxxx.
2 Requirements and assumptions
The term Qualified Certificates is defined in this section with the only
purpose to clarify the scope of this standard. The actual mechanisms that
will decide whether a certificate should or should not be considered
qualified to meet this definition or whether this definition is relevant
for a particular certificate or service, are outside the scope of this
standard.
In this context the term Qualified Certificate defines a certificate which
has the properties defined in section 2.1, fall within the legal
assumptions in section 2.2, and have the primary purpose of identifying a
person with high level of assurance in non-repudiation services, which may
protect considerable values.
Harmonization in the field of Qualified Certificates is essential within
several aspects that falls outside the scope of RFCxxxx. The most important
aspects that affects the scope of this specification are:
- Definition of names and identity information in order to
identify the associated subject in a uniform way.
- Definition of information which identifies the jurisdiction under
which the CA operates when issuing a particular certificate.
- Definition of key usage extension usage for Qualified Certificates.
- Requirements for critical extensions.
2.1 Properties
A Qualified Certificate as defined in this standard is assumed to have the
following properties:
- Issued by a CA that makes a public statement that the certificate serves
the purpose of a Qualified Certificate, as discussed in section 2.3
- Indicate a certificate policy consistent with liabilities, practices and
procedures undertaken by the CA, as discussed in 2.4
- Be issued to a natural person (living human being).
- Contain an unmistakable name of the subject or an unmistakable
pseudonym identified as such.
- Exclusively indicates non-repudiation key usage for the certified public
key.
- Fully complies with the certificate profile defined in RFCxxxx
2.2 Legal framework
The evidence value and thereby the expected legal status of a digital
signature is highly dependent on the quality of the signers certificate as
well as the properties of the signature service used to create and verify
the signature.
Current national laws in general covers the area of agreements and
signatures, regardless of whether they appear in a physical or digital
context. There is however a great uncertainty how traditional law will be
applied to the relatively new digital techniques. According to the UNCITRAL
Model law on Electronic Commerce, a key factor for the legal status of
digital signatures is whether they are used in a context where they are to
be considered "functionally equivalent" to handwritten signatures.
A common characteristic for emerging legal frameworks regarding digital
signatures is thus to identify some minimum requirements on certificates
which are qualified to support digital signatures in a context which is
considered to be "functional equivalent" with handwritten signatures. These
requirements may emphasize different aspects of certificate issuance and
maintenance such as the routines for identifying the key holder, revocation
routines, liabilities of key holders and CA:s, accreditation of CA:s and
information content in certificates.
2.3 Statement of purpose
For a certificate to serve the purpose of supporting digital signatures
that are legally compatible with handwritten signatures, it is assumed that
the CA will have to make a public statement which states this purpose,
presumably published in a CPS.
The shape of this statement may depend on the governing law under which the
CA is operating but in general it is assumed that the CA at least will have
to include in its statement that the certificate:
- is aimed to be used for verification of digital signatures in a context
where they are considered "functional equivalent" to hand written
signatures and;
- meets all requirements, according to the law under which the CA is
operating, necessary to support this "functional equivalence".
The legal effects of this statement will be dependent on the applicable
governing law under which the CA is operating. Within states with no
specific regulations concerning digital signatures, the statement will only
be a declaration of the suitable area of use of the certificate. In states
where regulations are extensive and specific the statement will be a
declaration that the certificate complies with all these regulations.
The function of the statement is thus to assist any concerned entity in
evaluating the risk associated with creating or accepting signatures based
on a particular certificate.
2.4 Policy issues
Certain policy aspects defines the context in which the profile is to be
understood and used. It is however outside the scope of this profile to
specify any policies or legal aspects that will govern services that issues
or utilizes certificates according to this profile.
It is however assumed that the issuing CA will undertake to follow a
publicly available certificate policy which is consistent with its
liabilities, practices and procedures.
3. Certificate and Certificate Extensions Profile
This section defines a profile for Qualified Certificates. The profile is
based on the Internet certificate profile RFCxxxx which in turn is based on
the X.509 version 3 format. For full implementation of this section
implementers are REQUIRED to consult the underlying formats and semantics
defined in RFCxxxx.
ASN.1 definitions relevant for this section are supplied by RFCxxxx except
for definition of SupportedAttributes which is extended in this standard.
Definition of the extended SupportedAttributes and definitions of the added
attribute types are supplied in Appendix B.
3.1 Basic Certificate Fields
3.1.1 Issuer
The issuer field SHALL contain an unmistakable name of the issuer which at
least SHALL identify the organization liable for the certificate. The
unmistakable name of the issuer MUST be obtained by examining the present
values of the following attribute types;
countryName
stateOrProvinceName
organizationName
commonName
Additional attributes MAY be present but they SHALL NOT be necessary to
identify the issuer.
The attributes organizationName and countryName are mandatory. All other
attributes are OPTIONAL with the exception concerning stateOrProvinceName
as stated below.
The geographical information SHALL be consistent with the legal
jurisdiction under which the CA is operating. The geographical information
SHALL be contained in the mandatory countryName attribute value and if
necessary the stateOrProvinceName attribute. If the stateOrProvince
attribute value is relevant for the legal jurisdiction this attribute is
also mandatory.
3.1.2 Subject
The subject field SHALL contain an unmistakable name of the subject.
Subject name includes the complete set of attributes describing the
identity and other related attributes and privileges of the subject. In
this profile the attributes used to form the subject name are divided into
four groups:
- Registered name attributes; holding the value of the subject's officially
registered name.
- Pseudonym attributes; holding the value of the subjects pseudonym.
- Additional identifying attributes; holding the value of attributes which
in combination with the real name attributes or the pseudonym attributes
forms an unmistakable identifier of the subject.
- Specific attributes; holding the value of attributes and privileges of the
subject which has a purpose other than to identify the subject.
If the Pseudonym attribute is used the additional identity attributes
SHOULD be considered to be part of the pseudonym identity, thus not
representing any officially registered identity attributes of the subject.
3.1.2.1 Registered Name Attributes
If the registered name values of a subject are present in a certificate the
surname attribute type SHALL be used to store surnames and the givenName
attribute type SHALL be used to store given names.
The real name of a subject SHALL be represented by names which are
officially registered within the country given by the value of the
mandatory countyName attribute.
If the real name is carried in the givenName and surename attributes the
commonName attribute type SHALL, when present, be used to store the
subjects name in a preferred presentation format commonly used by the
subject. Nicknames and names with spelling other than defined by the
registered name MAY be used.
3.1.2.2 Pseudonym attributes
If a pseudonym name of a subject is present in a certificate the pseudonym
values SHALL be stored using the pseudonym attribute type.
If a pseudonym is carried in the pseudonym attribute the commonName
attribute type SHALL, if present, be used to store the same pseudonym
value. The rationale for this may be to allow applications to access the
subjects name in its preferred presentation format from the commonName
attribute, regardless of whether the subjects name is a pseudonym or a real
name.
3.1.2.3 Additional identifying attributes
The unmistakable identifier of a subject SHALL be obtained by combining the
value of the subjects registered name attributes or pseudonym attributes,
with the values of the following attribute types;
countryName
civicRegistrationNumber
serialNumber
organizationName
organizationalUnitName
postalAddress
Additional attributes MAY be present but they SHALL NOT be necessary to
identify the subject.
The countryName attribute is mandatory. All other attributes are OPTIONAL
as long as the used set of attributes form an unmistakable name.
The countryName attribute value specifies the context in which other
attributes that forms the unmistakable name are to be understood. The
registration number is thus a registration number within that country and
the organization is an organization or a branch office located in that
country. The country attribute does not necessarily mach the subject's
country of citizenship or country of residence, nor does it have to match
the country of issuance.
The civicRegistrationNumber attribute type SHALL, when present, be used to
store an officially registered civic registration number of the subject,
registered within the specified country. This may be a social security
number or other similar type of civic registration number.
The serialNumber attribute type SHALL, when present, be used to store an
identifier of the subject of any type. This MAY be a number appointed by
the CA but it MAY also be used as an alternative to the
civicRegistrationNumber attribute type to store officially registered values.
The organizationName attribute type and the organizationalUnitName
attribute type SHALL, when present, be used to store the name and relevant
information of an organization with which the subject is associated.
The postalAddress attribute type SHALL, when present, be used to store an
address with which the subject is associated. If an organizationName value
also is present then the postalAdress attribute value SHALL be associated
with the specified organization.
3.1.2.4 Specific attributes
This section specifies some specific attributes which may be useful in
Qualified Certificates.
The following attribute types are defined
countryOfCitizenship
countryOfResidence
The countryOfCitizenship attribute type SHALL, when present, be used to
hold the subjects country of citizenship. If the subject is a citizen of
more than one country, they MAY all be included in the certificate using
this attribute type.
The countryOfResidence attribute type SHALL, when present, hold the value
of the country in which the subject is resident.
3.2 Certificate Extensions
3.2.1 Subject Key identifier
The subject key identifier extension SHALL be present but SHALL NOT be
marked critical.
The keyIdentifier is RECOMMENDED to be composed of a four bit type field
with the value 0100 followed by the least significant 60 bits of the SHA-1
hash of the value of the BIT STRING subjectPublicKey.
3.2.2 Certificate Policies
The certificate policies extension SHALL contain at least one certificate
policy which reflects the practices and procedures undertaken by the CA.
The certificate policy extension SHALL be marked critical.
A statement by the issuer stating the purpose of the certificate as
discussed in 2.3 SHOULD be evident through an indicated policy or through
its associated CPS.
3.2.3 Key usage extension
The key usage extension SHALL be present and SHALL exclusively assert the
key usage nonRepudiation (1). No other key usage values are allowed to be
asserted. The key usage extension SHALL be marked critical.
6 References
RFC 2119
RFC xxxx
X.509 version 3
X.520
Appendix A. Security considerations
A.1 Private key policy
The legal value of a digital signature which is validated with a Qualified
Certificate will be highly dependent upon the policy governing the use of
the associated private key. Both the private key holder as well as the
relying party should make sure that the private key is used only with the
consent of the legitimate key holder and only after the key holders
conscious acceptance of the signed message content.
Appendix B. ASN.1 definitions
SupportedAttributes ATTRIBUTE ::= {
name | commonName | surname | givenName | initials |
generationQualifier | dnQualifier | countryName |
localityName | stateOrProvinceName | organizationName |
organizationalUnitName | title | pkcs9email | serialNumber |
pseudonym | civicRegistrationNumber | countryOfCitizenship |
countryOfResidence }
serialNumber ATTRIBUTE
WITH ATTRIBUTE-SYNTAX printableStringSyntax (SIZE(1..ub-serial-number))
::= {attributeType 5}
pseudonym ATTRIBUTE
..... To be defined
civicRegistrationNumber ATTRIBUTE
..... To be defined
countryOfCitizenship ATTRIBUTE
..... To be defined
countryOfResidence ATTRIBUTE
..... To be defined
ub-serial-number INTEGER ::= 64
Appendix C. Author addresses:
Stefan Santesson
Accurata Systemsäkerhet AB
Lotsgatan 27d
216 42 Malmö
Sweden
stefan@accurata.se
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27347 for ietf-pkix-bks; Mon, 26 Oct 1998 14:26:48 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27343 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 14:26:47 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id RAA21353; Mon, 26 Oct 1998 17:28:50 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id RAA13148; Mon, 26 Oct 1998 17:28:48 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A9.007B2344 ; Mon, 26 Oct 1998 17:24:59 -0500
X-Lotus-FromDomain: FDC
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>
cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Al Arsenault" <aarsenault@spyrus.com>, "Stephen Kent" <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566A9.007AD734.00@lnsunr02.firstdata.com>
Date: Mon, 26 Oct 1998 14:27:00 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
PKI tends to represent a binding between some set of attributes and a
public key. Accounts have been used for a long time for attribute binding
in business scenerios.
If the PKI attributes start to take on real-time status requirements for
various business processes ... then a certificate approach will tend to
represent stale status ... and something else must be created to provide
real-time status. If business process completion is dependent on obtaining
that real-time status ... and some of the status has been PKI linked ...
and some of the status is core business process, account-record links ...
then availability is impacted (i.e. attribute status like requiring real
time information on whether a certificate is even still valid).
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA26804 for ietf-pkix-bks; Mon, 26 Oct 1998 13:23:31 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA26800 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 13:23:30 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA10705; Mon, 26 Oct 1998 13:22:48 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA00621; Mon, 26 Oct 1998 13:24:57 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: <Lynn.Wheeler@firstdata.com>
Cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Al Arsenault" <aarsenault@spyrus.com>, "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Mon, 26 Oct 1998 16:25:26 -0500
Message-ID: <00ba01be0127$261f7260$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <882566A9.00690680.00@lnsunr02.firstdata.com>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> there are business operations with account-based systems with >100million
> entries and raw
> data in tens of terabytes. for business process that have to access the
> account record to complete the transaction, splitting responsibility for
> the transaction between an account infrastructure and a PKI infrastructure
> ... doesn't improve availability ... it actually lowers it since now there
> has to be two things that are operational for transaction completion
I would not propose such a split. In fact I think it argues to my point.
Perhaps I have been unclear, the functional division I see as essential
is at a somewhat abstract level. I want to avoid bluring the distinctions
between PKI functions and information distribution functions precisely
so that applications such as Lynn's can be supported.
You want the authentication information from the PKI to directly mesh
into the authorization information supplied by your application.
In other words you do not want to have a directory intermediating
between the PKI and your application.
The question to ask is 'what box (program etc.) have I just added
that can break?'
If there is a per-transaction protocol connection required for PKI
use, it will as you said reduce your availability. But PKI is not
inherently protocol oriented. Nor is it necessarily a 'box to
break'. It would be more accurate to view being 'PKI aware' as being
a quality of systems rather than "THE PKI" being a discrete system
in its own right that can be pointed out in the control room and
thumped with a hammer when it breaks:-)
In other words the PKI should not mandate a 'coherent directory
infrastructure' since the PKI abstraction should not care how the
bits arrived so long as they are properly signed. But what the PKI
suite of standards MUST do is to state how to link to a directory
to obtain such information in the case where one is available.
To permit scale your PKI protocol infrastructure needs to be entirely
integrated within your transaction protocol infrastructure - at least
for that *particular* application. That does not mean however that
there is no 'PKI' component or indeed that every piece of the
infrastructure must be integrated at that level - certificate
issue could well be independent.
A good reason to be ruthless when insisting on separation of function!
It is very easy to propose tweaks that look very good in a limited
context but fail in a larger one.
Phill
[PS OK I'll admit that it is much the same once you get up to Terabytes
of data but I was talking about input bandwidth, not just static
storage :-) I think that you Steve and myself are essentially arguing
the same point though.]
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA25910 for ietf-pkix-bks; Mon, 26 Oct 1998 11:15:33 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA25906 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 11:15:32 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id OAA19143; Mon, 26 Oct 1998 14:17:34 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id OAA04074; Mon, 26 Oct 1998 14:17:32 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A9.0069A034 ; Mon, 26 Oct 1998 14:13:42 -0500
X-Lotus-FromDomain: FDC
To: "Phillip M Hallam-Baker" <pbaker@verisign.com>
cc: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, "Al Arsenault" <aarsenault@spyrus.com>, "Stephen Kent" <kent@bbn.com>, ietf-pkix@imc.org
Message-ID: <882566A9.00690680.00@lnsunr02.firstdata.com>
Date: Mon, 26 Oct 1998 11:16:22 -0800
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
there are business operations with account-based systems with >100million
entries and raw
data in tens of terabytes. for business process that have to access the
account record to complete the transaction, splitting responsibility for
the transaction between an account infrastructure and a PKI infrastructure
... doesn't improve availability ... it actually lowers it since now there
has to be two things that are operational for transaction completion i.e.
availability to complete is the product of the availability of the two
infrastructures; for availability to improve, transaction would have to be
able to complete even if the whole PKI infrastructure or the whole account
infrastructure was not operational (and since the original premise was that
at least the account infrastructure has to be operational for the
transaction to complete; adding a PKI infrastructure can't improve the
availibitliy)
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA24664 for ietf-pkix-bks; Mon, 26 Oct 1998 08:59:04 -0800 (PST)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA24660 for <ietf-pkix@imc.org>; Mon, 26 Oct 1998 08:59:03 -0800 (PST)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id IAA03889; Mon, 26 Oct 1998 08:58:20 -0800 (PST)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA10408; Mon, 26 Oct 1998 09:00:32 -0800 (PST)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, <Lynn.Wheeler@firstdata.com>, "Al Arsenault" <aarsenault@spyrus.com>
Cc: "Stephen Kent" <kent@bbn.com>, <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Mon, 26 Oct 1998 12:01:00 -0500
Message-ID: <009301be0102$34ed93a0$c807a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D49D@DSG1>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> ie. The direction today is to consolidate business information models in
> line with current systems be it "internal" for Staff and "external"
> Customers with X.500 directory systems ....
I disagree.
The idea that there is one 'direction' that is appropriate for the
market as a whole is simply ridiculous. There are directions that
will be more appropriate for some applications than others.
There are many organizations in which the deployment of a PKI will
never happen if the precondition is the deployment of a coherent
directory strategy. The 'consolidated approach' to information
systems has been tried and the current CIO got where he did by
dismantling it.
As Steve said, been there, done that.
Having built systems which by anyone's definition are 'extreeme'
scale-wise (anyone else here commissioned machines dealing with
6Tb/sec raw data?) the major lesson I have drawn from this
experience is the need to insist on tight compartmentalization
of functionality. The interdependencies between complex
infrastructure must be ruthlessly pruned to the bare minimum.
The 'directory-centric' PKI that Alan is promoting is simply
a further step in a direction that is already causing severe
scaling problems. Directory dependent PKI can only scale as
far as the directory. Where is the global X.500 directory?
A PKI should be able to take advantage of a directory if it is
there (call it directory linkable?) - but collapse in a quivering
heap if the directory has a bad day? - NEVER!
Until someone can show me a directory system with 100 million
users that is deployed the 'directories scale hypothesis' is
unproven in my view.
More seriously however the ability of directories to scale
rests upon a very tightly circumscribed set of duties which
they respond to. After all the difference between a directory
and a database is simply that the transaction coherency
requirements which are costly to implement in conjunction
with replication are not supported by a directory.
In other words a directory might scale to 100 million users,
but not if we start tampering with the assumptions on which
that scalability depends. The scaling of Web servers became
much more difficult once they became stateful.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA29898 for ietf-pkix-bks; Sun, 25 Oct 1998 18:07:32 -0800 (PST)
Received: from mail-ewr-3.pilot.net (mail-ewr-3.pilot.net [206.98.230.17]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA29894 for <ietf-pkix@imc.org>; Sun, 25 Oct 1998 18:07:31 -0800 (PST)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-3.pilot.net (Pilot/8.8.8) with ESMTP id VAA13779; Sun, 25 Oct 1998 21:09:25 -0500 (EST)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id VAA11239; Sun, 25 Oct 1998 21:09:24 -0500 (EST)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A9.000B7D2C ; Sun, 25 Oct 1998 21:05:29 -0500
X-Lotus-FromDomain: FDC
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
cc: Al Arsenault <aarsenault@spyrus.com>, Stephen Kent <kent@bbn.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-ID: <882566A9.000B3A1A.00@lnsunr02.firstdata.com>
Date: Sun, 25 Oct 1998 18:08:24 -0800
Subject: aads & x9.59 (was RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
... X9.59 (built on account authority digital signature model) left
financial industiries retail payments committee and on its way for vote as
the industry payment protocol standard.
drafts of x9.59 standard are at ansi-epay@lists.commerce.net mailing list
archive (also my presentation at NISSC a couple weeks ago). url for the
archive and other information on x9.59 and aads is on my personal web site:
http://www.garlic.com/~lynn/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA26267 for ietf-pkix-bks; Sun, 25 Oct 1998 15:43:29 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA26248 for <ietf-pkix@imc.org>; Sun, 25 Oct 1998 15:43:06 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW33Z1>; Mon, 26 Oct 1998 10:40:28 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D49D@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Lynn.Wheeler@firstdata.com'" <Lynn.Wheeler@firstdata.com>, Al Arsenault <aarsenault@spyrus.com>
Cc: Stephen Kent <kent@bbn.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Mon, 26 Oct 1998 10:40:25 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Fantastic... this one has got my vote.
ie. The direction today is to consolidate business information models in
line with current systems be it "internal" for Staff and "external"
Customers with X.500 directory systems (distributed object oriented,
protected, name base transactions, etc) and then apply the security
paradigms necessary to protect a) internal services and; b) customer
authorisation on to the busines's systems used for service delivery.
Importantly and in line with business expansion through customer and
other organisation acquisition strategies - and in line with dealing
with the dynamics of such. It is better to consolidate the information
model (via directories), apply a business strategy re staff and
customers and then apply the security regimes in line with cost, risk
and trust and the business.
I think that trying to shoehorn a PKI onto a company without a directory
system is hard work. In fact very hard work. Simply because there is not
a consolidated information system, no consolidated approach to services
or no consolidated approach to the staff or customers - re the
application of 509.
As said in previous postings, the theory of CAs and 509 has a place.
Buts its application will be (eg.) a telco giving a customer a phone on
which the telco can verify the phone and what services are afforded to
that phone (or attched smartcard).. ie. there is no third party
verification here, just millions of very fast verification actions - via
very large distributed directory services that have directory enabled
validation functions.
Just thoughts - regards alan
PS should we change the subject line?
> -----Original Message-----
> From: Lynn.Wheeler@firstdata.com [SMTP:Lynn.Wheeler@firstdata.com]
> Sent: Saturday, 24 October 1998 3:45
> To: Al Arsenault
> Cc: Stephen Kent; 'ietf-pkix@imc.org '
> Subject: Re: A different architecture? (was Re: certificate path
> services [ was RE: NEW Data type for certificate selection ? ])
>
> Many of the infrastructures involving authorization ... include many
> factors in addition to strong authentication, some real-time and some
> not.
> Accont-based infrastructures have been a part of business
> infrastructures
> for some time to bind together the necessary information necessary to
> support authorization. The accont authority digital signature model
> attempts to integrate public key registration and digital signature
> authentication into the core business process ... as opposed to
> working on
> ways of figuring out what pieces might be exportable to a certificate,
> then
> realizing that there are real-time requirements ... which means
> real-time
> contact of the CA which is maintaining various critical information.
>
> As the number of attributes are exported into certificates increases
> ...
> and the real-time status of those attributes are required to be
> maintained
> at the CA for authorization ... a CA would eventually begin to migrate
> to
> becoming an accont authority. The current main distinction of a CA is
> that
> it is maybe 20-30% handling cryptography for certificates and 70-80%
> account management. As number of attributes and real-time status
> requirements increase ... the role of cryptography in the CA becomes
> smaller and smaller ... and the account management starts to grow to
> 95+%.
>
> From the financial infrastructure standpoint ... once past toy pilot
> stage,
> it is much more cost effective to start with the most robust
> account-management infrastructure in existance today and retrofit the
> 1-2%
> cryptography necessary to support digital signature authentication ...
> than
> it is to try and upgrade CAs into business-critical, industrial
> strength
> account management support.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19319 for ietf-pkix-bks; Sun, 25 Oct 1998 13:59:43 -0800 (PST)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19315 for <ietf-pkix@imc.org>; Sun, 25 Oct 1998 13:59:40 -0800 (PST)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <VTDW33YN>; Mon, 26 Oct 1998 08:57:01 +1100
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D49C@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Stephen Kent'" <kent@bbn.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 26 Oct 1998 08:56:57 +1100
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Stephen, naturally a directory cannot develop key sets, but many of the
customised database being promoted by CAs should be supported by
directory services - otherwise its a proprietary solution with all the
issues of limited scaling all built in. Plus the fact that directories
provide a uniform authentication and access control regime , and
distribution, makes life much mor sensible for those deploying CAs.
As for verification, the engineering approach with CAs re CRLs and
complex clients, etc, etc and domain agile requirements just means that
a wide scale, distributed infrastructure, lightweight client, domain
agile device should be taken.
I accept that single domain, complex clients and bespoke validation
paths may server highly trusted or dedicated enclaves, but there are
other CA areas that need more of an operational and service based
approach.
Adding validation supporting matching rules to directories and/or adding
directory enabled cert validation processes strikes me as the way to go.
I just cannot see how thin, domain agile client software and the system
scaling issues can be dealt with any other way.
But I am open to ideas.
regards alan
> -----Original Message-----
> From: Stephen Kent [SMTP:kent@bbn.com]
> Sent: Tuesday, 20 October 1998 9:15
> To: Alan Lloyd
> Cc: ietf-pkix@imc.org
> Subject: RE: NEW Data type for certificate selection ?
>
> Alan,
>
> I can appreciate the directory perspective of "CA-ness" but I don't
> think
> that captures all of the issues being raised here. CAs exist
> independent
> of directories, so many aspects of a CA may not be captured by by a
> purely
> directory-centric view. Still, to the extent that folks look to
> directories to help with cert selection, it's good to keep in mind
> what
> features a directory can offer to help in addressing this problem.
>
> steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06958 for ietf-pkix-bks; Fri, 23 Oct 1998 10:45:14 -0700 (PDT)
Received: from mail-ewr-2.pilot.net (mail-ewr-2.pilot.net [206.98.230.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06954 for <ietf-pkix@imc.org>; Fri, 23 Oct 1998 10:45:13 -0700 (PDT)
From: Lynn.Wheeler@firstdata.com
Received: from mailgw.FirstData.com ([204.48.27.166]) by mail-ewr-2.pilot.net (Pilot/8.8.8) with ESMTP id NAA02194; Fri, 23 Oct 1998 13:46:55 -0400 (EDT)
Received: from lnsunr02.firstdata.com (lnsunr02.firstdata.com [192.168.247.16]) by mailgw.FirstData.com with SMTP id NAA06231; Fri, 23 Oct 1998 13:46:47 -0400 (EDT)
Received: by lnsunr02.firstdata.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 852566A6.00614980 ; Fri, 23 Oct 1998 13:42:38 -0400
X-Lotus-FromDomain: FDC
To: Al Arsenault <aarsenault@spyrus.com>
cc: Stephen Kent <kent@bbn.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Message-ID: <882566A6.00618318.00@lnsunr02.firstdata.com>
Date: Fri, 23 Oct 1998 10:45:05 -0700
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Many of the infrastructures involving authorization ... include many
factors in addition to strong authentication, some real-time and some not.
Accont-based infrastructures have been a part of business infrastructures
for some time to bind together the necessary information necessary to
support authorization. The accont authority digital signature model
attempts to integrate public key registration and digital signature
authentication into the core business process ... as opposed to working on
ways of figuring out what pieces might be exportable to a certificate, then
realizing that there are real-time requirements ... which means real-time
contact of the CA which is maintaining various critical information.
As the number of attributes are exported into certificates increases ...
and the real-time status of those attributes are required to be maintained
at the CA for authorization ... a CA would eventually begin to migrate to
becoming an accont authority. The current main distinction of a CA is that
it is maybe 20-30% handling cryptography for certificates and 70-80%
account management. As number of attributes and real-time status
requirements increase ... the role of cryptography in the CA becomes
smaller and smaller ... and the account management starts to grow to 95+%.
>From the financial infrastructure standpoint ... once past toy pilot stage,
it is much more cost effective to start with the most robust
account-management infrastructure in existance today and retrofit the 1-2%
cryptography necessary to support digital signature authentication ... than
it is to try and upgrade CAs into business-critical, industrial strength
account management support.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA05824 for ietf-pkix-bks; Fri, 23 Oct 1998 07:53:21 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA05820 for <ietf-pkix@imc.org>; Fri, 23 Oct 1998 07:53:20 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id HAA06571; Fri, 23 Oct 1998 07:54:32 -0700 (PDT)
Message-Id: <3.0.6.32.19981023105001.00920e50@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Fri, 23 Oct 1998 10:50:01 -0400
To: Stephen Kent <kent@bbn.com>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
In-Reply-To: <v04011706b253c410d825@[128.33.238.49]>
References: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com> <3627C5B7.2E7800AE@bull.net> <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Steve,
While I agree with many of your points, I think I disagree with your
conclusion.
From the standpoint of PKIX, the question is whether or not somebody
develops a full protocol for "dumb client talking to validation server"
communication, which would be a generalization of the OCSP and DCS
protocols introduced to this point. That's the only thing we could do that
fits within the IETF's bailiwick; other architectural issues I think belong
with some other group (although I'm not sure which one). I'm not willing
to push that protocol right now (or maybe ever), but I was trying find out
whether somebody is planning on introducing it in the future (Michael?
Carlisle? Anybody? :-), since we seem to be heading there one step at a time.
However, I do think that the type of architecture I described has some
applicabiity in the PKI world. Not everywhere, to be sure, but in some
places. What I was trying to do was find out whether I'm out in left field
(again :-) with that belief, or there are some others who are looking in
that direction. There's an issue with exactly how much functionality goes
in the end-entity, but I think that there's definitely a place for a
validation server.
Now, some specific comments:
At 02:51 PM 10/21/98 -0400, Stephen Kent wrote:
>Al,
>
>First I just wanted to point out that your credit card example isn't quite
>complete. In principle, the merchant makes the authorization request to
>the issuing bank (though not directly), equivalent to asking the issuing CA
>about the status of a cert. This is necessary because the request is not
>really authentication, which could be statically validated, but an
>authorization check, which depends on the current credit limit for the
>account, which is know only by the issuing bank.
>
AWA: are PKIs for authentication only, or are they also useful to support
authorization checks? I've always believed that PKIs can be used to
support authorization checks, although this is clearly a much harder
problem than mere authentication.
>Now, in fact, intermediaries have become part of this scheme, and they will
>confer authorization codes, even though they don't have access to all the
>necessary credit data. These "factors" take a piece of the action for this
>service, and are liable for the transaction cost as a result. It is not at
>all clear that this later model is appropriate for the PKI environment, for
>other than financial transactions. For one thing, it may be hard to attach
>a price to many non-financial transactions, which makes it difficult for a
>third party to accept liability. Also, if you look at the CPS for most
>public CAs, they really try to avoid all liability, or limit it
>substantially, which calls into question the real utility of folks who
>would perform this as a public service.
>
AWA: I agree with you on this. It is unfortunate that many of the
"intermediaries" (and a lot of the "public CAs") that exist in the PKI
world today charge a fee for their service but don't really provide
anything of value. I have enough confidence in the marketplace, though, to
believe (or at least hope) that they will either start providing a useful
service or disappear soon enough. (I for one refuse to deal with any
public CAs - or private ones, for that matter - that I believe don't
provide value. If they won't accept liability for their actions, then I'm
stuck with the consequences. If I'm stuck with the consequences, I'm just
going to do the work myself, and the heck with them.) However, I don't
believe that this invalidates the entire model of "validation servers",
particularly when those servers are the CAs themselves.
>If one thinks about the model in a more local context, some of these issues
>change, but then it also seems less likely that one should expect a high
>availability, high security server to be provided in such contexts.
>
AWA: yes, I think that a lot of the concerns about "intermediaries" and
"public CAs" go away. However, the requirements for "high availability,
high security" will be a function of the specific locale, so it will still
be an issue for some. As an example, an organization processing
very-large-dollar transactions may set up its own PKI, separate from the
rest of the world, but still have very stringent security and availability
requirements for certificate validation, because of the risk involved.
>One of the biggest features of a well designed PKI is that it embodies a
>distributed security model that scales through simple replication of static
>data, a problem we know how to solve. It also has the property that to
>spoof the identity of an end entity, one ought to have to subvert the CA
>that issued the cert to that entity, although sloppy cross certification
>and bad choices for PKI structure can make this situation worse.
>
AWA: agreed, it should be a required property of a PKI that the only ways
to spoof the identity of an end-entity should be (1) defeating the CA (by
taking over the CA's machine & private key; by tricking the CA into issuing
the certificate improperly; etc.); and (2) defeating the end user (by
stealing his private key & the ability to use it without detection).
>The notion of cert validation servers is thus very disturbing. It might be
>quite helpful for a server to collect certs and CRLs on behalf of users,
>caching them locally, to facilitate cert path validation, so long as the
>relying party does the validation. The reduced commiunication overhead
>would be a good side effect, and fancy heuristics for figuring out where to
>look to find the right certs could be centralized. However, once one has a
>candidate cert path, and matching CRLs/OCSP responses, the validation
>process isn't all that bad and is well within the capabilities of cert
>clients.
AWA: in principle, I agree. Sometimes the notion of a 'thin client' is
stretched so much that I think it should really be called a 'dumb
terminal'. Personally, I want the software on my machine to do the cert
path validation. However, there are some folks who seem to be willing to
let the security of their system depend on the actions of a validation
server. If, understanding all of the risks, they really want to do that, I
won't try to stop them.
>
>Pushing validation off to a third party, especially in a public context,
>further complicates the murky "trust model" problems we already face in the
>PKI arena, e.g., because organizations that are authoritative for data are
>failing to act as CAs (or at least RAs). In a country where few people can
>program VCRs, the notion of complex certification hierarchies is
>unrealistic, whether distributed or centralized processing is performed;
>moving cert validation to servers will not fix this problem and it
>certainly has the potential to create significant new vulnerabilities for
>PKI implementations.
>
>My view has been that OCSP is an appropriate mechanism IF the responder is
>operated by the cognizant CA or an explicit delegee thereof. Once one
>moves in the direction of having other than the issuer of a cert vouch for
>its validity, one is heading down the slippery slope you descibed. At the
>bottom of this slope is a swamp, which explains why the slope is slippery,
>i.e., slime has been tracked onto the slope by those trying to escape the
>swamp :-).
>
>Steve
AWA: the model I described can't work unless the validation server is
either the CA or someone explicitly designated by her - otherwise, the
revocation information won't necessarily be correct; the operator of the
validation server won't accept liability and thus there's no value added;
and the risks are increased too much. (When we looked at this, we first
thought of having our CA - which did its assigned job very well - be the
validation server. We weren't sure it was up to the performance
requirements, and we didn't want to risk the security of our CA
implementation by throwing on a bunch of extraneous tasks.)
Re your last sentence: yes this can add significant new vulnerabilities,
but it also provides an opportunity to concentrate the hard problem of
dealing with complex certification hierarchies into a few places, and you
may have a better chance of getting it right. It comes down to how much
trust you're willing to place in the client<-->validation server connections.
Al Arsenault
-- you all know the disclaimer about my opinions by now. As if any
employer would actually admit to sharing them!!
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA06782 for ietf-pkix-bks; Thu, 22 Oct 1998 05:49:42 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA06778 for <ietf-pkix@imc.org>; Thu, 22 Oct 1998 05:49:35 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05X7F>; Thu, 22 Oct 1998 22:46:50 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC08311A@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Stephen Kent '" <kent@bbn.com>
Cc: "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 22 Oct 1998 22:46:48 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line.
snip - disagree with some but:
I don't want to debate LDAP issues; this is a PKI list. Your e-mail
address
suggests that you may work for a company that believes directories are
the
solution to lots of problems. Personally, I don't share that belief,
but
the more central issues is that I'd like us to not confuse the current
definition of directory services, as defined in X.500 and LDAP, with
some
possible future set of cert validation services. About 5 years ago we
developed such a service as part of a DARPA program; it validated certs
that a client could not validate because of algorithm incompatability or
similar constraints. Been there, done that. However, the better use of
the service was to collect certs and CRLs for the client and deliver
them
in a form to simplify client cert path validation. That's not an
unreasonable service, but it's a far cry fro asking a third party to do
the
validation for you.
I have answered some of this in another email.. But why is it that there
is little discussion about trust that includes cert validation services,
stability of software or formal information models for PKIs (not just
object definitions and usage? Or discussion that deals with the fact
that trust is derived from sound scaleable system design and
implementation qualitative features (not theoretical objects in an
abstract system)... and that from the real world perspective we must
operationally deal with multiple CA domains and domain agile devices,
etc, etc from different vendors. In addition the "scale" issues do not
get discussed. ie we seem to ignore the issues re 100s of millions of
users that work under dozens of business domains with many certficates
each....
IMHO the only way of dealing with this validation and scaling issue from
a system and information perspective is through a distributed directory
service THAT provides the User and Service information ON WHICH
certficates are placed. AND that CAs and validation functions are
processes that are supported by such distributed object oriented, name
based transaction systems and infrastructure.
Labeling things as third party in this model is also incorrect, the
validation service which is directory attached can be ownwd and trusted
by the CA itself. ie is a third party "label" applied mabove a
functional label or an operational label or an implementation quality
label?
In not sharing my belief re directories are the distributed information
systems for supporting global services - can you enlighten me on how you
would deploy a multi domain CA infrastructure in todays world that
enable single point of authentication (information) for users, simple
client software, and how one can deal with such information over a
distributed global area for 100s of Ms of Users, etc.
By not putting the correct perspective on directories in support of
distributed information functions like CAs - all one is doing is
building islands of mechanisms.
eg its like developing lots of customised PABXs.
Is "trust" relying that a service works and is globally scaleable (eg.
the phone system) eg. The Internet is slow .. I will ring the ISP on the
phone system because I know that always works.
or is trust some theory about abstract objects placed in an abstract
security policy on a yet to be defined unscaleable implementation.?
just views and regards alan
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA06545 for ietf-pkix-bks; Thu, 22 Oct 1998 04:51:30 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA06541 for <ietf-pkix@imc.org>; Thu, 22 Oct 1998 04:51:10 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05X68>; Thu, 22 Oct 1998 21:48:12 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC083114@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Al Arsenault '" <aarsenault@spyrus.com>, "'Stephen Kent '" <kent@bbn.com>
Cc: "''ietf-pkix@imc.org ' '" <ietf-pkix@imc.org>
Subject: RE: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Thu, 22 Oct 1998 21:48:11 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line. Agree with some of the comments - but like to add.
----------
From: Stephen Kent
To: Al Arsenault
Cc: 'ietf-pkix@imc.org '
Sent: 10/22/98 4:51:41 AM
Subject: Re: A different architecture? (was Re: certificate path
services [ was RE: NEW Data type for certificate selection ? ])
snip
One of the biggest features of a well designed PKI is that it embodies a
distributed security model that scales through simple replication of
static
data, a problem we know how to solve.
Alan: However a major weakness in any system occurs when one replicates
data - particularly when that data forms a linkages to a point of trust
- and in the path there are other objects that may or may not exist (eg
CRLs) that could be placed in these paths in non uniform ways...
EG LDAP - one of the major deficiencies cannot ask for master data from
a CA directory ie. If a CRL has been placed in the master but not yet
propagated to replicas, then a client could consider the cert being
validated - valid if it (without its knowlege - accesses the replica).
(ie. why talk of trust and how one achieves trust in a distributed and
replicated information system and then use a protocol that has so many
untrusted deficiencies???? eg. LDAP.
It also has the property that to
spoof the identity of an end entity, one ought to have to subvert the CA
that issued the cert to that entity, although sloppy cross certification
and bad choices for PKI structure can make this situation worse.
Alan: Bad PKI designs come from weaknesses and complexities in the CA
and the related client information model and service interaction
software - as one adds complexity the components that work with an ill
defined and variable information model, then all things get into a mess.
EG LDAP - no system service model, add and extension here there and
everywhere. Outcome - LDAP is not universal anymore - an operational
mess.
Limited scale systems, complex clients and weak/variable CA information
models is what we have. Its better to have consistency in service and
place trust in the implementation of that service. There is no point in
discussing trust in theoretical Objects and certificates and the
processes that might happen in someones CA or "cert server".
The notion of cert validation servers is thus very disturbing.
Alan:
If a client goes to a CAs directory to get a cert in the path and the
directory provides the wrong one and therefore user to user transaction
is invalidated - then denial of service happens.
Something - somewhere in the system has to be trusted. And in my book
its the implementation that is trusted not theoretical models.
eg. I can build a highy trusted directory system that does cert
matching, has bullet proof access controls, has trusted processes that
generate valid flags from processing CRLs...for the client.
OR I could write sloppy, bug ridden, fragile process that serves no
purpose in terms of trust.
OR I could promote a protocol to a server without any distributed,
directory relevant CA information model and say that solves the problem.
In the above the following observations MUST be made.
Using good directory technology, with sound information services to
support CA functions provide scaleability and measureable trust models.
Using bad anything .. provides no trust
Having a protocol to a server without any notion of the CA function and
the directory support that CAs need or any notion of scaling or how it
deals with multiple CA domains or the complexity of the client, only
generates problems.
IE.
IMHO Talking of trust in the CA/X.509/directory environment without any
reference to implemtation and system design qualitative characteristics
becomes an endless debate - without resolution.
regards alan
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12042 for ietf-pkix-bks; Wed, 21 Oct 1998 14:50:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA12038 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 14:50:58 -0700 (PDT)
Received: from [128.33.238.121] (TC121.BBN.COM [128.33.238.121]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id RAA09883; Wed, 21 Oct 1998 17:52:20 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04011706b253c410d825@[128.33.238.49]>
In-Reply-To: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com>
References: <3627C5B7.2E7800AE@bull.net> <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Date: Wed, 21 Oct 1998 14:51:41 -0400
To: Al Arsenault <aarsenault@spyrus.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al,
First I just wanted to point out that your credit card example isn't quite
complete. In principle, the merchant makes the authorization request to
the issuing bank (though not directly), equivalent to asking the issuing CA
about the status of a cert. This is necessary because the request is not
really authentication, which could be statically validated, but an
authorization check, which depends on the current credit limit for the
account, which is know only by the issuing bank.
Now, in fact, intermediaries have become part of this scheme, and they will
confer authorization codes, even though they don't have access to all the
necessary credit data. These "factors" take a piece of the action for this
service, and are liable for the transaction cost as a result. It is not at
all clear that this later model is appropriate for the PKI environment, for
other than financial transactions. For one thing, it may be hard to attach
a price to many non-financial transactions, which makes it difficult for a
third party to accept liability. Also, if you look at the CPS for most
public CAs, they really try to avoid all liability, or limit it
substantially, which calls into question the real utility of folks who
would perform this as a public service.
If one thinks about the model in a more local context, some of these issues
change, but then it also seems less likely that one should expect a high
availability, high security server to be provided in such contexts.
One of the biggest features of a well designed PKI is that it embodies a
distributed security model that scales through simple replication of static
data, a problem we know how to solve. It also has the property that to
spoof the identity of an end entity, one ought to have to subvert the CA
that issued the cert to that entity, although sloppy cross certification
and bad choices for PKI structure can make this situation worse.
The notion of cert validation servers is thus very disturbing. It might be
quite helpful for a server to collect certs and CRLs on behalf of users,
caching them locally, to facilitate cert path validation, so long as the
relying party does the validation. The reduced commiunication overhead
would be a good side effect, and fancy heuristics for figuring out where to
look to find the right certs could be centralized. However, once one has a
candidate cert path, and matching CRLs/OCSP responses, the validation
process isn't all that bad and is well within the capabilities of cert
clients.
Pushing validation off to a third party, especially in a public context,
further complicates the murky "trust model" problems we already face in the
PKI arena, e.g., because organizations that are authoritative for data are
failing to act as CAs (or at least RAs). In a country where few people can
program VCRs, the notion of complex certification hierarchies is
unrealistic, whether distributed or centralized processing is performed;
moving cert validation to servers will not fix this problem and it
certainly has the potential to create significant new vulnerabilities for
PKI implementations.
My view has been that OCSP is an appropriate mechanism IF the responder is
operated by the cognizant CA or an explicit delegee thereof. Once one
moves in the direction of having other than the issuer of a cert vouch for
its validity, one is heading down the slippery slope you descibed. At the
bottom of this slope is a swamp, which explains why the slope is slippery,
i.e., slime has been tracked onto the slope by those trying to escape the
swamp :-).
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA11974 for ietf-pkix-bks; Wed, 21 Oct 1998 14:43:48 -0700 (PDT)
Received: from mclean-mail.usae.bah.com (mclean-mail.usae.bah.com [156.80.5.109]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA11970 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 14:43:47 -0700 (PDT)
Received: from bah.com ([156.80.128.196]) by mclean-mail.usae.bah.com (Netscape Messaging Server 3.01) with ESMTP id AAA24884 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 17:45:12 -0400
Message-ID: <362E55ED.2289C800@bah.com>
Date: Wed, 21 Oct 1998 17:45:17 -0400
From: "Simonetti David" <simonetti_david@bah.com>
Organization: BAH
X-Mailer: Mozilla 4.04 [en] (Win95; I)
MIME-Version: 1.0
To: IETF-PKIX <ietf-pkix@imc.org>
Subject: Announcing ISO CD-15782-1 Review and Ballot
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dear PKIX,
ISO CD-15782-1, Banking-Certificate Management Part 1: Public Key
Certificates, has recently been distributed for international review and
ballot. This draft standard had previously been released for ballot and
received sufficient approvals. However, due to the number of comments
incorporated, the working group has decided to send the document through
the ballot process once again. If you are interested in this standard,
please contact your national standards body. In the United States, this
group is ANSI Accredited Standards Committee X9.F.1.
An American national review and discussion session will be held at the
National Institute for Standards and Technology in Gaithersburg,
Maryland, on Friday, November 6. The session will be held at NIST
North, room 618, starting at 0900. Directions can be found at
<http://csrc.nist.gov/pki/twg/twg1998.htm#nist>. Those interested are
welcome to attend.
Copies of the draft standard may only be distributed to members of the
respective national standards bodies. However, copies will be available
at the review session held at NIST.
--
David Simonetti, Booz·Allen & Hamilton Inc.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA08902 for ietf-pkix-bks; Wed, 21 Oct 1998 08:34:18 -0700 (PDT)
Received: from slack.lne.com (NoBody@slack.lne.com [140.174.94.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA08898 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 08:34:16 -0700 (PDT)
Received: (from ericm@localhost) by slack.lne.com (8.9.0/8.9.0) id IAA25076; Wed, 21 Oct 1998 08:35:20 -0700
From: Eric Murray <ericm@lne.com>
Message-Id: <199810211535.IAA25076@slack.lne.com>
Subject: Re: A different architecture? (was Re: certificate path services
To: aarsenault@spyrus.com (Al Arsenault)
Date: Wed, 21 Oct 1998 08:35:19 -0700 (PDT)
Cc: Denis.Pinkas@bull.net, sgupta@cygnacom.com, Alan.Lloyd@OpenDirectory.com.au, ietf-pkix@imc.org
In-Reply-To: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com> from "Al Arsenault" at Oct 20, 98 09:29:30 am
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al Arsenault writes:
>
>
> The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
> DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
> an architecture that I've looked at in the past. I'm curious as to
> whether that's where some people really want to go.
>
> The architecture in question is modeled after what many people believe is
> the way the credit card system works. That is, I go into a store to
> purchase an item. I hand my credit card to the clerk to pay for the item.
> The clerk contacts an account authority, and asks the question "is this
> user (i.e., the credit card number) valid for this transaction (giving the
> dollar amount in question)?". The system responds with one of a variety of
> possible answers:
[deletia]
The account authority model is very useful for systems which
require authentication of messages from end-entity by a central
authority. As you point out, it's not as useful for key exchange
between end entities. But there are a lot of systems where
there isn't a key exchange but is authentication of end entities
by an authority.
The ANSI X9.59 electronic payment protocol (from the X9A10 working group)
is based on the account authority model. It integrates well with
systems like credit-card processing.
X9.59's model for account-authority authentication is based on
Lynn Wheeler's AADS work. See http://www.garlic.com/~lynn/.
--
Eric Murray N*Able Technologies www.nabletech.com
(email: ericm at the sites lne.com or nabletech.com) PGP keyid:E03F65E5
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA04942 for ietf-pkix-bks; Wed, 21 Oct 1998 02:37:06 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA04938; Wed, 21 Oct 1998 02:36:59 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id LAA19932; Wed, 21 Oct 1998 11:37:20 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA14484; Wed, 21 Oct 1998 11:39:38 +0200 (DFT)
Message-ID: <362E2A67.B916557B@bull.net>
Date: Wed, 21 Oct 1998 11:39:38 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: IETF-PXIX <ietf-pkix@imc.org>, S-MIME / IETF <ietf-smime@imc.org>
Subject: Cert. identifiers in OCSP and ESS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Certificate identifiers are used both the OCSP specification from the PKIX WG
and in the ESS specification from the S/MIME WG. This is the reason why this
mail is posted to both the S/MIME and PKIX WGs.
A recent proposal made by Jim Schaad has been to change the "CertID
"definition from the S/MIME WG to "ESSCertID" because we had two different
ASN1 definitions for the same name. :-(
I would prefer to call the later "SigningCert", since the Certificates are
signed attributes and thus remove the ESS co-notation. We would then have :
SigningCertificates ::= SEQUENCE {
certs SEQUENCE OF SigningCert,
(stuff deleted)
This is (only) a naming issue. :-)
A much more important concern is how to use the CertID content from ESS and
the CertID from the OCSP protocol altogether.
The current definition of CertID in ESS-08 is as follows:
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF CertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
CertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
The current definition of CertID in OCSP-07 is as follows:
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING, -- Hash of Issuer's public key
serialNumber CertificateSerialNumber }
One of the problems is that the current definition places limitations when
using both specifications.
A receiver of a signed message will be able to extract directly the
issuerSerial from the received message either from the CertID field or from
the issuerAndSerialNumber field contained in SignerInfo. It would be nice if
he would then immediately be able to ask to an OCSP server whether the
certificate is revoked or not. However, it can't.
He needs to obtain first the right issuerKeyHash, i.e. the hash of the
issuer's public key. For this he needs to fetch the certificate BEFORE making
the OCSP request AND to get the issuer public key. This can take long.
The goal is to be able to perform the operations in parallel or in whatever
order.
For this, what should be changed ? In which specification ?
I could end up the mail here. However, I will attempt to make a proposal which
is certainly not the single way to solve this issue. So other proposals
reaching the same goal are welcomed.
The idea is to optimise the cases where there is no name collisions for the
DNs of the CAs, without sacrifying any security. In case of name collision,
i.e. the same OCSP server supports two CAs with the same DN - which will be
very scarce in practice - performance will be much lower.
Let us redefine CertID in OCSP-07 is as follows:
CertID ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier,
issuerNameHash OCTET STRING, -- Hash of Issuer's DN
issuerKeyHash OCTET STRING OPTIONAL,
-- Hash of Issuer's public key
serialNumber CertificateSerialNumber }
i.e. let us make the issuerKeyHash OPTIONAL in the OCSP request. This means
that the receiver can immediately construct its OCSP request and send it to
the OCSP server while fetching after or in parallel the certificate and the
issuer public key.
In order to make sure that the right issuer was indeed selected, the OCSP
server will have to include in its response the issuerKeyHash. Thus "after the
fact", i.e. after fetching the certificate and the issuer public key, the
receiver can check that he got the right response from the OCSP server. If
not, he will have to query again the OCSP server using the issuerKeyHash in
its request.
I would thus propose that we modify OCSP to make issuerKeyHash optional and
this we add some text to explain that issuerKeyHash is optional for the
request but mandatory for the response.
I would also propose that we use the term "SigningCert" in the ESS document.
Denis
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA03868 for ietf-pkix-bks; Wed, 21 Oct 1998 02:10:18 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA03861 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 02:10:15 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Wed, 21 Oct 1998 10:10:56 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: versed@elvis.ru (Pavel Krylov)
cc: ietf-pkix@imc.org
Subject: Re: ASN1 question
In-reply-to: Your message of "Wed, 21 Oct 1998 11:40:22 +0400." <199810210740.LAA28045@relay2.elvis.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 21 Oct 1998 10:10:47 +0100
Message-ID: <28208.908961047@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Pavel Krylov writes:
>I have a question about INTEGER encoding in <draft-ietf-pkix-ipki-part1
-10.txt
>>.
>If You saw in <D.3 End-Entity Certificate Using RSA> section of this
draft,
>You saw RSAPublicKey encoded as BIT STRING. Please, see in inner
structure
>of RSAPublicKey. By specification it is:
>
> RSAPublicKey ::= SEQUENCE {
> modulus INTEGER, -- n
> publicExponent INTEGER -- e -- }
>
>In draft it looked so:
>
>0319 03 6b 107: . . . BIT STRING
> : 00 (0 unused bits)
> : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
^^ this zero
> : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
> : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
> : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
> : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
> : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
> : 56 15 c6 1c 8b 02 03 01 00 01
>
>Question: Why is there 0 ( zero ) in first INTEGER ( -- n )? By ASN1 if
>encoded integer value consists of more then one octet string, than
first
>octet shall not be 0xff or 0x00.
Pavel,
That zero is there to ensure that the INTEGER n is treated as a positive
number; note that the top bit of the next octet ('be') is set. If this
'00' were not present, the value would be regarded as negative.
You have not quoted the encoding rules correctly; it's the first NINE
bits (first OCTET and bit 8 of the next OCTET) which must not be
all 0 or 1. The above encoding conforms to this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA28443 for ietf-pkix-bks; Wed, 21 Oct 1998 00:39:08 -0700 (PDT)
Received: from relay2.elvis.ru (ss10.elvis.ru [194.190.192.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA28424 for <ietf-pkix@imc.org>; Wed, 21 Oct 1998 00:38:56 -0700 (PDT)
Received: by relay2.elvis.ru (8.8.5/1.30) id LAA28045; Wed, 21 Oct 1998 11:40:22 +0400 (MSK DST)
Date: Wed, 21 Oct 1998 11:40:22 +0400 (MSK DST)
From: versed@elvis.ru (Pavel Krylov)
Message-Id: <199810210740.LAA28045@relay2.elvis.ru>
To: ietf-pkix@imc.org
Subject: ASN1 question
X-Sun-Charset: US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi All!
I have a question about INTEGER encoding in <draft-ietf-pkix-ipki-part1-10.txt>.
If You saw in <D.3 End-Entity Certificate Using RSA> section of this draft,
You saw RSAPublicKey encoded as BIT STRING. Please, see in inner structure
of RSAPublicKey. By specification it is:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e -- }
In draft it looked so:
0319 03 6b 107: . . . BIT STRING
: 00 (0 unused bits)
: 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
: b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
: 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
: 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
: 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
: 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
: 56 15 c6 1c 8b 02 03 01 00 01
Question: Why is there 0 ( zero ) in first INTEGER ( -- n )? By ASN1 if
encoded integer value consists of more then one octet string, than first
octet shall not be 0xff or 0x00.
___________________________________________________
Krylov Pavel Pavel.Krylov@trustworks.com
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA07704 for ietf-pkix-bks; Tue, 20 Oct 1998 18:56:53 -0700 (PDT)
Received: from gracilis.interspect.com (gracilis.interspect.com [199.175.156.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id SAA07700 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 18:56:51 -0700 (PDT)
Received: from andrew-ii.gt.ca (161.255.16.172.admin.gt.ca [172.16.255.161]) by gracilis.interspect.com (8.6.10/8.6.9) with SMTP id SAA07604; Tue, 20 Oct 1998 18:45:36 -0700
Message-ID: <001d01bdfc96$99501c20$a1ff10ac@andrew-ii.gt.ca>
From: "Andrew Csinger" <csinger@interspect.com>
To: "Denis Pinkas" <Denis.Pinkas@bull.net>, "Sarbari Gupta" <sgupta@cygnacom.com>, "Al Arsenault" <aarsenault@spyrus.com>
Cc: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, <ietf-pkix@imc.org>
Subject: Re: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Date: Tue, 20 Oct 1998 18:59:37 -0700
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 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
This is more or less what I've been trying to sell for years :) In other
words, I think it's the right model, but so far, the market hasn't been
aggressively demanding the concept. It's an extremely simple model that
lends itself to a wide range of applications, from basic web access control
to a variety of on-line payment protocols. You might call it Connected-Mode
PKI (I do).
The strongest counter-argument has always been the contention that it would
be difficult, if not impossible, to guarantee reliability, availability and
performance. The best defense to this counter-argument is still the
"dial-tone argument," which is why I now work at a telecommunications
company :) Our approach involves a replicated, geographically distributed
directory server built for vendor-independent PKI. Available for sale or
lease :)
If PKIX were to head off on this road, I would be happy to help pave it.
Andrew
--------------------------------------------------------------
Andrew Csinger, VP Electronic Commerce GT Group Telecom
840 Howe Street, 3rd Floor tel: 604-688-3010
Vancouver, B.C., Canada V6Z 2L2 fax: 604-688-3011
http://www.gt.ca email: csinger@gt.ca
**** Information is Power. Plug in. ****
--------------------------------------------------------------
-----Original Message-----
From: Al Arsenault <aarsenault@spyrus.com>
To: Denis Pinkas <Denis.Pinkas@bull.net>; Sarbari Gupta
<sgupta@cygnacom.com>
Cc: 'Alan Lloyd' <Alan.Lloyd@OpenDirectory.com.au>; 'ietf-pkix@imc.org '
<ietf-pkix@imc.org>
Date: October 20, 1998 6:50 AM
Subject: A different architecture? (was Re: certificate path services [ was
RE: NEW Data type for certificate selection ? ])
>
>The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
>DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
>an architecture that I've looked at in the past. I'm curious as to
>whether that's where some people really want to go.
>
>The architecture in question is modeled after what many people believe is
>the way the credit card system works. That is, I go into a store to
>purchase an item. I hand my credit card to the clerk to pay for the item.
>The clerk contacts an account authority, and asks the question "is this
>user (i.e., the credit card number) valid for this transaction (giving the
>dollar amount in question)?". The system responds with one of a variety of
>possible answers:
>
> - reject the transaction because:
> - the credit card has been reported stolen (i.e., the "private key" has
>been compromised)
> - the credit card has expired
> - this transaction exceeds the available credit on the card
> - ...
>
> - accept the transaction; here's the authorization code.
>
>(Obviously, this is generally done electronically - the clerk or the
>customer swipes the card and the data are fed to a computer which provides
>the answer; the human clerk doesn't talk to another human unless there's
>some problem.)
>
>The clerk's next action depends on the account authority's response: write
>down the authorization code if approved; return the card with explanation
>if expired; keep card and call police if stolen; etc.
>
>
>To replicate this in the world of certificates, one would do something
like:
>
> - establish an account authority or transaction server to do all of the
>certificate path construction and validation; policy checking; etc. (You'd
>probably have more than one, depending on overall system load, reliability
>requirements, etc.)
> - configure each end-entity with the name and certificate of the
>transaction server to trust (again, you'd probably configure each one with
>a primary and one or more back-ups, but that could be worked on a
>case-by-case basis).
> - when an end-entity receives something to be validated (e.g., a signed
>S/MIME message; a request for SSL session set-up) it sends that information
>to the transaction server; basically, it's asking "right now, to the best
>of your knowledge, is this valid for what the sender wants to do?"
> - the transaction server receives the request, crunches through all of the
>signature validation, cert path construction and validation, policy
>processing, etc., and determines an answer which it sends to the requesting
>end-entity
> - the end-entity accepts or rejects the initial request based on the
>response it gets.
>
>We actually looked at this for a while in the MISSI effort (well, at least
>some of us did :-). There were a number of potential customers who wanted
>something like this because of some perceived advantages:
>
> 1 - it seems to fit the 'thin client' model that was all the rage a year
>or so ago. All the end-entity has to know is how to contact a transaction
>server; it doesn't have to have all of the cert path construction and
>validation logic. This makes the software with the most copies deployed be
>as small, simple, and cheap as possible.
>
> 2 - it doesn't force any user interactions at the end-entity. At worst,
>the user is told "accepted; authorization code = .." or "rejected:
reason...".
>
> 3 - it results in all of the information needed for non-repudiation (e.g.,
>certificates, cert paths, CRLs, etc.) being stored at one or a few central
>places, rather than having it scattered at various workstations all over
>the net. Further, since it was envisioned that the transaction servers
>would be high-end machines located in data centers, it would be easier to
>establish the procedures and processes necessary to protect and store the
>non-repudiation information.
>
> 4 - it seems to provide the most timely revocation notification of the
>system designs presented so far. Particularly if the transaction server is
>also the CA who issued the certificate in the first place, revocation
>notification can be distributed almost instantly upon the revocation
>decision being made.
>
>On the other hand, it does have a number of potential "issues" (to be
>polite). Some of them were:
>
> 1 - as Steve Kent has pointed out, it makes the transaction server an
>attractive target. I can derive great benefit from taking it over, and I
>can probably derive some benefit just from crashing the thing. (Military
>folk tend not to like designs with single points of failure; it's too
>darned easy to just drop a bomb on the thing.)As Denis Pinkas pointed out,
>you can alleviate some of this, but there's a cost attached.
>
> 2 - without worrying about attacks, it's likely that the transaction
>server will have major reliability & communications bandwidth requirements,
>especially if we're dealing with approvals required prior to the
>establishment of real-time connections. This will cause it to be a very
>expensive suite of hardware & software, compared with the rest of the
>system.
>
> 3 - it's relatively straightforward to handle signed messages. Encryption
>is worse, though - if you want the transaction server to handle encrypting
>and decrypting of data, you've turned your environment into something that
>looks a lot like what's described in Dean & Ottaway's
><draft-ietf-smime-domsec-00.txt>. You lose the ability to have data
>encrypted from end-user to end-user; you can only encrypt it from end-user
>to server or even server to server. Then, the data pass in the clear
>between end-user and server, or have to be separately encrypted for that
>link. That's not necessarily bad, but it may not be something that
>everybody wants to do. (If you want to have the transaction server handle
>signature but not encryption, you lose much of the benefit, because the
>end-entity will have to do all of the certificate path construction and
>validation just to encrypt & decrpyt data.)
>
>
>None of these "issues" is necessarily unsolvable in general, but they may
>be too hard in any particular environment, and taken together they can
>cause a lot of pain. (Ultimately, we didn't implement anything like this,
>because it was going to take a lot of time and money to solve the "issues",
>and it wasn't clear that all of them were readily solvable given our
>particular constraints.)
>
>Now, the reason for this long-winded message: with OCSP, PKIX took the
>first step toward this architecture, by setting up a server to basically
>check CRLs for the end-user. With DCS, it looks like we're taking the
>second step, with the cs and cpkc transaction types. So: will PKIX
>eventually move toward supporting the full architecture? If that's
>anybody's goal, should we be starting to look now at the entire set of
>things necessary to get there, rather than taking it piece by piece?
>
>Or, is it the case that nobody thinks that the architecture I described is
>ever in the plans, and all we're looking at is incremental service
>enhancements?
>
> Al Arsenault
>
>- my opinions are my own, yada, yada, yada
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA21237 for ietf-pkix-bks; Tue, 20 Oct 1998 09:06:25 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA21233 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 09:06:23 -0700 (PDT)
Received: (qmail 32407 invoked from network); 20 Oct 1998 16:07:54 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 20 Oct 1998 16:07:54 -0000
Received: (qmail 1279 invoked from network); 20 Oct 1998 16:07:53 -0000
Received: from swilson.eris.dera.gov.uk (HELO eris.dera.gov.uk) (128.98.10.29) by mail-relay.eris.dera.gov.uk with SMTP; 20 Oct 1998 16:07:53 -0000
Message-ID: <362CB5B1.63F51523@eris.dera.gov.uk>
Date: Tue, 20 Oct 1998 17:09:21 +0100
From: "Stephen P. Wilson" <s.wilson@eris.dera.gov.uk>
Organization: Defence Evaluation & Research Agency.
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Al Arsenault <aarsenault@spyrus.com>
CC: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: A different architecture? (was Re: certificate path services[ was RE: NEW Data type for certificate selection ? ])
References: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER> <3.0.6.32.19981020092930.0091b340@mail.spyrus.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Al Arsenault wrote:
>
> 3 - it's relatively straightforward to handle signed messages.
> Encryption is worse, though - if you want the transaction server to
> handle encrypting and decrypting of data, you've turned your
> environment into something that looks a lot like what's described in
> Dean & Ottaway's <draft-ietf-smime-domsec-00.txt>. You lose the
> ability to have data encrypted from end-user to end-user; you can only
> encrypt it from end-user to server or even server to server.
Just to clarify - the domsec draft doesn't prevent end to end user
encryption.
Steve.
--
Stephen Wilson. BSc (hons), AMIEE. S.Wilson@eris.dera.gov.uk
The views and statements contained in this message are entirely those
of the author and should not be considered as the opinion or policy
of any other person or organisation.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA20090 for ietf-pkix-bks; Tue, 20 Oct 1998 06:33:55 -0700 (PDT)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA20086 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 06:33:54 -0700 (PDT)
Received: from intern_pc ([209.172.119.112]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id GAA22074; Tue, 20 Oct 1998 06:33:49 -0700 (PDT)
Message-Id: <3.0.6.32.19981020092930.0091b340@mail.spyrus.com>
X-Sender: aarsenault@mail.spyrus.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 20 Oct 1998 09:29:30 -0400
To: Denis Pinkas <Denis.Pinkas@bull.net>, Sarbari Gupta <sgupta@cygnacom.com>
From: Al Arsenault <aarsenault@spyrus.com>
Subject: A different architecture? (was Re: certificate path services [ was RE: NEW Data type for certificate selection ? ])
Cc: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
In-Reply-To: <3627C5B7.2E7800AE@bull.net>
References: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
The recent postings by Sarbari Gupta and Denis Pinkas, along with the draft
DCS protocol <draft-ietf-pkix-dcs-00.txt> seem to be further steps toward
an architecture that I've looked at in the past. I'm curious as to
whether that's where some people really want to go.
The architecture in question is modeled after what many people believe is
the way the credit card system works. That is, I go into a store to
purchase an item. I hand my credit card to the clerk to pay for the item.
The clerk contacts an account authority, and asks the question "is this
user (i.e., the credit card number) valid for this transaction (giving the
dollar amount in question)?". The system responds with one of a variety of
possible answers:
- reject the transaction because:
- the credit card has been reported stolen (i.e., the "private key" has
been compromised)
- the credit card has expired
- this transaction exceeds the available credit on the card
- ...
- accept the transaction; here's the authorization code.
(Obviously, this is generally done electronically - the clerk or the
customer swipes the card and the data are fed to a computer which provides
the answer; the human clerk doesn't talk to another human unless there's
some problem.)
The clerk's next action depends on the account authority's response: write
down the authorization code if approved; return the card with explanation
if expired; keep card and call police if stolen; etc.
To replicate this in the world of certificates, one would do something like:
- establish an account authority or transaction server to do all of the
certificate path construction and validation; policy checking; etc. (You'd
probably have more than one, depending on overall system load, reliability
requirements, etc.)
- configure each end-entity with the name and certificate of the
transaction server to trust (again, you'd probably configure each one with
a primary and one or more back-ups, but that could be worked on a
case-by-case basis).
- when an end-entity receives something to be validated (e.g., a signed
S/MIME message; a request for SSL session set-up) it sends that information
to the transaction server; basically, it's asking "right now, to the best
of your knowledge, is this valid for what the sender wants to do?"
- the transaction server receives the request, crunches through all of the
signature validation, cert path construction and validation, policy
processing, etc., and determines an answer which it sends to the requesting
end-entity
- the end-entity accepts or rejects the initial request based on the
response it gets.
We actually looked at this for a while in the MISSI effort (well, at least
some of us did :-). There were a number of potential customers who wanted
something like this because of some perceived advantages:
1 - it seems to fit the 'thin client' model that was all the rage a year
or so ago. All the end-entity has to know is how to contact a transaction
server; it doesn't have to have all of the cert path construction and
validation logic. This makes the software with the most copies deployed be
as small, simple, and cheap as possible.
2 - it doesn't force any user interactions at the end-entity. At worst,
the user is told "accepted; authorization code = .." or "rejected: reason...".
3 - it results in all of the information needed for non-repudiation (e.g.,
certificates, cert paths, CRLs, etc.) being stored at one or a few central
places, rather than having it scattered at various workstations all over
the net. Further, since it was envisioned that the transaction servers
would be high-end machines located in data centers, it would be easier to
establish the procedures and processes necessary to protect and store the
non-repudiation information.
4 - it seems to provide the most timely revocation notification of the
system designs presented so far. Particularly if the transaction server is
also the CA who issued the certificate in the first place, revocation
notification can be distributed almost instantly upon the revocation
decision being made.
On the other hand, it does have a number of potential "issues" (to be
polite). Some of them were:
1 - as Steve Kent has pointed out, it makes the transaction server an
attractive target. I can derive great benefit from taking it over, and I
can probably derive some benefit just from crashing the thing. (Military
folk tend not to like designs with single points of failure; it's too
darned easy to just drop a bomb on the thing.)As Denis Pinkas pointed out,
you can alleviate some of this, but there's a cost attached.
2 - without worrying about attacks, it's likely that the transaction
server will have major reliability & communications bandwidth requirements,
especially if we're dealing with approvals required prior to the
establishment of real-time connections. This will cause it to be a very
expensive suite of hardware & software, compared with the rest of the
system.
3 - it's relatively straightforward to handle signed messages. Encryption
is worse, though - if you want the transaction server to handle encrypting
and decrypting of data, you've turned your environment into something that
looks a lot like what's described in Dean & Ottaway's
<draft-ietf-smime-domsec-00.txt>. You lose the ability to have data
encrypted from end-user to end-user; you can only encrypt it from end-user
to server or even server to server. Then, the data pass in the clear
between end-user and server, or have to be separately encrypted for that
link. That's not necessarily bad, but it may not be something that
everybody wants to do. (If you want to have the transaction server handle
signature but not encryption, you lose much of the benefit, because the
end-entity will have to do all of the certificate path construction and
validation just to encrypt & decrpyt data.)
None of these "issues" is necessarily unsolvable in general, but they may
be too hard in any particular environment, and taken together they can
cause a lot of pain. (Ultimately, we didn't implement anything like this,
because it was going to take a lot of time and money to solve the "issues",
and it wasn't clear that all of them were readily solvable given our
particular constraints.)
Now, the reason for this long-winded message: with OCSP, PKIX took the
first step toward this architecture, by setting up a server to basically
check CRLs for the end-user. With DCS, it looks like we're taking the
second step, with the cs and cpkc transaction types. So: will PKIX
eventually move toward supporting the full architecture? If that's
anybody's goal, should we be starting to look now at the entire set of
things necessary to get there, rather than taking it piece by piece?
Or, is it the case that nobody thinks that the architecture I described is
ever in the plans, and all we're looking at is incremental service
enhancements?
Al Arsenault
- my opinions are my own, yada, yada, yada
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA14311 for ietf-pkix-bks; Mon, 19 Oct 1998 20:19:22 -0700 (PDT)
Received: from heidegger.uol.com.br (smtp.uol.com.br [200.230.198.76]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA14307 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 20:19:15 -0700 (PDT)
Received: from csclientwin95-2 ([200.231.73.18]) by heidegger.uol.com.br (8.9.1/8.9.1) with SMTP id BAA02541 for <ietf-pkix@imc.org>; Tue, 20 Oct 1998 01:21:15 -0200 (EDT)
Message-ID: <001f01bdfbf1$c5ea5200$8044e7c8@csclientwin95-2>
Reply-To: "Ramirez" <marcio_ramirez@uol.com.br>
From: "Ramirez" <marcio_ramirez@uol.com.br>
To: <ietf-pkix@imc.org>
Subject: DigitalID for MS-Outlook Express ?
Date: Tue, 20 Oct 1998 04:18:12 -0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01BDFBE0.A6ADDC60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_001A_01BDFBE0.A6ADDC60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello,
I need some help for building Digital ID for Microsoft Explorer.
I build with some extensions, but I think wich fault anything.
The my Client certificate is:
-----BEGIN CERTIFICATE-----
MIIBsQYJKoZIhvcNAQcCoIIBojCCAZ4CAQExADAPBgkqhkiG9w0BBwGgAgQAoIIB
gjCCAX4wgegCAXAwDQYJKoZIhvcNAQEEBQAwPDEYMBYGA1UEChMPQ29uc3VsdFNv
ZnR3YXJlMSAwHgYDVQQDExdDb25zdWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODEw
MTgxOTM4MjZaFw05OTEwMTgxOTM4MjZaMBkxFzAVBgNVBAMTDm1hcmNpb19yYW1p
cmV6MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAeWq6iOwb5NDfJxhNhW17R7cnRrST
D9dE3XmIiwhioSFO3lva3q89G/yvf878IwsoGO4j4ae3s0Qi3ndxZuZm9QIDAQAB
MA0GCSqGSIb3DQEBBAUAA4GBANIdRuYLsmgAfh6IWrstNxBr8mDewAb6fXJ1OOcM
sPgINwmeWPk7t25h6237mxUN9+X/By+na9sabzfvOjcFwqDdEjuHjOQmm1Qkz+mo
RzPjuF7ux3UdHJdT0916TS1M7GqcpP8QW0RLYMNxY0YDxOm6z+AV2zzG3GoPcVx1
6WPFMQA=3D
-----END CERTIFICATE-----
Version=3D1 (yet set with 2 to)
The extensions includes are:
SubjectAltName: email (RFC822)
ext: oid =3D "2.5.29.17"
critial =3D false
understood =3D false
gnames: parsed =3D true
KeyUsage: digitalSiganture =3D true
nonRepudiation =3D true;
keyEncipherment =3D true;
dataEncipherment =3D false;
keyAgreement =3D false;
keyCertSign =3D false;
cRLSign =3D false;
encipherOnly =3D false;
decipherOnly =3D false;
ext: oid =3D "2.5.29.15"
critial =3D true
understood =3D false
KeyExtensionUsage: oid(int) =3D EMAIL_PROT;
oid(char) =3D "1.3.6.1.5.5.7.3.4";
ext: oid =3D "2.5.29.37"
critial =3D false
understood =3D false
And my CA certificate is:
-----BEGIN CERTIFICATE-----
MIIBuDCCASGgAwIBAQIBIDANBgkqhkiG9w0BAQQFADAiMSAwHgYDVQQDExdDb25z
dWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODEwMTgxNTQ0MjdaFw05OTEwMTgxNTQ0
MjdaMCIxIDAeBgNVBAMTF0NvbnN1bHRTb2Z0d2FyZSBDbGFzcyAxMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQD491Bjirg7jKgnamn15yaoo9Rs+FUb+w3PXLnJ
6RvKGWA5B+53K+NjHYtVg8DG1O8rZbWS+8C5E/ZU16TpAATkpfj3dWgOL1HAtmu4
gWiNKZ0+UIzISMt7aI26RpQHeLyM+dc5pTFP5nDEtD/Q//xalfihHp7VWQXXd5g0
u1D8qwIDAQABMA0GCSqGSIb3DQEBBAUAA4GBADZXLvOMXUjjcPrzld17c5qxOYCv
m89Uh6u+r+GUukU4UuIDjQfm6jBtHnDKhsgxjXaz1pv5IX0YIUmsXnuqNZkBNlUp
RhV/2wO58XBI013DO4tU5HbQbe0mN+Cj0Oz+LRVfJgR7pvnKOwYzExN5G2EA1rrf
trmslxtHhYJx3bqc
-----END CERTIFICATE-----
Version=3D2
The extensions includes are:
BasicConstraints:
ca =3D true;
ext:
oid(int) =3D BASIC_CONSTRAINTS;
oid(char) =3D "2.5.29.19";
critical =3D true;
understood =3D false;
The client certificate is load succesfully into clientAuthority, but, =
don't load in DigitalID's MS-Outlook Express accounts.
What I need ?
Thanks
------=_NextPart_000_001A_01BDFBE0.A6ADDC60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2><BR>I need some help for building =
Digital ID for=20
Microsoft Explorer.<BR>I build with some extensions, but I think wich =
fault=20
anything.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The my Client certificate =
is:<BR>-----BEGIN=20
CERTIFICATE-----<BR>MIIBsQYJKoZIhvcNAQcCoIIBojCCAZ4CAQExADAPBgkqhkiG9w0BB=
wGgAgQAoIIB<BR>gjCCAX4wgegCAXAwDQYJKoZIhvcNAQEEBQAwPDEYMBYGA1UEChMPQ29uc3=
VsdFNv<BR>ZnR3YXJlMSAwHgYDVQQDExdDb25zdWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODE=
w<BR>MTgxOTM4MjZaFw05OTEwMTgxOTM4MjZaMBkxFzAVBgNVBAMTDm1hcmNpb19yYW1p<BR>=
cmV6MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAeWq6iOwb5NDfJxhNhW17R7cnRrST<BR>D9dE3=
XmIiwhioSFO3lva3q89G/yvf878IwsoGO4j4ae3s0Qi3ndxZuZm9QIDAQAB<BR>MA0GCSqGSI=
b3DQEBBAUAA4GBANIdRuYLsmgAfh6IWrstNxBr8mDewAb6fXJ1OOcM<BR>sPgINwmeWPk7t25=
h6237mxUN9+X/By+na9sabzfvOjcFwqDdEjuHjOQmm1Qkz+mo<BR>RzPjuF7ux3UdHJdT0916=
TS1M7GqcpP8QW0RLYMNxY0YDxOm6z+AV2zzG3GoPcVx1<BR>6WPFMQA=3D<BR>-----END=20
CERTIFICATE-----</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Version=3D1 (yet set with 2 =
to)</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The extensions includes =
are:<BR>SubjectAltName:=20
email (RFC822)<BR> ext: oid =3D =
"2.5.29.17"<BR> critial=20
=3D false<BR> understood =3D false</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> gnames: parsed =3D =
true</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyUsage: digitalSiganture =3D =
true<BR> nonRepudiation =3D true;<BR> keyEncipherment =3D=20
true;<BR> dataEncipherment =3D false;<BR> keyAgreement =3D=20
false;<BR> keyCertSign =3D false;<BR> cRLSign =3D =
false;<BR> =20
encipherOnly =3D false;<BR> decipherOnly =3D false;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> ext: oid =3D=20
"2.5.29.15"<BR> critial =3D true<BR> understood =
=3D=20
false</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyExtensionUsage: oid(int) =3D=20
EMAIL_PROT;<BR> oid(char) =3D=20
"1.3.6.1.5.5.7.3.4";</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> ext: oid =3D=20
"2.5.29.37"<BR> critial =3D false<BR> understood =
=3D=20
false</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2><BR>And my CA certificate =
is:<BR>-----BEGIN=20
CERTIFICATE-----<BR>MIIBuDCCASGgAwIBAQIBIDANBgkqhkiG9w0BAQQFADAiMSAwHgYDV=
QQDExdDb25z<BR>dWx0U29mdHdhcmUgQ2xhc3MgMTAeFw05ODEwMTgxNTQ0MjdaFw05OTEwMT=
gxNTQ0<BR>MjdaMCIxIDAeBgNVBAMTF0NvbnN1bHRTb2Z0d2FyZSBDbGFzcyAxMIGfMA0GCSq=
G<BR>SIb3DQEBAQUAA4GNADCBiQKBgQD491Bjirg7jKgnamn15yaoo9Rs+FUb+w3PXLnJ<BR>=
6RvKGWA5B+53K+NjHYtVg8DG1O8rZbWS+8C5E/ZU16TpAATkpfj3dWgOL1HAtmu4<BR>gWiNK=
Z0+UIzISMt7aI26RpQHeLyM+dc5pTFP5nDEtD/Q//xalfihHp7VWQXXd5g0<BR>u1D8qwIDAQ=
ABMA0GCSqGSIb3DQEBBAUAA4GBADZXLvOMXUjjcPrzld17c5qxOYCv<BR>m89Uh6u+r+GUukU=
4UuIDjQfm6jBtHnDKhsgxjXaz1pv5IX0YIUmsXnuqNZkBNlUp<BR>RhV/2wO58XBI013DO4tU=
5HbQbe0mN+Cj0Oz+LRVfJgR7pvnKOwYzExN5G2EA1rrf<BR>trmslxtHhYJx3bqc<BR>-----=
END=20
CERTIFICATE-----</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Version=3D2</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The extensions includes=20
are:<BR>BasicConstraints:<BR> ca =3D true;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> ext:<BR> oid(int) =3D=20
BASIC_CONSTRAINTS;<BR> oid(char) =3D =
"2.5.29.19";<BR> =20
critical =3D true;<BR> understood =3D false;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The client certificate is load =
succesfully into=20
clientAuthority, but, don't load in DigitalID's MS-Outlook Express=20
accounts.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>What I need ?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 =
size=3D2><BR>Thanks</FONT></DIV></BODY></HTML>
------=_NextPart_000_001A_01BDFBE0.A6ADDC60--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA12815 for ietf-pkix-bks; Mon, 19 Oct 1998 17:10:00 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA12811 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 17:09:59 -0700 (PDT)
Received: from [128.33.238.135] (TC135.BBN.COM [128.33.238.135]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id UAA19959; Mon, 19 Oct 1998 20:11:12 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011709b2517e919c08@[128.33.238.135]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D492@DSG1>
Date: Mon, 19 Oct 1998 19:55:01 -0400
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
>> Yes, one can imagine offloading this processing, but a fundamental
>> assumption underlying certificates is that one does not need to rely
>> on
>> other parties for such processing and storage. Thus directories are
>> untrusted repositories, which can do not worse than store bad data.
> [Alan Lloyd]
> That is why a certficate is signed so that in can be stored and
>transferred with and between "cryptographically" untrusted repositories.
The issue here is not the storage of signed data in directories, it is the
notion that the directory would perform a search for a user to collect
certs and CRLs, process them, and tell the user whether the cert was valid
or not. This abrogation of responsibility by the user, to a third party,
is dangerous.
>> I
>> would not want to confuse this long term existing model of what a
>> directory
>> does with the notion you;re suggesting, of a component/system that
>> performs
>> lots of processing that we currently envision being done by a
>> certificate
>> consuming system. I'm not saying we ought not consider such
>> alternative
>> models, but le's not confuse folks by calling them directories,
>> trusted
>> directories, etc.
> [Alan Lloyd] There is no confusion with the systems I work
>with. There are two approaches.
>
> 1. Where the CA's information model re root paths and cross
>certs and CRLs etc are sensibly designed and organised and matching
>rules applied from standard directory access (Search Ops) that can
>return a result. In this case the "processing" is placed on the
>directory to "validate" the certificate path issues.. all the clent
>needs to do is offer the cert require validation without prior knowledge
>of the information designs or the operational relationships that a
>directory enabled CA function might have.
I believe that we do fundamentally disagree here. Directories are
repositories that can return data stored in them, e.g., in response to
searches. Validation of cert paths is something a directory does for its
own use when employing certs for authentication in support of directory
access control. It is the relying party in such circumstances and thus is
doing what any such party ought to do as part of cert validation.
> 2. The second approach - which still promotes a validation -
>service based model is to have directory attached, directory enabled
>processes.. This is a nicer approach because these can scale easier -
>eg. we (the third rock from the sun) need to deal with global services
>that have 100m + users with at least 10 certs each -- and simple,
>business domain agile clients.
I don't know what this is saying.
>> >Phone systems are good - my telephone does not have software in it
>> to
>> >prove the telephone company can provide it with its phone number !
>> :-)
>>
>> I don't really see the relevance of this last analogy.
> [Alan Lloyd] This quite straight forward. I do not see the
>sense behind writing complex clients that when validating a certificate,
>the client goes has to know all the relationships of a CA, eg roots and
>cross certs, what extensions are used in CA certs, what may or may not
>be valid, etc for all the subjects (the cert subject) it deals with in
>the many domains of business they might work in.
> CAs may wish to improve their information models and objects
>over time that deal with cross certs and multiple roots - at any time.
>Why should such a change invalidate all the client software that deals
>with validation?.
It should not invalidate client software, because such software should be
just as capable of validating the resvied PKI structure as it was of
validating certs under the previous structure. We have standards for cert
processing procisely so that clients can do this correctly, in a standard
fashion.
> As said the PKI /CA design at present has not dealt with (IMHO
>)very well the way large scale directory systems are needed for wider
>use of X.509 and EC or the operational and service based issues of
>validation - with the emphasis of making client software as portable and
>as simple as possible. The designs at the moment are "technically
>orchestrated" re a CA information functional and information
>relationship design and certainly too complex - because the designs of
>the CA with all its mystery points is enforced on the client process.
Sorry. These are vague complaints.
> This is similar situation why LDAP is in a mess.
>
> If one designs a system with (distributed) functions (like the
>phone system or a directory SERVICE) and then one designs the access
>protocol, the system services actually constrains what is in the access
>protocol is and the software in the client that uses the access
>protocol ca actually do. ie. the system services and operations
>constrain any shift in what upgrades can occur on the access interface.
>
> LDAP approach - make the directory system as vague as possible,
>add protocol features that have an effect in the client and the server
>in a random way, ie make the processing of the protocol elements affect
>how the system and the clients evolve to a point where any new feature
>affects the wider interoperability of clients and servers/services. ie
>many features in LDAP MAY work OK with a single server address book (and
>need a lot of human effort), but if LDAP is used with a real distributed
>directory service (eg. X.500) then many of the funny features of LDAP
>cannot be used. - in addition , different knowledge, referral,
>replication, authentication, password and certficate management issues
>apply depending on what type of service supports the "LDAP" interface.
>
> A system model re services (such as cert validation) would
>strike me as the only way to start.
I don't want to debate LDAP issues; this is a PKI list. Your e-mail address
suggests that you may work for a company that believes directories are the
solution to lots of problems. Personally, I don't share that belief, but
the more central issues is that I'd like us to not confuse the current
definition of directory services, as defined in X.500 and LDAP, with some
possible future set of cert validation services. About 5 years ago we
developed such a service as part of a DARPA program; it validated certs
that a client could not validate because of algorithm incompatability or
similar constraints. Been there, done that. However, the better use of
the service was to collect certs and CRLs for the client and deliver them
in a form to simplify client cert path validation. That's not an
unreasonable service, but it's a far cry fro asking a third party to do the
validation for you.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA12804 for ietf-pkix-bks; Mon, 19 Oct 1998 17:09:36 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA12800 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 17:09:35 -0700 (PDT)
Received: from [128.33.238.135] (TC135.BBN.COM [128.33.238.135]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id UAA19923; Mon, 19 Oct 1998 20:10:46 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011704b25177b5ff58@[128.33.238.135]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC05D48E@DSG1>
Date: Mon, 19 Oct 1998 19:15:22 -0400
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: ietf-pkix@imc.org
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
I can appreciate the directory perspective of "CA-ness" but I don't think
that captures all of the issues being raised here. CAs exist independent
of directories, so many aspects of a CA may not be captured by by a purely
directory-centric view. Still, to the extent that folks look to
directories to help with cert selection, it's good to keep in mind what
features a directory can offer to help in addressing this problem.
steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA07367 for ietf-pkix-bks; Mon, 19 Oct 1998 06:37:49 -0700 (PDT)
Received: from TYO203.gate.nec.co.jp (TYO203.gate.nec.co.jp [202.32.8.211]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA07363 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 06:37:48 -0700 (PDT)
Received: from mailsv.nec.co.jp (mailsv-le1 [192.168.1.90]) by TYO203.gate.nec.co.jp (8.9.1a/3.7W98092815) with ESMTP id WAA14846 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:38:33 +0900 (JST)
Received: from gw.ccs.mt.nec.co.jp (gw.ccs.mt.nec.co.jp [133.201.2.2]) by mailsv.nec.co.jp (8.9.1a/3.7W-MAILSV-NEC) with ESMTP id WAA00426 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:38:32 +0900 (JST)
Received: from mail.ccs.mt.nec.co.jp (mail.ccs.mt.nec.co.jp [133.201.3.22]) by gw.ccs.mt.nec.co.jp (8.8.8+2.7Wbeta7/3.3W9-GW_CCS) with ESMTP id WAA19137 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:33:45 +0900 (JST)
Received: from sple243.ccs.mt.nec.co.jp (sple243.ccs.mt.nec.co.jp [172.16.5.41]) by mail.ccs.mt.nec.co.jp (8.9.1a/3.6W-CCS_Master) with ESMTP id WAA02733 for <ietf-pkix@imc.org>; Mon, 19 Oct 1998 22:38:32 +0900 (JST)
Received: from ccs.mt.nec.co.jp by sple243.ccs.mt.nec.co.jp (8.8.5+2.7Wbeta4/6.4J.6-slave-1.0) id WAA29988; Mon, 19 Oct 1998 22:38:29 +0900 (JST)
Message-Id: <199810191338.WAA29988@sple243.ccs.mt.nec.co.jp>
To: ietf-pkix@imc.org
Subject: Root CA key Update in CMP
X-Mailer: Mew version 1.70 on Emacs 19.28.6 / Mule 2.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 19 Oct 1998 22:38:28 +0900
From: Mine Sakurai <m-sakura@ccs.mt.nec.co.jp>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi,
I'm trying to experiment a Root CA key update according to the CMP
description.
I have some questions about the "OldwithNew" and the "NewwithOld"
certificates.
1. Should both the certificates have entirely the same Subject with
the "OldwithOld" or the "NewwithNew" certificate ?
I would like to put the string "OldwithNew" somewhere in the
Subject of the "OldwithNew" certificate to avoid confusion.
(the string "NewwithOld" in the Subject of the "NewwithOld",
similary)
Is it wrong?
2. Is there any reason the "OldwithNew" certificate is issued prior to the
"NewwithOld"?
I think it is natural that the "NewwithOld" certificate is first
issued with the old private key and then the "OldwithNew" and the
"NewwithNew" is issued with the new private key.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mine Sakurai E-mail: m-sakura@ccs.mt.nec.co.jp
Platform Technology Laboratory,
Internet Technology Laboratories, NEC Corp., Tokyo, JAPAN
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA28719 for ietf-pkix-bks; Sun, 18 Oct 1998 23:45:51 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA28705 for <ietf-pkix@imc.org>; Sun, 18 Oct 1998 23:45:42 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05XRZ>; Mon, 19 Oct 1998 16:42:28 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D497@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Carlisle Adams'" <carlisle.adams@entrust.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'Sarbari Gupta'" <sgupta@cygnacom.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: certificate path services [ was RE: NEW Data type for certifi cate selection ? ]
Date: Mon, 19 Oct 1998 16:42:25 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
IMHO This issue is not solved with YAP - yet another protocol, .....As
these create yet more complexity, scaling issues, knowledge and
addressing issues when building a system ..
Why is OCSP and yet another being promoted - as they seem to solve
nothing. - and what they do is add yet more implementation problems.
The issue of CA info/ client validation is one of (object - directory
style) information, information management, system knowledge and dealing
with a name based distributed environment. The protocol , semantics and
syntax of the information transfer and testing of all this can all be
dealt with quite naturally by directory services.
So unless OCSP or cert server protocol specs can define the information
model (in named distributed objects) for CAs, multiple paths, and the
validation process that clients need .. then what to they solve.
regards alan
> -----Original Message-----
> From: Carlisle Adams [SMTP:carlisle.adams@entrust.com]
> Sent: Friday, 16 October 1998 1:50
> To: 'Alan Lloyd'; 'Sarbari Gupta'
> Cc: 'ietf-pkix@imc.org '
> Subject: RE: certificate path services [ was RE: NEW Data type
> for certificate selection ? ]
>
> Hi Sarbari,
>
> > ----------
> > From: Sarbari Gupta[SMTP:sgupta@cygnacom.com]
> > Sent: Thursday, October 15, 1998 10:46 AM
> > To: 'Alan Lloyd'
> > Cc: 'ietf-pkix@imc.org '
> > Subject: certificate path services [ was RE: NEW Data type for
> > certificate selection ? ]
> >
> > I seem to agree with Alan that there are certain situations where it
> > would be very beneficial to have third-party services available to
> > assist with certificate path development and/or validation.
> >
> > If (and when) large scale PKIs become widely deployed, it could
> become
> > a
> > real problem for each end entity to look up and then validate the
> > certificate path to its peer's certificate. It requires a large
> amount
> > of processing power as well as complicated path processing software
> to
> > do this task. Additionally, it requires repeated interactions with a
> > remote Directory Server to build the certificate path.
> >
> > There are (at least) two ways to resolve this issue:
> >
> > 1) We introduce the concept of a trusted service, let's call it
> > "Certificate Path Validation Service (CPVS)" which could take in
> > requests for validation (comprising the end entity certificate and
> > possibly a trusted root, policy IDs, etc.) and return an YES/NO
> > answer.
> > The CPVS could be hosted on a high-end server that caches recent
> > requests and has the capability to interface with
> > Directories/Repositories over the internet to quickly obtain an
> answer
> > for the subscriber, thus relieving the end entity system from the
> > overhead of certificate path processing. The CPVS would also support
> > revocation models. The CPVS would be particularly useful in an
> > organizational environment, where a single dedicated system runs the
> > CPVS for that organization and services path validation requests for
> > other users within the organization. To support the notion of a CPVS
> > service, a new service interface needs to be defined and
> standardized.
> >
> >
> This is precisely one of the services specified in the Data
> Certification Server protocol. Please take a look at
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt
> (recently re-introduced into the PKIX Working Group) and let me know
> if
> this meets the functionality you had in mind.
>
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> cadams@entrust.com
> --------------------------------------------
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA13633 for ietf-pkix-bks; Sun, 18 Oct 1998 19:16:45 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA13629 for <ietf-pkix@imc.org>; Sun, 18 Oct 1998 19:16:37 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05XQ0>; Mon, 19 Oct 1998 12:13:35 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D492@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Stephen Kent'" <kent@bbn.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 19 Oct 1998 12:13:33 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line....
> -----Original Message-----
> From: Stephen Kent [SMTP:kent@bbn.com]
> Sent: Thursday, 15 October 1998 23:40
> To: Alan Lloyd
> Cc: 'ietf-pkix@imc.org '
> Subject: RE: NEW Data type for certificate selection ?
>
> Alan,
>
> >Yes the problem is a path issue. where CAs may have multiple paths to
> >their roots or other CAs, multiple approaches to revokation, Users
> have
> >multiple certficates, clients might be root and domain agile, etc.
> >
> >I have views on this which says we should not complicate the
> certificate
> >any more- so the client gets even more complex and untrusted, we
> should
> >use some simpler methods of validation with the assistance of the
> >directory service.
>
> Yes, one can imagine offloading this processing, but a fundamental
> assumption underlying certificates is that one does not need to rely
> on
> other parties for such processing and storage. Thus directories are
> untrusted repositories, which can do not worse than store bad data.
[Alan Lloyd]
That is why a certficate is signed so that in can be stored and
transferred with and between "cryptographically" untrusted repositories.
> I
> would not want to confuse this long term existing model of what a
> directory
> does with the notion you;re suggesting, of a component/system that
> performs
> lots of processing that we currently envision being done by a
> certificate
> consuming system. I'm not saying we ought not consider such
> alternative
> models, but le's not confuse folks by calling them directories,
> trusted
> directories, etc.
[Alan Lloyd] There is no confusion with the systems I work
with. There are two approaches.
1. Where the CA's information model re root paths and cross
certs and CRLs etc are sensibly designed and organised and matching
rules applied from standard directory access (Search Ops) that can
return a result. In this case the "processing" is placed on the
directory to "validate" the certificate path issues.. all the clent
needs to do is offer the cert require validation without prior knowledge
of the information designs or the operational relationships that a
directory enabled CA function might have.
2. The second approach - which still promotes a validation -
service based model is to have directory attached, directory enabled
processes.. This is a nicer approach because these can scale easier -
eg. we (the third rock from the sun) need to deal with global services
that have 100m + users with at least 10 certs each -- and simple,
business domain agile clients.
> >Phone systems are good - my telephone does not have software in it
> to
> >prove the telephone company can provide it with its phone number !
> :-)
>
> I don't really see the relevance of this last analogy.
[Alan Lloyd] This quite straight forward. I do not see the
sense behind writing complex clients that when validating a certificate,
the client goes has to know all the relationships of a CA, eg roots and
cross certs, what extensions are used in CA certs, what may or may not
be valid, etc for all the subjects (the cert subject) it deals with in
the many domains of business they might work in.
CAs may wish to improve their information models and objects
over time that deal with cross certs and multiple roots - at any time.
Why should such a change invalidate all the client software that deals
with validation?.
As said the PKI /CA design at present has not dealt with (IMHO
)very well the way large scale directory systems are needed for wider
use of X.509 and EC or the operational and service based issues of
validation - with the emphasis of making client software as portable and
as simple as possible. The designs at the moment are "technically
orchestrated" re a CA information functional and information
relationship design and certainly too complex - because the designs of
the CA with all its mystery points is enforced on the client process.
This is similar situation why LDAP is in a mess.
If one designs a system with (distributed) functions (like the
phone system or a directory SERVICE) and then one designs the access
protocol, the system services actually constrains what is in the access
protocol is and the software in the client that uses the access
protocol ca actually do. ie. the system services and operations
constrain any shift in what upgrades can occur on the access interface.
LDAP approach - make the directory system as vague as possible,
add protocol features that have an effect in the client and the server
in a random way, ie make the processing of the protocol elements affect
how the system and the clients evolve to a point where any new feature
affects the wider interoperability of clients and servers/services. ie
many features in LDAP MAY work OK with a single server address book (and
need a lot of human effort), but if LDAP is used with a real distributed
directory service (eg. X.500) then many of the funny features of LDAP
cannot be used. - in addition , different knowledge, referral,
replication, authentication, password and certficate management issues
apply depending on what type of service supports the "LDAP" interface.
A system model re services (such as cert validation) would
strike me as the only way to start.
regards alan
> Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA13279 for ietf-pkix-bks; Sun, 18 Oct 1998 17:59:21 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA13275 for <ietf-pkix@imc.org>; Sun, 18 Oct 1998 17:59:17 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <V1Y05XQV>; Mon, 19 Oct 1998 10:56:08 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC05D48E@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Sarbari Gupta'" <sgupta@cygnacom.com>, "'Dwight Arthur'" <dwightarthur@mindspring.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 19 Oct 1998 10:56:07 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Comments in line
> -----Original Message-----
> From: Sarbari Gupta [SMTP:sgupta@cygnacom.com]
> Sent: Tuesday, 13 October 1998 1:29
> To: 'Dwight Arthur'
> Cc: ietf-pkix@imc.org
> Subject: RE: NEW Data type for certificate selection ?
>
> I have been following this thread with great interest. Since the
> thread
> was rekindled, I wanted to offer another usage model that needs a
> slightly different selection criterion. I was not sure whether this
> model was discussed before on this list.
>
> One of the certificate selection mechanisms in use today is based on
> matching the issuer name. SSL implementations allow this form of
> selection. There is another variant of this model that may also be
> useful. In this variant, the certificate selection is based on a
> prefix
> of the issuer name. For example, the selection may be done based only
> on
> the country name and the organization name components of the issuer
> DN.
> Thus, if a large organization has multiple CAs, the selection criteria
> may logically be "a certificate issued by the organization" instead of
> the more restrictive "a certificate issued by a particular CA within
> the
> organization".
[Alan Lloyd] Being a directory oriented person. I think that
there seems to be a confused line between a function called a CA which
is represented by a directory object (that has certificates),etc and how
CA functions are represented in a directory system.
An organisation can in fact be a CA simply by adding a CA V2 aux
class to the OC definition of the "organisation" or org untit concerned.
In fact any directory object can take on the role of a CA
function by adding the aux OC to the entry eg a CA can be a Org person,
a device, an application, a ship, a tank or a kerbside kiosk or
automated ticket machine in a railway station.
Its the question of how such objects apply a directory
information model (CRLs, root paths, validity indications, etc) and how
the respective client software validates certificates against such
variances and differing application requirements is the issue..
Perhaps the help of directory services and matching rules may
this work?
regards alan
Do the X.500 matching rules support this kind of selection?
This model
> may be useful for SSL connections.
>
[Alan Lloyd] snip
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA21532 for ietf-pkix-bks; Fri, 16 Oct 1998 06:15:34 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA21521 for <ietf-pkix@imc.org>; Fri, 16 Oct 1998 06:14:51 -0700 (PDT)
Received: from k2.frcl.bull.fr (k2.frcl.bull.fr [129.182.100.2]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with ESMTP id PAA14063; Fri, 16 Oct 1998 15:14:35 +0200
Received: from bull.net (cloe198.frcl.bull.fr [129.182.109.213]) by k2.frcl.bull.fr (AIX4.2/UCB 8.7/8.7) with ESMTP id PAA17538; Fri, 16 Oct 1998 15:16:22 +0200 (DFT)
Message-ID: <3627C5B7.2E7800AE@bull.net>
Date: Fri, 16 Oct 1998 15:16:25 -0700
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull
X-Mailer: Mozilla 4.03 [fr] (Win16; I)
MIME-Version: 1.0
To: Sarbari Gupta <sgupta@cygnacom.com>
CC: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: certificate path services [ was RE: NEW Data type for certificate selection ? ]
References: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari,
It is nice to hear from you on the PKIX list now.
I will take the occasion of this new thread to comment about the CDS draft
and place this requirement in a broader perspective. This means a rather
long E-mail. :-(
> I seem to agree with Alan that there are certain situations where it
> would be very beneficial to have third-party services available to
> assist with certificate path development and/or validation.
>
> If (and when) large scale PKIs become widely deployed, it could become a
> real problem for each end entity to look up and then validate the
> certificate path to its peer's certificate. It requires a large amount
> of processing power as well as complicated path processing software to
> do this task. Additionally, it requires repeated interactions with a
> remote Directory Server to build the certificate path.
Agreed.
> There are (at least) two ways to resolve this issue:
>
> 1) We introduce the concept of a trusted service, let's call it
> "Certificate Path Validation Service (CPVS)" which could take in
> requests for validation (comprising the end entity certificate and
> possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
> The CPVS could be hosted on a high-end server that caches recent
> requests and has the capability to interface with
> Directories/Repositories over the internet to quickly obtain an answer
> for the subscriber, thus relieving the end entity system from the
> overhead of certificate path processing. The CPVS would also support
> revocation models. The CPVS would be particularly useful in an
> organizational environment, where a single dedicated system runs the
> CPVS for that organization and services path validation requests for
> other users within the organization. To support the notion of a CPVS
> service, a new service interface needs to be defined and standardized.
This can be seen as one of the services a "Data Validation Service (DVS)"
(see later for the justification of this new name) would provide.
The comments are relative to the document: Internet X.509 Public Key
Infrastructure. Data Certification Server Protocols
<draft-ietf-pkix-dcs-00.txt>. The various facets of the DCS functionality
need to be looked at very carefully before looking at the protocols (i.e. I
will not deal with the protocols).
The abstract says:
"Useful Data Certification Server responsibilities in a PKI are to validate
signatures and to provide up-to-date information regarding the status of
public key certificates".
This addresses two items:
a) validation of signatures,
b) up-to-date information regarding the status of public key certificates.
Let us address the validation of signatures first.
When a signer signs something this is in accordance with a security policy.
That policy may specify one OR MORE trusted points but also the allowed
certification paths that can be used. That policy may be implicit for a
given application/context or may be extracted from the data itself, e.g.
when you receive a signed contract that contains the policy.
The policy does not specify only the trusted points. It may also specify
other conditions, like which TSAs (Time Stamping Authorities) need to be
involved, the grace time period for a user to ask for the revocation of its
certificate in case of a private key compromise, ...
The implication is that nominating one or more trusted points is not enough
in the general case and only a security policy is able to encompass all the
checks that need to be made.
Degenerated cases may consider only one or more trusted point, but saying
that the signature is *valid* is insufficient unless we say against what
(see later the various cases that may be considered).
Considering a "certification path validity checking" would thus be more
appropriate but still restrictive.
An intermediate conclusion is thus to consider in addition to the validity
of a signature, the validity of a certification path. What means performing
a checking against trusted points ? This includes the certification path
that may be used. One way (but not the single one) to define them, is to use
self-signed certificates that include naming constraints. The key point is
to remember that it is not because a certificate exists in a Repository that
it should be used.
When trust points are used instead of security policies, it would be needed
to refer to ONE OR MORE self-signed certificates. In order to make sure that
the path used for the verification is correct, it should be given back
(including CRLs or OCSP responses and ARLs) to the requester so that either
it can check that it is OK and/or that it can be rechecked in the same way
by another DVS.
Let us then address the second item: up-to-date information regarding the
status of public key certificates.
The *status* of public key certificates is already being addressed by OCSP,
so we should not duplicate the work here. It is NOT addressed for an old
status, but it is not evident that it should (see arguments later on, why it
should not).
It would be better to consider "up-to-date information regarding the
*validity* of public key certificates".
Since both items would be about validity/validation, a better name would be
a Data Validation Server (DVS) instead of DCS where the word "Certification"
(from Data Certification server) may be confusing with the function of a CA.
As an example of this kind of problem the actual text speaks about: "When
certifying a public key certificate, the DCS verifies ..." A CA
(Certification Authority) does such a certification, not a DCS.
In the introduction (section 1) three functions are introduced:
1) validity and correctness of an entity's claim to possess data,
2) validity and revocation status of an entity's public key certificate,
3) validity and correctness of another entity's signature.
For the item 1, the TSA (Time Stamping Authority) already allows to prove
that the requester possessed the data in the request at the time indicated
by the DVS.
Is it thus needed in addition to consider the case where a single entity
(the DVS) both proves that the requester possessed the data in the request
and a valid signature key at the time indicated by the DVS ?
It would be better to keep the two functionality independent. The TSA
signature is always for later use, while the DVS signature is not (see
additional arguments later on). If needed, the same entity can support both
protocols. Since the last case (3) is about any entity's signature, it would
be easier to consider only that case and use the TSA, in addition, when
needed.
In the item 2, if validity is checked, by implication the revocation status
is also checked.
Note: It is not clear to understand what "correctness" means in addition to
validity in the items 1) and 3).
This let me to conclude that the various facets to consider for a DVS would
then be along the following:
1) validity of an entity's public key certificate.
2) validity of a certification path.
3) validity of an entity's signature.
The validity may be checked against:
a) a security policy.
b) one or more self-signed certificates.
c) one or more certification paths.
d) one or more trusted points (provided that the path being used is
returned).
The next question is what kind of information should be given to the DVS ?
There is not a single answer to this question, but it would be better to
restrict some of the possibilities when verifications "in the past" occur.
When something is signed, it seems natural that the verifier makes sure
that, at the first time it makes the verification, it gets everything back
that he will need later on to prove that the signature was valid (according
to a non repudiation policy).
If he (or someone else) wants to make the verification later on, it seems
then natural that he provides what he got at that time. This has two
important implications:
1) This means that the DVS does not have to fetch, e.g. back 3 years old
CRLs or ARLs.
2) This also means that the DVS should return all what is needed for later
proof. That stuff may then be used by any DVS to make the verification,
without the need for anyone to trust the first DVS for its good faith. This
would be a nice way to support the IDUP APIs where such a functionality
exists.
CRLS, OCSP responses and ARLs may then be part of the data that is given or
returned to the DVS. Time Stamp tokens may also be part of it.
All the functions listed above can be used in the context where the DVS is a
server trusted only by its requester and not necessarily by all the other
users. This minimizes the problem of a single point of attack as mentioned
by Steve.
> 2) We extend the services offered by a Directory Server to allow the
> retrieval of an entire certificate path is one call. Thus, the end
> system would issue a single LDAP call to the Directory Server (providing
> as inputs, the end entity certificate, trust anchors, etc.) to retrieve
> an entire certificate path. The actual path validation would be done on
> the end system itself. In this case, there is no need to trust the
> Directory since the actual path validation is done locally. The
> Directory Service is extended to support path development - also
> implying an extension to the LDAP interfaces.
>From my previous remarks, this second option would not be workable since we
would need a very intelligent Directory to do so. Anyway a protocol
different from LDAP would be needed and would not provide all the
flexibility that is needed.
> I think it would be beneficial to offer viable alternatives to
> developers of PKI-based systems/products to unburden them from
> complicated path processing functions. I am curious to hear others'
> opinions on these ideas.
Regards,
Denis
> - Sarbari Gupta
> =============================
> Sarbari Gupta
> CygnaCom Solutions
> (703)848-0883 ext 217
> sgupta@cygnacom.com
> =============================
>
> > -----Original Message-----
> > From: Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au]
> > Sent: Wednesday, October 14, 1998 6:06 PM
> > To: 'Sarbari Gupta '
> > Cc: ''David Boyce' '; 'ietf-pkix@imc.org '
> > Subject: RE: NEW Data type for certificate selection ?
> >
> > Yes the problem is a path issue. where CAs may have multiple paths to
> > their roots or other CAs, multiple approaches to revokation, Users
> > have
> > multiple certficates, clients might be root and domain agile, etc.
> >
> > I have views on this which says we should not complicate the
> > certificate
> > any more- so the client gets even more complex and untrusted, we
> > should
> > use some simpler methods of validation with the assistance of the
> > directory service.
> >
> > Phone systems are good - my telephone does not have software in it to
> > prove the telephone company can provide it with its phone number ! :-)
> >
> > see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
> > right direction - but I am biased of course :-)
> > regards alan
> >
> > ----------
> > From: David Boyce
> > To: Sarbari Gupta
> > Cc: 'David Boyce'; ietf-pkix@imc.org
> > Sent: 10/14/98 12:48:24 AM
> > Subject: Re: NEW Data type for certificate selection ?
> >
> > Sarbari Gupta writes (quoting David Boyce):
> > >>(I don't believe specifying 'prefix of Name' is adequate, since it
> > may
> > >>not be acceptable to match an Issuer at some greater depth than
> > >>intended. Both SubtreeSpecification and NameConstraintsSyntax
> > permit
> > >>limits to be placed on the depth of the matching, and also permit
> > the
> > >>explicit exclusion of Names which would otherwise match.)
> > >
> > >In the context of discussing a mechanism for "selecting" end entity
> > >certificates for use, I do not understand why the 'prefix of name'
> > >criterion is inadequate.
> >
> > Let me see if I can clarify what I mean. As I understand it, a
> > matching rule which supported 'prefix of Issuer' (without further
> > qualification) would be adequate for the specific purpose you
> > described ONLY if ANY Issuer whose name contained the prefix specified
> > would satisfy the intended purpose of the selection. I think there
> > might be other scenarios for which this would not be sufficient.
> >
> > For example, consider an environment in which an organization has a
> > mixture of 'high-trust' CAs at one level, subordinate to the
> > organization, and other 'Low-trust' CAs subordinate to them. All
> > these CAs would satisfy a selection criterion of 'prefix of Issuer'
> > with a value corresponding to the organization's name; clearly if the
> > intention was to select only 'high-trust' CAs, "prefix of Issuer" is
> > inadequate; some other discriminator would have to be used,
> > e.g. policyIds.
> >
> > A Certificate Matching rule which used NameConstraintsSyntax against
> > the Issuer name would permit successful discrimination in this case on
> > the basis of Issuer name alone, as specifying a permittedSubtrees.base
> > of the organisation name, with a permittedSubtrees.minimum of 1 and
> > permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
> > considered.
> >
> > In general, once a shortcoming in the present mechanism has been
> > identified, it's worth trying to think about what other constraints a
> > certificate selector might wish to specify with regard to the Issuer
> > name. (Of course, this whole discussion also has application to
> > Subject name and their respective altName extenstions.)
> >
> > You have indicated a need for 'prefix of Issuer'; by suggesting
> > e.g. NameConstraintsSyntax, I'm trying to address that need, and at
> > the same time think about what other aspects of the same problem might
> > need to be addressed. "prefix of Issuer" matching may well be
> > adequate for your own environment; but it may not be for other
> > environments.
> >
> > > On the other hand, if we were discussing
> > >certificate path validation, I would agree with you completely; for
> > CA
> > >certificates in the path to be validated, the NameConstraints
> > extension
> > >with the permitted and excluded subtrees would be absolutely
> > relevant.
> >
> > We're not discussing certificate path validation (although clearly
> > certificate selection has a bearing on subsequent certificate path
> > validation).
> >
> > In the above discussion, I'm suggesting extending/adapting the current
> > NameConstraintsSyntax definition so that it becomes a basis for a
> > matching rule for Issuer name.
> >
> > >Apparently, what is needed to support "selection of a certificate for
> > >use" by secure applications is the ability to draw upon the richness
> > >that is already present in the X.509 v3 certificate syntax.
> >
> > I am beginning to realise there is a more general problem here: how to
> > select a Certificate Path (end user certificate plus zero or more CA
> > certs) which will permit authentication. So far we have just been
> > discussing the selection of an end-user certificate while assuming
> > that the Cert path follows automatically ... it might make sense to
> > use X.509 certificatePairMatch for this.
> >
> > David.
> >
> > --
> > David Boyce
> >
> > Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
> > Email: d.boyce@isode.com Isode's WWW:
> > http://www.isode.com/
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA23344 for ietf-pkix-bks; Thu, 15 Oct 1998 16:37:23 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA23340 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 16:37:21 -0700 (PDT)
Received: from [128.33.238.34] (TC128.BBN.COM [128.33.238.128]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id TAA25800; Thu, 15 Oct 1998 19:38:10 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v0401170ab24c36bab792@[128.33.238.34]>
In-Reply-To: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
Date: Thu, 15 Oct 1998 19:35:19 -0400
To: Sarbari Gupta <sgupta@cygnacom.com>
From: Stephen Kent <kent@bbn.com>
Subject: Re: certificate path services [ was RE: NEW Data type for certificate selection ? ]
Cc: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari,
>There are (at least) two ways to resolve this issue:
>
>1) We introduce the concept of a trusted service, let's call it
>"Certificate Path Validation Service (CPVS)" which could take in
>requests for validation (comprising the end entity certificate and
>possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
>The CPVS could be hosted on a high-end server that caches recent
>requests and has the capability to interface with
>Directories/Repositories over the internet to quickly obtain an answer
>for the subscriber, thus relieving the end entity system from the
>overhead of certificate path processing. The CPVS would also support
>revocation models. The CPVS would be particularly useful in an
>organizational environment, where a single dedicated system runs the
>CPVS for that organization and services path validation requests for
>other users within the organization. To support the notion of a CPVS
>service, a new service interface needs to be defined and standardized.
Well, this certainly makes it clear which single, online system to attack
if one wants to be able to spoof all users in an enterprise environemnt.
>2) We extend the services offered by a Directory Server to allow the
>retrieval of an entire certificate path is one call. Thus, the end
>system would issue a single LDAP call to the Directory Server (providing
>as inputs, the end entity certificate, trust anchors, etc.) to retrieve
>an entire certificate path. The actual path validation would be done on
>the end system itself. In this case, there is no need to trust the
>Directory since the actual path validation is done locally. The
>Directory Service is extended to support path development - also
>implying an extension to the LDAP interfaces.
This is a lot better than option 1, if I have to choose bewteen the two.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA19261 for ietf-pkix-bks; Thu, 15 Oct 1998 08:56:44 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA19257 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:56:43 -0700 (PDT)
Received: id LAA24051; Thu, 15 Oct 1998 11:54:16 -0400
Received: by gateway id <4CGY0QJJ>; Thu, 15 Oct 1998 11:51:58 -0400
Message-ID: <D789F71F24B4D111955D00A0C99B4F5001789108@sothmxs01.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>, "'Sarbari Gupta'" <sgupta@cygnacom.com>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: certificate path services [ was RE: NEW Data type for certifi cate selection ? ]
Date: Thu, 15 Oct 1998 11:50:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Sarbari,
> ----------
> From: Sarbari Gupta[SMTP:sgupta@cygnacom.com]
> Sent: Thursday, October 15, 1998 10:46 AM
> To: 'Alan Lloyd'
> Cc: 'ietf-pkix@imc.org '
> Subject: certificate path services [ was RE: NEW Data type for
> certificate selection ? ]
>
> I seem to agree with Alan that there are certain situations where it
> would be very beneficial to have third-party services available to
> assist with certificate path development and/or validation.
>
> If (and when) large scale PKIs become widely deployed, it could become
> a
> real problem for each end entity to look up and then validate the
> certificate path to its peer's certificate. It requires a large amount
> of processing power as well as complicated path processing software to
> do this task. Additionally, it requires repeated interactions with a
> remote Directory Server to build the certificate path.
>
> There are (at least) two ways to resolve this issue:
>
> 1) We introduce the concept of a trusted service, let's call it
> "Certificate Path Validation Service (CPVS)" which could take in
> requests for validation (comprising the end entity certificate and
> possibly a trusted root, policy IDs, etc.) and return an YES/NO
> answer.
> The CPVS could be hosted on a high-end server that caches recent
> requests and has the capability to interface with
> Directories/Repositories over the internet to quickly obtain an answer
> for the subscriber, thus relieving the end entity system from the
> overhead of certificate path processing. The CPVS would also support
> revocation models. The CPVS would be particularly useful in an
> organizational environment, where a single dedicated system runs the
> CPVS for that organization and services path validation requests for
> other users within the organization. To support the notion of a CPVS
> service, a new service interface needs to be defined and standardized.
>
>
This is precisely one of the services specified in the Data
Certification Server protocol. Please take a look at
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt
(recently re-introduced into the PKIX Working Group) and let me know if
this meets the functionality you had in mind.
--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA18927 for ietf-pkix-bks; Thu, 15 Oct 1998 08:05:59 -0700 (PDT)
Received: from procert.cert.dfn.de (kelm@procert.cert.dfn.de [134.100.14.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA18923 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:05:55 -0700 (PDT)
Received: (from kelm@localhost) by procert.cert.dfn.de (8.9.1a/8.9.1) id RAA21625 for ietf-pkix@imc.org; Thu, 15 Oct 1998 17:05:04 +0200 (MET DST)
Date: Thu, 15 Oct 1998 17:05:04 +0200 (MET DST)
From: Stefan Kelm <kelm@pca.dfn.de>
Message-Id: <199810151505.RAA21625@procert.cert.dfn.de>
To: ietf-pkix@imc.org
Subject: Typo
Reply-To: ietf-pkix@imc.org
X-Sun-Charset: US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Folks,
I'm getting nitpicky here...
there are three tiny typos in both draft-ietf-pkix-ipki-part1-11.txt
and draft-ietf-pkix-crmf-01.txt where it says "posession" instead of
"possession".
Also, there are still references to ietf-pkix@tandem.com in some of
the PKIX drafts.
Cheers,
Stefan.
______________________________________________________________________________
Stefan Kelm PGP key: "finger kelm@www.cert.dfn.de" or via key server
DFN-CERT, University of Hamburg <kelm@cert.dfn.de>
Vogt-Koelln-Str. 30 http://www.cert.dfn.de/~kelm/
22527 Hamburg (Germany) Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18774 for ietf-pkix-bks; Thu, 15 Oct 1998 07:46:57 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18770 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 07:46:55 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDZCZ>; Thu, 15 Oct 1998 10:46:32 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9052@WUHER>
From: Sarbari Gupta <sgupta@cygnacom.com>
To: "'Alan Lloyd'" <Alan.Lloyd@OpenDirectory.com.au>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: certificate path services [ was RE: NEW Data type for certificate selection ? ]
Date: Thu, 15 Oct 1998 10:46:29 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I seem to agree with Alan that there are certain situations where it
would be very beneficial to have third-party services available to
assist with certificate path development and/or validation.
If (and when) large scale PKIs become widely deployed, it could become a
real problem for each end entity to look up and then validate the
certificate path to its peer's certificate. It requires a large amount
of processing power as well as complicated path processing software to
do this task. Additionally, it requires repeated interactions with a
remote Directory Server to build the certificate path.
There are (at least) two ways to resolve this issue:
1) We introduce the concept of a trusted service, let's call it
"Certificate Path Validation Service (CPVS)" which could take in
requests for validation (comprising the end entity certificate and
possibly a trusted root, policy IDs, etc.) and return an YES/NO answer.
The CPVS could be hosted on a high-end server that caches recent
requests and has the capability to interface with
Directories/Repositories over the internet to quickly obtain an answer
for the subscriber, thus relieving the end entity system from the
overhead of certificate path processing. The CPVS would also support
revocation models. The CPVS would be particularly useful in an
organizational environment, where a single dedicated system runs the
CPVS for that organization and services path validation requests for
other users within the organization. To support the notion of a CPVS
service, a new service interface needs to be defined and standardized.
2) We extend the services offered by a Directory Server to allow the
retrieval of an entire certificate path is one call. Thus, the end
system would issue a single LDAP call to the Directory Server (providing
as inputs, the end entity certificate, trust anchors, etc.) to retrieve
an entire certificate path. The actual path validation would be done on
the end system itself. In this case, there is no need to trust the
Directory since the actual path validation is done locally. The
Directory Service is extended to support path development - also
implying an extension to the LDAP interfaces.
I think it would be beneficial to offer viable alternatives to
developers of PKI-based systems/products to unburden them from
complicated path processing functions. I am curious to hear others'
opinions on these ideas.
- Sarbari Gupta
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================
> -----Original Message-----
> From: Alan Lloyd [SMTP:Alan.Lloyd@OpenDirectory.com.au]
> Sent: Wednesday, October 14, 1998 6:06 PM
> To: 'Sarbari Gupta '
> Cc: ''David Boyce' '; 'ietf-pkix@imc.org '
> Subject: RE: NEW Data type for certificate selection ?
>
> Yes the problem is a path issue. where CAs may have multiple paths to
> their roots or other CAs, multiple approaches to revokation, Users
> have
> multiple certficates, clients might be root and domain agile, etc.
>
> I have views on this which says we should not complicate the
> certificate
> any more- so the client gets even more complex and untrusted, we
> should
> use some simpler methods of validation with the assistance of the
> directory service.
>
> Phone systems are good - my telephone does not have software in it to
> prove the telephone company can provide it with its phone number ! :-)
>
> see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
> right direction - but I am biased of course :-)
> regards alan
>
> ----------
> From: David Boyce
> To: Sarbari Gupta
> Cc: 'David Boyce'; ietf-pkix@imc.org
> Sent: 10/14/98 12:48:24 AM
> Subject: Re: NEW Data type for certificate selection ?
>
> Sarbari Gupta writes (quoting David Boyce):
> >>(I don't believe specifying 'prefix of Name' is adequate, since it
> may
> >>not be acceptable to match an Issuer at some greater depth than
> >>intended. Both SubtreeSpecification and NameConstraintsSyntax
> permit
> >>limits to be placed on the depth of the matching, and also permit
> the
> >>explicit exclusion of Names which would otherwise match.)
> >
> >In the context of discussing a mechanism for "selecting" end entity
> >certificates for use, I do not understand why the 'prefix of name'
> >criterion is inadequate.
>
> Let me see if I can clarify what I mean. As I understand it, a
> matching rule which supported 'prefix of Issuer' (without further
> qualification) would be adequate for the specific purpose you
> described ONLY if ANY Issuer whose name contained the prefix specified
> would satisfy the intended purpose of the selection. I think there
> might be other scenarios for which this would not be sufficient.
>
> For example, consider an environment in which an organization has a
> mixture of 'high-trust' CAs at one level, subordinate to the
> organization, and other 'Low-trust' CAs subordinate to them. All
> these CAs would satisfy a selection criterion of 'prefix of Issuer'
> with a value corresponding to the organization's name; clearly if the
> intention was to select only 'high-trust' CAs, "prefix of Issuer" is
> inadequate; some other discriminator would have to be used,
> e.g. policyIds.
>
> A Certificate Matching rule which used NameConstraintsSyntax against
> the Issuer name would permit successful discrimination in this case on
> the basis of Issuer name alone, as specifying a permittedSubtrees.base
> of the organisation name, with a permittedSubtrees.minimum of 1 and
> permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
> considered.
>
> In general, once a shortcoming in the present mechanism has been
> identified, it's worth trying to think about what other constraints a
> certificate selector might wish to specify with regard to the Issuer
> name. (Of course, this whole discussion also has application to
> Subject name and their respective altName extenstions.)
>
> You have indicated a need for 'prefix of Issuer'; by suggesting
> e.g. NameConstraintsSyntax, I'm trying to address that need, and at
> the same time think about what other aspects of the same problem might
> need to be addressed. "prefix of Issuer" matching may well be
> adequate for your own environment; but it may not be for other
> environments.
>
> > On the other hand, if we were discussing
> >certificate path validation, I would agree with you completely; for
> CA
> >certificates in the path to be validated, the NameConstraints
> extension
> >with the permitted and excluded subtrees would be absolutely
> relevant.
>
> We're not discussing certificate path validation (although clearly
> certificate selection has a bearing on subsequent certificate path
> validation).
>
> In the above discussion, I'm suggesting extending/adapting the current
> NameConstraintsSyntax definition so that it becomes a basis for a
> matching rule for Issuer name.
>
> >Apparently, what is needed to support "selection of a certificate for
> >use" by secure applications is the ability to draw upon the richness
> >that is already present in the X.509 v3 certificate syntax.
>
> I am beginning to realise there is a more general problem here: how to
> select a Certificate Path (end user certificate plus zero or more CA
> certs) which will permit authentication. So far we have just been
> discussing the selection of an end-user certificate while assuming
> that the Cert path follows automatically ... it might make sense to
> use X.509 certificatePairMatch for this.
>
> David.
>
> --
> David Boyce
>
> Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
> Email: d.boyce@isode.com Isode's WWW:
> http://www.isode.com/
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA18270 for ietf-pkix-bks; Thu, 15 Oct 1998 06:53:38 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA18266 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 06:53:37 -0700 (PDT)
Received: from [128.33.238.148] (TC148.BBN.COM [128.33.238.148]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA22838; Thu, 15 Oct 1998 09:54:27 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011705b24baa7ed026@[128.33.238.141]>
In-Reply-To: <D1A949D4508DD1119C8100400533BEDC08309A@DSG1>
Date: Thu, 15 Oct 1998 09:40:26 -0400
To: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '"<ietf-pkix@imc.org>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Alan,
>Yes the problem is a path issue. where CAs may have multiple paths to
>their roots or other CAs, multiple approaches to revokation, Users have
>multiple certficates, clients might be root and domain agile, etc.
>
>I have views on this which says we should not complicate the certificate
>any more- so the client gets even more complex and untrusted, we should
>use some simpler methods of validation with the assistance of the
>directory service.
Yes, one can imagine offloading this processing, but a fundamental
assumption underlying certificates is that one does not need to rely on
other parties for such processing and storage. Thus directories are
untrusted repositories, which can do not worse than store bad data. I
would not want to confuse this long term existing model of what a directory
does with the notion you;re suggesting, of a component/system that performs
lots of processing that we currently envision being done by a certificate
consuming system. I'm not saying we ought not consider such alternative
models, but le's not confuse folks by calling them directories, trusted
directories, etc.
>Phone systems are good - my telephone does not have software in it to
>prove the telephone company can provide it with its phone number ! :-)
I don't really see the relevance of this last analogy.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA17822 for ietf-pkix-bks; Thu, 15 Oct 1998 05:40:51 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA17818 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 05:40:49 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id IAA23737 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:41:50 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id IAA23731 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:41:49 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id IAA06468 for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:40:57 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000312602@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Thu, 15 Oct 1998 08:36:28 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BDF816.E8B7A3C0@avenger.missi.ncsc.mil>; Thu, 15 Oct 1998 08:36:31 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981015123630Z-15230@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'David Boyce'" <D.Boyce@isode.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: Clarification on matching rules
Date: Thu, 15 Oct 1998 08:36:30 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Those of us who were at the ISO meeting back in 1995 are trying to
reconstruct all of the steps that led to the matching rule definitions.
In the interim, I forward this general recollection...
>> >Stefan Santesson writes:
>> >>CertificateAssertion ::= SEQUENCE {
>> > ...
>> >> policy [9] CertPolicySet OPTIONAL,
>> > ...
>> >
>> >>CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId
>> >
>> >Can anyone shed light on why this is called a
>> >CertPolicy*Set* when it's>defined as a SEQUENCE OF ?
>> >
>> >The only thing I can think of is that the nature of the data is 'SET
>> >OF', with the name reflecting that nature, but that 'SEQUENCE OF' has
>> >been used in the definition of the type in order to avoid introducing
>> >DER-encoding hassles.
>
>If memory and gut feelings serve, that is the reason: to avoid
>DER problems with encoding SET OF. Semantically, it is a set;
>pragmatically it is a sequence, to make it work.
>
>> >> j) policy matches if all of the policy elements identified
>> >> in one of the presented values are contained in the set of
>> >> policyElementIds in any of the policyInformation values in
>> >> the certificate policies extension in the stored attribute
>> >> value; there is no match if there is no certificate
>policies
>> >> extension in the stored attribute value;
>> >
>> >Is there mismatch between this description and the defined syntax for
>> >CertPolicySet here? The presence of the phrase 'in one of the
>presented
>> >values' seems to indicate a different syntax to the one defined.
>> >
>> >It looks to me as if the author had in mind a definition of
>> >CertPolicySet along the lines of
>> >
>> > CertPolicySet ::= SET (1..MAX) OF CertPolicyPresentedValues
>> >
>> > CertPolicyPresentedValues ::= SET (1..MAX) OF CertPolicyId
>> >
>> >(SET OF being regarded as equivalent to SEQUENCE OF for the
>> purposes of this discussion).
>> >
>> >If not, then surely CertPolicySet would comprise the entire
>> 'presented value', making the phrase 'identified in one of the
>> presented values' misleading.
>
>Yeah, this seems fuzzy to me, too. Perhaps it (j) should read
>
> j) policy matches if all of the policy elements specified as
> presented values are contained in the set of
> policyElementIds in any of the policyInformation values in
> the certificate policies extension in the stored attribute
> value; there is no match if there is no certificate policies
> extension in the stored attribute value;
>
>In other words:
>
>The assertion contains a single set; the assertion matches
>the certificate if and only if all elements of that set are
>contained in the certificate.
Sandi
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA22892 for ietf-pkix-bks; Wed, 14 Oct 1998 15:09:46 -0700 (PDT)
Received: from dsg1.OpenDirectory.com.au ([203.108.249.145]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA22888 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 15:09:38 -0700 (PDT)
Received: by DSG1 with Internet Mail Service (5.0.1458.49) id <4WLS6X8Z>; Thu, 15 Oct 1998 08:06:24 +1000
Message-ID: <D1A949D4508DD1119C8100400533BEDC08309A@DSG1>
From: Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>
To: "'Sarbari Gupta '" <sgupta@cygnacom.com>
Cc: "''David Boyce' '" <D.Boyce@isode.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 15 Oct 1998 08:06:23 +1000
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Yes the problem is a path issue. where CAs may have multiple paths to
their roots or other CAs, multiple approaches to revokation, Users have
multiple certficates, clients might be root and domain agile, etc.
I have views on this which says we should not complicate the certificate
any more- so the client gets even more complex and untrusted, we should
use some simpler methods of validation with the assistance of the
directory service.
Phone systems are good - my telephone does not have software in it to
prove the telephone company can provide it with its phone number ! :-)
see lloyd-dir-cert-stat-00.txt - I thought it was a good start in the
right direction - but I am biased of course :-)
regards alan
----------
From: David Boyce
To: Sarbari Gupta
Cc: 'David Boyce'; ietf-pkix@imc.org
Sent: 10/14/98 12:48:24 AM
Subject: Re: NEW Data type for certificate selection ?
Sarbari Gupta writes (quoting David Boyce):
>>(I don't believe specifying 'prefix of Name' is adequate, since it may
>>not be acceptable to match an Issuer at some greater depth than
>>intended. Both SubtreeSpecification and NameConstraintsSyntax permit
>>limits to be placed on the depth of the matching, and also permit the
>>explicit exclusion of Names which would otherwise match.)
>
>In the context of discussing a mechanism for "selecting" end entity
>certificates for use, I do not understand why the 'prefix of name'
>criterion is inadequate.
Let me see if I can clarify what I mean. As I understand it, a
matching rule which supported 'prefix of Issuer' (without further
qualification) would be adequate for the specific purpose you
described ONLY if ANY Issuer whose name contained the prefix specified
would satisfy the intended purpose of the selection. I think there
might be other scenarios for which this would not be sufficient.
For example, consider an environment in which an organization has a
mixture of 'high-trust' CAs at one level, subordinate to the
organization, and other 'Low-trust' CAs subordinate to them. All
these CAs would satisfy a selection criterion of 'prefix of Issuer'
with a value corresponding to the organization's name; clearly if the
intention was to select only 'high-trust' CAs, "prefix of Issuer" is
inadequate; some other discriminator would have to be used,
e.g. policyIds.
A Certificate Matching rule which used NameConstraintsSyntax against
the Issuer name would permit successful discrimination in this case on
the basis of Issuer name alone, as specifying a permittedSubtrees.base
of the organisation name, with a permittedSubtrees.minimum of 1 and
permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
considered.
In general, once a shortcoming in the present mechanism has been
identified, it's worth trying to think about what other constraints a
certificate selector might wish to specify with regard to the Issuer
name. (Of course, this whole discussion also has application to
Subject name and their respective altName extenstions.)
You have indicated a need for 'prefix of Issuer'; by suggesting
e.g. NameConstraintsSyntax, I'm trying to address that need, and at
the same time think about what other aspects of the same problem might
need to be addressed. "prefix of Issuer" matching may well be
adequate for your own environment; but it may not be for other
environments.
> On the other hand, if we were discussing
>certificate path validation, I would agree with you completely; for CA
>certificates in the path to be validated, the NameConstraints extension
>with the permitted and excluded subtrees would be absolutely relevant.
We're not discussing certificate path validation (although clearly
certificate selection has a bearing on subsequent certificate path
validation).
In the above discussion, I'm suggesting extending/adapting the current
NameConstraintsSyntax definition so that it becomes a basis for a
matching rule for Issuer name.
>Apparently, what is needed to support "selection of a certificate for
>use" by secure applications is the ability to draw upon the richness
>that is already present in the X.509 v3 certificate syntax.
I am beginning to realise there is a more general problem here: how to
select a Certificate Path (end user certificate plus zero or more CA
certs) which will permit authentication. So far we have just been
discussing the selection of an end-user certificate while assuming
that the Cert path follows automatically ... it might make sense to
use X.509 certificatePairMatch for this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA22676 for ietf-pkix-bks; Wed, 14 Oct 1998 14:43:47 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA22672 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 14:43:45 -0700 (PDT)
Received: id RAA21675; Wed, 14 Oct 1998 17:42:39 -0400
Received: by gateway id <4CGY0N97>; Wed, 14 Oct 1998 17:40:25 -0400
Message-ID: <D789F71F24B4D111955D00A0C99B4F5001789100@sothmxs01.entrust.com>
From: Carlisle Adams <carlisle.adams@entrust.com>
To: ietf-pkix@imc.org, "'Stefan_Salzmann/HAM/Lotus@lotus.com'" <Stefan_Salzmann/HAM/Lotus@lotus.com>
Subject: RE: Centralized Scheme versus Basic Authentication Scheme
Date: Wed, 14 Oct 1998 17:38:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA22673
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Stefan,
> ----------
> From:
> Stefan_Salzmann/HAM/Lotus@lotus.com[SMTP:Stefan_Salzmann/HAM/Lotus@lot
> us.com]
> Sent: Tuesday, October 13, 1998 9:39 AM
> To: ietf-pkix@imc.org
> Subject: Centralized Scheme versus Basic Authentication Scheme
>
> Hello once again,
>
> wouldn´t it be better as well as easier to use the centralized scheme
> instead
> using the basic authentication scheme:
>
It may well be easier, but "better" depends upon your environment...
> In Draft draft-ietf-pkix-ipki3cmp-08.txt Certificate Management
> Protocols the
> basic authentication scheme MUST be used. So why not using the easier
> centralized scheme.
>
> Thanks for answering,
> Stefan
>
Many people object to the idea that the CA generates all key pairs (for
a variety of reasons, including the absence of strong non-repudiation
arguments). Therefore, making the centralized scheme the mandatory
scheme was totally unacceptable to a large number of interested parties.
--------------------------------------------
Carlisle Adams
Entrust Technologies
cadams@entrust.com
--------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA10539 for ietf-pkix-bks; Wed, 14 Oct 1998 00:19:10 -0700 (PDT)
Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA10533 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 00:19:08 -0700 (PDT)
Received: from fionn.es.net (LOCALHOST [127.0.0.1]) by fionn.es.net (LBNLMWH18/LBNLMWH11/ESOCF2) with ESMTP id AAA21775 for <ietf-pkix@imc.org>; Wed, 14 Oct 1998 00:20:05 -0700 (PDT)
Message-Id: <199810140720.AAA21775@fionn.es.net>
To: ietf-pkix@imc.org
Reply-to: helm@fionn.es.net
Subject: Re: We Buy Anything!
In-reply-to: Your message of "Wed, 14 Oct 1998 00:45:52 CDT." <199810140545.AAA24289@mail.hic.net>
Date: Wed, 14 Oct 1998 00:20:05 -0700
From: Michael Helm <helm@fionn.es.net>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
liquid_32@hotmail.com writes:
>
> We buy anything!!!!!
>
>
> DISTRESSED MERCHANDISE----CLOSE-OUTS------FACTORY RETURNS
Clipper chips?
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id VAA29314 for ietf-pkix-bks; Tue, 13 Oct 1998 21:28:09 -0700 (PDT)
Received: from mail.hic.net (root@mail.hic.net [209.144.4.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id VAA29310; Tue, 13 Oct 1998 21:28:07 -0700 (PDT)
From: liquid_32@hotmail.com
Received: from default (ip121.hamilton2.dialup.canada.psi.net [154.11.101.121]) by mail.hic.net (8.8.5/8.8.5) with SMTP id AAA24289; Wed, 14 Oct 1998 00:45:52 -0500 (CDT)
Date: Wed, 14 Oct 1998 00:45:52 -0500 (CDT)
Message-Id: <199810140545.AAA24289@mail.hic.net>
To: liquid_32@hotmail.com
Subject: We Buy Anything!
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
We buy anything!!!!!
DISTRESSED MERCHANDISE----CLOSE-OUTS------FACTORY RETURNS
We pay top dollar for your merchandise!! GUARANTEED!
Representatives Nationwide ready to pay immediate cash!
PHONE: 818-506-7885
FAX: 818-980-8033
E-MAIL: liquidator@hotmail.com
http://www.ieleads.com/liquidator
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA25613 for ietf-pkix-bks; Tue, 13 Oct 1998 20:46:58 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA25605 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 20:46:57 -0700 (PDT)
Received: from chromatix.com (cc1020663-a.hwrd1.md.home.com [24.3.62.220]) by chromatix.com (8.8.8/8.8.8) with ESMTP id XAA21409; Tue, 13 Oct 1998 23:47:29 -0400 (EDT) (envelope-from dave@chromatix.com)
Message-ID: <3624C9B0.C90F3E09@chromatix.com>
Date: Wed, 14 Oct 1998 11:56:32 -0400
From: David Horvath <dave@chromatix.com>
Organization: @Home Network
X-Mailer: Mozilla 4.05 [en]C-AtHome0404 (Win95; U)
MIME-Version: 1.0
To: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
CC: "'Sean Turner'" <turners@ieca.com>, "'PKIX'" <ietf-pkix@imc.org>, "'Ldapext'" <ietf-ldapext@netscape.com>, "'Dave Horvath'" <David.Horvath@chromatix.com>
Subject: Re: CA strong binds
References: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981013192151Z-14363@avenger.missi.ncsc.mil>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sandi,
I don't believe the OID of the attribute (indicating where the
certificate came from) is included in the certification path as defined
in X.509.
Dave H
Miklos, Sue A. wrote:
>
> Dave,
>
> I believe the discussion may have been related to "which data blob" goes
> into the protocol exchange when performing an operation that calls out
> "userCertificate", if the user is a CA. Does the CA certificate (with a
> different oid) get inserted into the exchange or does this require that
> the CA also maintain a certificate (identical information?) with the oid
> of a userCertificate.
>
> I realize this should be transparent, but wonder if others have
> experiences with this.
>
> Sandi
>
> >----------
> >From: Dave Horvath[SMTP:David.Horvath@chromatix.com]
> >Sent: Tuesday, October 13, 1998 2:44 PM
> >To: Sean Turner; PKIX; Ldapext
> >Subject: Re: CA strong binds
> >
> >
> >Sean,
> >
> > The only requirement that we have for the SafePages LDAP/X.500 products
> >is that the certificate must have the digitalSignature bit asserted in the
> >keyUsage field if it is a Version 3 certificate with the keyUsage extension
> >present. The other bits and the cA flag in the basicConstraints
> >extensions are not consulted.
> >
> > The existence or the location of the certificate in the repository does
> >not play a role for authentication.
> >
> >Dave Horvath
> >
> >-----Original Message-----
> >From: Sean Turner <turners@ieca.com>
> >To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
> >Date: Tuesday, October 13, 1998 1:41 PM
> >Subject: CA strong binds
> >
> >
> >>All,
> >>
> >>Appologies in advance if you get two of this message but I wasn't sure
> >>which list to send the message to.
> >>
> >>Recently some colleagues and I have been arguing whether applications
> >>will choke when looking for CA certificates in
> >>CertificationPath.userCertificate. For example, when a CA binds to an
> >>LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
> >>the CA's certificate will be passed in
> >>certification-path.userCertificate and the CA's superiors certificates
> >>are passed in certication-path.theCACertificates. Will applications
> >>choke when trying to process the CA certificate from a field called
> >>userCertificate or when trying to look for a "user's certificate"
> >>which is in a CA's directory entry?
> >>
> >>I know the name of the field shouldn't be confused with the value that
> >>goes into it, but we were concerned that many of the specifications
> >>were clear on where CA certificates should be put when attempting to
> >>perform strong binds to the directory.
> >>
> >>Any thoughts - implementation experience?
> >>
> >>Thanks,
> >>
> >>spt
> >>
> >>
> >
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA25430 for ietf-pkix-bks; Tue, 13 Oct 1998 20:34:15 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA25426 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 20:34:13 -0700 (PDT)
Received: from chromatix.com (cc1020663-a.hwrd1.md.home.com [24.3.62.220]) by chromatix.com (8.8.8/8.8.8) with ESMTP id XAA21389; Tue, 13 Oct 1998 23:34:44 -0400 (EDT) (envelope-from dave@chromatix.com)
Message-ID: <3624C6B8.A1EC044A@chromatix.com>
Date: Wed, 14 Oct 1998 11:43:52 -0400
From: David Horvath <dave@chromatix.com>
Organization: @Home Network
X-Mailer: Mozilla 4.05 [en]C-AtHome0404 (Win95; U)
MIME-Version: 1.0
To: Santosh Chokhani <chokhani@cygnacom.com>
CC: "'Dave Horvath'" <David.Horvath@chromatix.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, Ldapext <ietf-ldapext@netscape.com>
Subject: Re: CA strong binds
References: <51BF55C30B4FD1118B4900207812701E20B0CD@WUHER>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Santosh,
Good question. I believe we will reject the signature verification
even if the extension is not marked critical, as long as the ASN.1 is
decoded properly, but I will have to verify.
Dave Horvath
Santosh Chokhani wrote:
>
> Dave:
>
> I assume the digital signature bit is required to be turned only if the
> key usage extension is marked critical.
>
> > -----Original Message-----
> > From: Dave Horvath [SMTP:David.Horvath@chromatix.com]
> > Sent: Tuesday, October 13, 1998 2:44 PM
> > To: Sean Turner; PKIX; Ldapext
> > Subject: Re: CA strong binds
> >
> >
> > Sean,
> >
> > The only requirement that we have for the SafePages LDAP/X.500
> > products
> > is that the certificate must have the digitalSignature bit asserted in
> > the
> > keyUsage field if it is a Version 3 certificate with the keyUsage
> > extension
> > present. The other bits and the cA flag in the basicConstraints
> > extensions are not consulted.
> >
> > The existence or the location of the certificate in the repository
> > does
> > not play a role for authentication.
> >
> > Dave Horvath
> >
> > -----Original Message-----
> > From: Sean Turner <turners@ieca.com>
> > To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
> > Date: Tuesday, October 13, 1998 1:41 PM
> > Subject: CA strong binds
> >
> >
> > >All,
> > >
> > >Appologies in advance if you get two of this message but I wasn't
> > sure
> > >which list to send the message to.
> > >
> > >Recently some colleagues and I have been arguing whether applications
> > >will choke when looking for CA certificates in
> > >CertificationPath.userCertificate. For example, when a CA binds to
> > an
> > >LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
> > >the CA's certificate will be passed in
> > >certification-path.userCertificate and the CA's superiors
> > certificates
> > >are passed in certication-path.theCACertificates. Will applications
> > >choke when trying to process the CA certificate from a field called
> > >userCertificate or when trying to look for a "user's certificate"
> > >which is in a CA's directory entry?
> > >
> > >I know the name of the field shouldn't be confused with the value
> > that
> > >goes into it, but we were concerned that many of the specifications
> > >were clear on where CA certificates should be put when attempting to
> > >perform strong binds to the directory.
> > >
> > >Any thoughts - implementation experience?
> > >
> > >Thanks,
> > >
> > >spt
> > >
> > >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20580 for ietf-pkix-bks; Tue, 13 Oct 1998 12:21:01 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20576 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 12:20:59 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id PAA11735 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:57 -0400 (EDT)
Received: from missi.ncsc.mil (depot.missi.ncsc.mil [144.51.60.1]) by stingray.missi.ncsc.mil with ESMTP id PAA11720 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:55 -0400 (EDT)
Received: from mimesweeper.missi.ncsc.mil (mimesweeper.missi.ncsc.mil [144.51.60.2]) by missi.ncsc.mil (8.8.8/8.8.8) with ESMTP id PAA14095 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:06 -0400 (EDT)
Received: from avenger.missi.ncsc.mil (unverified) by mimesweeper.missi.ncsc.mil (Content Technologies SMTPRS 2.0.15) with SMTP id <B0000309932@mimesweeper.missi.ncsc.mil> for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 15:21:52 -0400
Received: by avenger.missi.ncsc.mil with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BDF6BD.34766C70@avenger.missi.ncsc.mil>; Tue, 13 Oct 1998 15:21:52 -0400
Message-Id: <c=US%a=_%p=ExchangeNSA%l=AVENGER-981013192151Z-14363@avenger.missi.ncsc.mil>
From: "Miklos, Sue A." <samiklo@missi.ncsc.mil>
To: "'Sean Turner'" <turners@ieca.com>, "'PKIX'" <ietf-pkix@imc.org>, "'Ldapext'" <ietf-ldapext@netscape.com>, "'Dave Horvath'" <David.Horvath@chromatix.com>
Subject: RE: CA strong binds
Date: Tue, 13 Oct 1998 15:21:51 -0400
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dave,
I believe the discussion may have been related to "which data blob" goes
into the protocol exchange when performing an operation that calls out
"userCertificate", if the user is a CA. Does the CA certificate (with a
different oid) get inserted into the exchange or does this require that
the CA also maintain a certificate (identical information?) with the oid
of a userCertificate.
I realize this should be transparent, but wonder if others have
experiences with this.
Sandi
>----------
>From: Dave Horvath[SMTP:David.Horvath@chromatix.com]
>Sent: Tuesday, October 13, 1998 2:44 PM
>To: Sean Turner; PKIX; Ldapext
>Subject: Re: CA strong binds
>
>
>Sean,
>
> The only requirement that we have for the SafePages LDAP/X.500 products
>is that the certificate must have the digitalSignature bit asserted in the
>keyUsage field if it is a Version 3 certificate with the keyUsage extension
>present. The other bits and the cA flag in the basicConstraints
>extensions are not consulted.
>
> The existence or the location of the certificate in the repository does
>not play a role for authentication.
>
>Dave Horvath
>
>-----Original Message-----
>From: Sean Turner <turners@ieca.com>
>To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
>Date: Tuesday, October 13, 1998 1:41 PM
>Subject: CA strong binds
>
>
>>All,
>>
>>Appologies in advance if you get two of this message but I wasn't sure
>>which list to send the message to.
>>
>>Recently some colleagues and I have been arguing whether applications
>>will choke when looking for CA certificates in
>>CertificationPath.userCertificate. For example, when a CA binds to an
>>LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
>>the CA's certificate will be passed in
>>certification-path.userCertificate and the CA's superiors certificates
>>are passed in certication-path.theCACertificates. Will applications
>>choke when trying to process the CA certificate from a field called
>>userCertificate or when trying to look for a "user's certificate"
>>which is in a CA's directory entry?
>>
>>I know the name of the field shouldn't be confused with the value that
>>goes into it, but we were concerned that many of the specifications
>>were clear on where CA certificates should be put when attempting to
>>perform strong binds to the directory.
>>
>>Any thoughts - implementation experience?
>>
>>Thanks,
>>
>>spt
>>
>>
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA20470 for ietf-pkix-bks; Tue, 13 Oct 1998 12:07:22 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA20466 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 12:07:21 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDYMJ>; Tue, 13 Oct 1998 15:06:58 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E20B0CD@WUHER>
From: Santosh Chokhani <chokhani@cygnacom.com>
To: "'Dave Horvath'" <David.Horvath@chromatix.com>, Sean Turner <turners@ieca.com>, PKIX <ietf-pkix@imc.org>, Ldapext <ietf-ldapext@netscape.com>
Subject: RE: CA strong binds
Date: Tue, 13 Oct 1998 15:06:56 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dave:
I assume the digital signature bit is required to be turned only if the
key usage extension is marked critical.
> -----Original Message-----
> From: Dave Horvath [SMTP:David.Horvath@chromatix.com]
> Sent: Tuesday, October 13, 1998 2:44 PM
> To: Sean Turner; PKIX; Ldapext
> Subject: Re: CA strong binds
>
>
> Sean,
>
> The only requirement that we have for the SafePages LDAP/X.500
> products
> is that the certificate must have the digitalSignature bit asserted in
> the
> keyUsage field if it is a Version 3 certificate with the keyUsage
> extension
> present. The other bits and the cA flag in the basicConstraints
> extensions are not consulted.
>
> The existence or the location of the certificate in the repository
> does
> not play a role for authentication.
>
> Dave Horvath
>
> -----Original Message-----
> From: Sean Turner <turners@ieca.com>
> To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
> Date: Tuesday, October 13, 1998 1:41 PM
> Subject: CA strong binds
>
>
> >All,
> >
> >Appologies in advance if you get two of this message but I wasn't
> sure
> >which list to send the message to.
> >
> >Recently some colleagues and I have been arguing whether applications
> >will choke when looking for CA certificates in
> >CertificationPath.userCertificate. For example, when a CA binds to
> an
> >LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
> >the CA's certificate will be passed in
> >certification-path.userCertificate and the CA's superiors
> certificates
> >are passed in certication-path.theCACertificates. Will applications
> >choke when trying to process the CA certificate from a field called
> >userCertificate or when trying to look for a "user's certificate"
> >which is in a CA's directory entry?
> >
> >I know the name of the field shouldn't be confused with the value
> that
> >goes into it, but we were concerned that many of the specifications
> >were clear on where CA certificates should be put when attempting to
> >perform strong binds to the directory.
> >
> >Any thoughts - implementation experience?
> >
> >Thanks,
> >
> >spt
> >
> >
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA20288 for ietf-pkix-bks; Tue, 13 Oct 1998 11:54:37 -0700 (PDT)
Received: from chromatix.com (chromatix.com [207.97.115.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA20284 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 11:54:36 -0700 (PDT)
Received: from ash (ash.chromatix.com [207.97.115.9]) by chromatix.com (8.8.8/8.8.8) with SMTP id OAA19857; Tue, 13 Oct 1998 14:55:02 -0400 (EDT) (envelope-from David.Horvath@chromatix.com)
Message-ID: <002001bdf6d9$742a3060$097361cf@ash.chromatix.com>
From: "Dave Horvath" <David.Horvath@chromatix.com>
To: "Sean Turner" <turners@ieca.com>, "PKIX" <ietf-pkix@imc.org>, "Ldapext" <ietf-ldapext@netscape.com>
Subject: Re: CA strong binds
Date: Tue, 13 Oct 1998 14:44:04 -0400
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 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sean,
The only requirement that we have for the SafePages LDAP/X.500 products
is that the certificate must have the digitalSignature bit asserted in the
keyUsage field if it is a Version 3 certificate with the keyUsage extension
present. The other bits and the cA flag in the basicConstraints
extensions are not consulted.
The existence or the location of the certificate in the repository does
not play a role for authentication.
Dave Horvath
-----Original Message-----
From: Sean Turner <turners@ieca.com>
To: PKIX <ietf-pkix@imc.org>; Ldapext <ietf-ldapext@netscape.com>
Date: Tuesday, October 13, 1998 1:41 PM
Subject: CA strong binds
>All,
>
>Appologies in advance if you get two of this message but I wasn't sure
>which list to send the message to.
>
>Recently some colleagues and I have been arguing whether applications
>will choke when looking for CA certificates in
>CertificationPath.userCertificate. For example, when a CA binds to an
>LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
>the CA's certificate will be passed in
>certification-path.userCertificate and the CA's superiors certificates
>are passed in certication-path.theCACertificates. Will applications
>choke when trying to process the CA certificate from a field called
>userCertificate or when trying to look for a "user's certificate"
>which is in a CA's directory entry?
>
>I know the name of the field shouldn't be confused with the value that
>goes into it, but we were concerned that many of the specifications
>were clear on where CA certificates should be put when attempting to
>perform strong binds to the directory.
>
>Any thoughts - implementation experience?
>
>Thanks,
>
>spt
>
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA19934 for ietf-pkix-bks; Tue, 13 Oct 1998 11:16:51 -0700 (PDT)
Received: from dimoni.upc.es (dimoni.upc.es [147.83.2.62]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA19930 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 11:16:44 -0700 (PDT)
Received: from sert.ac.upc.es (sert.ac.upc.es [147.83.33.7]) by dimoni.upc.es (8.8.6/8.8.6) with ESMTP id UAA20931; Tue, 13 Oct 1998 20:15:42 +0200 (MET DST)
Received: (from smap@localhost) by sert.ac.upc.es (8.9.1/8.9.1) id UAA11603; Tue, 13 Oct 1998 20:20:37 +0200 (MET DST)
Received: from mila10.ac.upc.es(147.83.34.83) by sert.ac.upc.es via smap (V2.0) id xma011599; Tue, 13 Oct 98 20:20:34 +0200
Message-Id: <3.0.1.32.19981013202002.006a042c@popserver.ac.upc.es>
X-Sender: isn99@popserver.ac.upc.es
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 13 Oct 1998 20:20:02 +0200
To: isn99@ac.upc.es
From: "IS&N'99 Conference" <isn99@ac.upc.es>
Subject: IS&N'99 in Barcelona - Second Call for Contributions
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id LAA19931
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dear Sir/Madam,
Please find enclosed the IS&N'99 Second Call for Contributions.
Please apologize any possible duplication!
================================
<<<<< Paving the Way for an Open Service Market >>>>>
IS&N'99
Sixth International Conference on Intelligence in Services and Networks
***********************
27th - 29th April 1999
Barcelona, Spain
***********************
Second call for contributions
http://www.ac.upc.es/isn99/
********************************************
The Conference is jointly sponsored by
the European Commission,
the Universitat Politècnica de Catalunya (UPC)
and Telefónica.
The Conference is currently supported by
the ACTS projects in the IS&N Domain,
EURESCOM,
NMF,
OMG, and
TINA-C.
<<< IEEE Communications Society is technical co-sponsor of the Conference >>>
We live in an age when powerful communications technology is becoming
universally available. Each home has the power to send and receive not
just analogue voice, but also growing volumes of digital information and
even intelligence in the form of agents. Users are becoming increasingly
mobile and are expecting the same level of connectivity in the home, in the
office and on the road.
The progress in computing and communications technologies has created a
need for advanced software and services, to control the complexity of the
technology and place it at the service of the end-user. The challenge for
service engineers is to develop the tools and techniques that will
ultimately bring the full power of communications and information to
everyone, in a way that everyone can easily use.
At the same time, the regulatory and commercial context in which these
technologies are used is changing. The telecommunications market is more
and more open to full competition. The Internet is erasing the borders
between information technology and telecommunications. And the way we do
business is ever more dominated by electronic exchanges of information. Is
our technology ready for the open market of services and networks?
The Sixth International Conference on Intelligence in Services and Networks
(ISN'99) addresses the question of paving the way to the open services
market. The main theme of the conference is the advance in technologies
that will contribute to managing the complexity of an open service market
and delivering services to the people.
Contributions are also invited on market and regulatory issues and
standards. Reports on industrial experience and trials from across the
world are especially welcomed.
<<<<**** Topics ****>>>>
Contributions are invited on (but not limited to) topics such as:
Agent Technology
· use of intelligent and mobile agents
Applications & Security
· electronic commerce
· safety, security and integrity of services and systems
· human machine interfaces
Service engineering & Communications management
· open architectures and interfaces
· interoperability
· communications management
· managing quality of service
· middleware for communications services
· software engineering techniques for the creation of new services
· deployment, provisioning and brokerage of services
· managing wanted and unwanted interactions between services and networks
· evolution of existing technologies such as IN, TMN, Internet
· new trends in multi-media services
· mobile services
· performance issues
<<<<**** Technical papers ****>>>>
Authors are invited to submit a full paper of up to 10 pages including
figures, tables, references and annexes. Papers will be selected for
publication and presentation by the Technical Programme Committee. The
conference proceedings will be published in book form.
All correspondence will take place electronically. Further details on
submission can be found on the IS&N'99 web page:
http://www.ac.upc.es/isn99/
E-mail address for submission:
isn99@ac.upc.es
<<<<**** Project and Industrial showcase ****>>>>
Projects from around the world working on one of the topics above are
invited to demonstrate their results at the conference. Industrial and
product exhibitions are also expected.
If you are interested in a demonstration, please send an e-mail to:
isn99@ac.upc.es
<<<<******* IMPORTANT DATES *******>>>>
Full paper submissions due: 30 November 1998
Notification of acceptance: 15 January 1999
Final papers due: 27 February 1999
<<<<**** IS&N Organisation ****>>>>
Steering committee
Alvin Mullery, ICEurope, France
Chairman
Mario Campolargo, European Commission, Belgium
Jaime Delgado, Universitat Politècnica de Catalunya, Spain
Han Zuidweg, Alcatel, Belgium
Technical programme committee
Han Zuidweg, Alcatel, Belgium
Chairman
Ordinary members
Stefano Antoniazzi, Italtel
E. Athanassiou, DeTeBerkom
Rob Brennan, Teltec
Stefan Covaci, GMD Fokus
Jaime Delgado, UPC
Sofoklis Efremidis, Intracom
Nigel Jefferies, Vodafone
Jens Kristensen, EC
Thomas Magedanz, GMD Fokus
Ahmed Patel, University College Dublin
Raymond Posch, University Graz
Martin Potts, ASPA
Rick Reed, TSE
Pierre Rodier, ICEurope
Simone Sedillot, INRIA
Keith Start, Orca Research
Alan Steventon, BT
Fabrizio Zizza, Italtel
Corresponding members
Alessandro Barbagli, EC
Stephane Beauvais, Softwire
Hendrik Berndt, TINA-C
Vincent Bic, SUN
Wiet Bouma, KPN Research
Brian Byrnes, Object Design
Mikael Ek, Telelogic
Takeyuki Endo, Hitachi
Dieter Gantenbein, IBM
Alex Galis, UCL
Takeo Hamada, Fujitsu
Per Fly Hansen, TeleDanmark
Duncan James-Bell, Lucent
Kristofer Kimbler, Lund University
Patricia Lago, Politecnico Torino
Dirk Lecluse, WTCM/CRIF Belgium
Juha Lipiainen, Nokia
Julio López, Ericsson
Claudio Maristany, Telecom Argentina
Sean Martin, Cambridge Consultants
Kathleen Milsted, France Telecom
David Muldowney, Broadcom
Declan O'Sullivan, Iona Technologies
George Pavlou, Univ. Surrey
Kimmo Raatikainen, Univ. Helsinki
Munir Tag, Sema Group
Sebastiano Trigila, FUB
Anh Hoang Van, CNET
Hans Vanderstraeten, Alcatel
Dong Sik Yun, Korea Telecom
Organising committee
Jaime Delgado, Universitat Politècnica de Catalunya, Spain
Chairman
Germán Santos, Telefónica, Spain
Isabel Gallego, Universitat Politècnica de Catalunya, Spain
====================
More information on:
http://www.ac.upc.es/isn99/
isn99@ac.upc.es
Tel: +34 93 401 68 14 / 6792 / 5947
Fax: +34 93 401 70 55
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA18684 for ietf-pkix-bks; Tue, 13 Oct 1998 09:15:56 -0700 (PDT)
Received: from hq.vni.net (hq.vni.net [205.252.27.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA18680 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 09:15:53 -0700 (PDT)
Received: from ieca.com (nova-aaa-047.vni.net [205.177.115.47]) by hq.vni.net (8.8.8/8.8.5) with ESMTP id MAA29050; Tue, 13 Oct 1998 12:16:44 -0400 (EDT)
Message-ID: <36237BEE.2645691B@ieca.com>
Date: Tue, 13 Oct 1998 12:12:30 -0500
From: Sean Turner <turners@ieca.com>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.06 [en] (Win98; U)
MIME-Version: 1.0
To: PKIX <ietf-pkix@imc.org>, Ldapext <ietf-ldapext@netscape.com>
Subject: CA strong binds
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
Appologies in advance if you get two of this message but I wasn't sure
which list to send the message to.
Recently some colleagues and I have been arguing whether applications
will choke when looking for CA certificates in
CertificationPath.userCertificate. For example, when a CA binds to an
LDAP server (using say the X.509 Authentication SASL Mechanism I-D)
the CA's certificate will be passed in
certification-path.userCertificate and the CA's superiors certificates
are passed in certication-path.theCACertificates. Will applications
choke when trying to process the CA certificate from a field called
userCertificate or when trying to look for a "user's certificate"
which is in a CA's directory entry?
I know the name of the field shouldn't be confused with the value that
goes into it, but we were concerned that many of the specifications
were clear on where CA certificates should be put when attempting to
perform strong binds to the directory.
Any thoughts - implementation experience?
Thanks,
spt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18166 for ietf-pkix-bks; Tue, 13 Oct 1998 07:48:07 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA18162 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 07:48:05 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 13 Oct 1998 15:48:25 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: Sarbari Gupta <sgupta@cygnacom.com>
cc: "'David Boyce'" <D.Boyce@isode.com>, ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
In-reply-to: Your message of "Tue, 13 Oct 1998 09:06:58 EDT." <51BF55C30B4FD1118B4900207812701E1F9046@WUHER>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 13 Oct 1998 15:48:24 +0100
Message-ID: <21792.908290104@isode.com>
From: David Boyce <D.Boyce@isode.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari Gupta writes (quoting David Boyce):
>>(I don't believe specifying 'prefix of Name' is adequate, since it may
>>not be acceptable to match an Issuer at some greater depth than
>>intended. Both SubtreeSpecification and NameConstraintsSyntax permit
>>limits to be placed on the depth of the matching, and also permit the
>>explicit exclusion of Names which would otherwise match.)
>
>In the context of discussing a mechanism for "selecting" end entity
>certificates for use, I do not understand why the 'prefix of name'
>criterion is inadequate.
Let me see if I can clarify what I mean. As I understand it, a
matching rule which supported 'prefix of Issuer' (without further
qualification) would be adequate for the specific purpose you
described ONLY if ANY Issuer whose name contained the prefix specified
would satisfy the intended purpose of the selection. I think there
might be other scenarios for which this would not be sufficient.
For example, consider an environment in which an organization has a
mixture of 'high-trust' CAs at one level, subordinate to the
organization, and other 'Low-trust' CAs subordinate to them. All
these CAs would satisfy a selection criterion of 'prefix of Issuer'
with a value corresponding to the organization's name; clearly if the
intention was to select only 'high-trust' CAs, "prefix of Issuer" is
inadequate; some other discriminator would have to be used,
e.g. policyIds.
A Certificate Matching rule which used NameConstraintsSyntax against
the Issuer name would permit successful discrimination in this case on
the basis of Issuer name alone, as specifying a permittedSubtrees.base
of the organisation name, with a permittedSubtrees.minimum of 1 and
permittedSubtrees.maximum of 1, the 'low-trust' CAs would not be
considered.
In general, once a shortcoming in the present mechanism has been
identified, it's worth trying to think about what other constraints a
certificate selector might wish to specify with regard to the Issuer
name. (Of course, this whole discussion also has application to
Subject name and their respective altName extenstions.)
You have indicated a need for 'prefix of Issuer'; by suggesting
e.g. NameConstraintsSyntax, I'm trying to address that need, and at
the same time think about what other aspects of the same problem might
need to be addressed. "prefix of Issuer" matching may well be
adequate for your own environment; but it may not be for other
environments.
> On the other hand, if we were discussing
>certificate path validation, I would agree with you completely; for CA
>certificates in the path to be validated, the NameConstraints extension
>with the permitted and excluded subtrees would be absolutely relevant.
We're not discussing certificate path validation (although clearly
certificate selection has a bearing on subsequent certificate path
validation).
In the above discussion, I'm suggesting extending/adapting the current
NameConstraintsSyntax definition so that it becomes a basis for a
matching rule for Issuer name.
>Apparently, what is needed to support "selection of a certificate for
>use" by secure applications is the ability to draw upon the richness
>that is already present in the X.509 v3 certificate syntax.
I am beginning to realise there is a more general problem here: how to
select a Certificate Path (end user certificate plus zero or more CA
certs) which will permit authentication. So far we have just been
discussing the selection of an end-user certificate while assuming
that the Cert path follows automatically ... it might make sense to
use X.509 certificatePairMatch for this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA18001 for ietf-pkix-bks; Tue, 13 Oct 1998 07:27:18 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17997 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 07:27:17 -0700 (PDT)
From: Stefan_Salzmann/HAM/Lotus@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id KAA03949 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:32:44 -0400 (EDT)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id KAA25024 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:26:33 -0400 (EDT)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3 (723.2 9-26-1998)) id 8525669C.004FEE8F ; Tue, 13 Oct 1998 10:33:04 -0400
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: ietf-pkix@imc.org
Message-ID: <8525669C.004BC008.00@mta2.lotus.com>
Date: Tue, 13 Oct 1998 15:39:19 +0200
Subject: Centralized Scheme versus Basic Authentication Scheme
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA17998
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello once again,
wouldn´t it be better as well as easier to use the centralized scheme instead
using the basic authentication scheme:
In Draft draft-ietf-pkix-ipki3cmp-08.txt Certificate Management Protocols the
basic authentication scheme MUST be used. So why not using the easier
centralized scheme.
Thanks for answering,
Stefan
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA17888 for ietf-pkix-bks; Tue, 13 Oct 1998 07:10:54 -0700 (PDT)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA17883 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 07:10:52 -0700 (PDT)
From: Stefan_Salzmann/HAM/Lotus@lotus.com
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id KAA01730 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:16:17 -0400 (EDT)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id KAA22966 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 10:10:04 -0400 (EDT)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3 (723.2 9-26-1998)) id 8525669C.004E6BB4 ; Tue, 13 Oct 1998 10:16:33 -0400
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: ietf-pkix@imc.org
Message-ID: <8525669C.004BA8A9.00@mta2.lotus.com>
Date: Tue, 13 Oct 1998 15:32:51 +0200
Subject: Question about Basic Authentication Scheme
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA17884
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello,
In draft-ietf-pkix-ipki3cmp-08.txt Certification Management Protocol the basic
authentication scheme is described as:
End entity RA/CA
========== =============
out-of-band distribution of Initial Authentication
Key (IAK) and reference value (RA/CA -> EE)
Key generation
Creation of certification request
Protect request with IAK
-->>--certification request-->>--
verify request
process request
create response
--<<--certification response--<<--
handle response
create confirmation
-->>--confirmation message-->>--
verify confirmation
The Initial Authentication Key (IAK) distributed by the CA/RA is not used in
PKCS#10 described in RFC 2314. In that RFC the process of designing a
certification request will be carried out without the IAK. So why use it?? Isn´t
it better to use the private key for encrypting the certificate request message
rather than using the IAK?
Thanks for answering,
Stefan
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA17353 for ietf-pkix-bks; Tue, 13 Oct 1998 06:07:27 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA17349 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 06:07:25 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDYF1>; Tue, 13 Oct 1998 09:07:00 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9046@WUHER>
From: Sarbari Gupta <sgupta@cygnacom.com>
To: "'David Boyce'" <D.Boyce@isode.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Tue, 13 Oct 1998 09:06:58 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
David,
>>Sarbari also asked about matching against the prefix of the
Issuer name.
>> The short answer appears to be that that is not possible
using the
>>current definition of certificateMatch Matching Rule, since it
always
>>uses an equality match of the Issuer name. A new Matching
Rule (or the
>>present one modified) would have to be defined to support
matching a
>>prefix.
I got the same impression (that an equality match is implied) when I
looked at the X.500 matching rules.
>>(I don't believe specifying 'prefix of Name' is adequate,
since it may
>>not be acceptable to match an Issuer at some greater depth
than
>>intended. Both SubtreeSpecification and NameConstraintsSyntax
permit
>>limits to be placed on the depth of the matching, and also
permit the
>>explicit exclusion of Names which would otherwise match.)
In the context of discussing a mechanism for "selecting" end entity
certificates for use, I do not understand why the 'prefix of name'
criterion is inadequate. On the other hand, if we were discussing
certificate path validation, I would agree with you completely; for CA
certificates in the path to be validated, the NameConstraints extension
with the permitted and excluded subtrees would be absolutely relevant.
Apparently, what is needed to support "selection of a certificate for
use" by secure applications is the ability to draw upon the richness
that is already present in the X.509 v3 certificate syntax.
- Sarbari
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================
> -----Original Message-----
> From: David Boyce [SMTP:D.Boyce@isode.com]
> Sent: Tuesday, October 13, 1998 8:08 AM
> To: Stefan Santesson
> Cc: Sarbari Gupta; 'Dwight Arthur'; ietf-pkix@imc.org
> Subject: Re: NEW Data type for certificate selection ?
>
> Stefan Santesson writes:
> >To your question. Does the X.500 matching rule cover selection by
> issuer
> >name according to your scheme?
> >My conclusion is that it does. You can specify any set of Issuer name
> >attributes you want and you get a match as long as your presented
> >attributes matches those of the target certificate.
> >(If any X.500 expert have another opinion, I would like to here it.)
>
> That appears to be broadly correct. Bear in mind that in order to
> match
> against a set of Issuer names, you will have to be able to specify
> multiple matching rules (one for each Issuer you wish to match
> against);
> a DAP/LDAP search filter allows you to do this, but in the specific
> context of this discussion (selection mechanisms for certificates)
> this
> may not apply.
>
> Sarbari also asked about matching against the prefix of the Issuer
> name.
> The short answer appears to be that that is not possible using the
> current definition of certificateMatch Matching Rule, since it always
> uses an equality match of the Issuer name. A new Matching Rule (or
> the
> present one modified) would have to be defined to support matching a
> prefix.
>
> If such a new prefix matching rule were defined, one way forward is to
> adapt either an X.501 SubtreeSpecification or X.509
> NameConstraintsSyntax to define the limits of matching. The latter,
> being X.509 based anyway, is probably the better choice since it also
> caters for similar matching against subjectAltName and issuerAltName.
>
> (I don't believe specifying 'prefix of Name' is adequate, since it may
> not be acceptable to match an Issuer at some greater depth than
> intended. Both SubtreeSpecification and NameConstraintsSyntax permit
> limits to be placed on the depth of the matching, and also permit the
> explicit exclusion of Names which would otherwise match.)
>
> >And as you see (Dwight), the policy OID is also covered by this
> structure.
>
> Correct; although I have some questions about its definition which I
> raise separately, they don't appear to affect this.
>
> David.
>
> --
> David Boyce
>
> Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
> Email: d.boyce@isode.com Isode's WWW:
> http://www.isode.com/
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16914 for ietf-pkix-bks; Tue, 13 Oct 1998 05:09:43 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16910 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 05:09:41 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 13 Oct 1998 13:09:55 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: ietf-pkix@imc.org
Subject: CertPolicySet definition (was Re: NEW Data type for certificate selection ? )
In-reply-to: Your message of "Mon, 12 Oct 1998 23:40:34 +0200." <3.0.32.19981012233953.00a39cf0@m1.403.telia.com>
Date: Tue, 13 Oct 1998 13:09:54 +0100
Message-ID: <21679.908280594@isode.com>
From: David Boyce <D.Boyce@isode.com>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA16911
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I have a couple of questions regarding the X.509 definition of
CertPolicySet which Stefan quoted.
Stefan Santesson writes:
>The certificateMatch has the following structure (X.509 section
12.7.2):
>
>certificateMatch MATCHING-RULE ::= {
> SYNTAX CertificateAssertion
> ID id-mr-certificateMatch }
>
>CertificateAssertion ::= SEQUENCE {
...
> policy [9] CertPolicySet OPTIONAL,
...
>CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId
Can anyone shed light on why this is called a CertPolicy*Set* when it's
defined as a SEQUENCE OF ?
The only thing I can think of is that the nature of the data is 'SET
OF', with the name reflecting that nature, but that 'SEQUENCE OF' has
been used in the definition of the type in order to avoid introducing
DER-encoding hassles.
> j) policy matches if all of the policy elements identified
> in one of the presented values are contained in the set of
> policyElementIds in any of the policyInformation values in
> the certificate policies extension in the stored attribute
> value; there is no match if there is no certificate policies
> extension in the stored attribute value;
Is there mismatch between this description and the defined syntax for
CertPolicySet here? The presence of the phrase 'in one of the presented
values' seems to indicate a different syntax to the one defined.
It looks to me as if the author had in mind a definition of
CertPolicySet along the lines of
CertPolicySet ::= SET (1..MAX) OF CertPolicyPresentedValues
CertPolicyPresentedValues ::= SET (1..MAX) OF CertPolicyId
(SET OF being regarded as equivalent to SEQUENCE OF for the purposes of
this discussion).
If not, then surely CertPolicySet would comprise the entire 'presented
value', making the phrase 'identified in one of the presented values'
misleading.
Or am I just reading something into the description which isn't there?
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA16904 for ietf-pkix-bks; Tue, 13 Oct 1998 05:08:45 -0700 (PDT)
Received: from woozle.isode.com (woozle.isode.com [193.133.227.19]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA16900 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 05:08:44 -0700 (PDT)
Received: from isode.com (actually dougal.isode.com) by woozle.isode.com (local) with ESMTP; Tue, 13 Oct 1998 13:08:18 +0100
X-Mailer: exmh version 2.0.2 2/24/98
To: Stefan Santesson <stefan@accurata.se>
cc: Sarbari Gupta <sgupta@cygnacom.com>, "'Dwight Arthur'" <dwightarthur@mindspring.com>, ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
In-reply-to: Your message of "Mon, 12 Oct 1998 23:40:34 +0200." <3.0.32.19981012233953.00a39cf0@m1.403.telia.com>
Date: Tue, 13 Oct 1998 13:08:10 +0100
Message-ID: <21672.908280490@isode.com>
From: David Boyce <D.Boyce@isode.com>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA16901
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Stefan Santesson writes:
>To your question. Does the X.500 matching rule cover selection by
issuer
>name according to your scheme?
>My conclusion is that it does. You can specify any set of Issuer name
>attributes you want and you get a match as long as your presented
>attributes matches those of the target certificate.
>(If any X.500 expert have another opinion, I would like to here it.)
That appears to be broadly correct. Bear in mind that in order to match
against a set of Issuer names, you will have to be able to specify
multiple matching rules (one for each Issuer you wish to match against);
a DAP/LDAP search filter allows you to do this, but in the specific
context of this discussion (selection mechanisms for certificates) this
may not apply.
Sarbari also asked about matching against the prefix of the Issuer name.
The short answer appears to be that that is not possible using the
current definition of certificateMatch Matching Rule, since it always
uses an equality match of the Issuer name. A new Matching Rule (or the
present one modified) would have to be defined to support matching a
prefix.
If such a new prefix matching rule were defined, one way forward is to
adapt either an X.501 SubtreeSpecification or X.509
NameConstraintsSyntax to define the limits of matching. The latter,
being X.509 based anyway, is probably the better choice since it also
caters for similar matching against subjectAltName and issuerAltName.
(I don't believe specifying 'prefix of Name' is adequate, since it may
not be acceptable to match an Issuer at some greater depth than
intended. Both SubtreeSpecification and NameConstraintsSyntax permit
limits to be placed on the depth of the matching, and also permit the
explicit exclusion of Names which would otherwise match.)
>And as you see (Dwight), the policy OID is also covered by this
structure.
Correct; although I have some questions about its definition which I
raise separately, they don't appear to affect this.
David.
--
David Boyce
Tel: +44 181 332 9091 Richmond, Surrey, ENGLAND
Email: d.boyce@isode.com Isode's WWW: http://www.isode.com/
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA16330 for ietf-pkix-bks; Tue, 13 Oct 1998 03:30:38 -0700 (PDT)
Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA16326 for <ietf-pkix@imc.org>; Tue, 13 Oct 1998 03:30:34 -0700 (PDT)
From: r1naray@in.ibm.com
Received: from f03n05e.au.ibm.com (f03n05s.au.ibm.com [9.185.166.73]) by ausmtp02.au.ibm.com (1.0.0) with ESMTP id UAA55482; Tue, 13 Oct 1998 20:28:49 +1000
Received: from au.ibm.com (f06n01s [9.185.166.65]) by f03n05e.au.ibm.com (8.8.7/8.8.7) with SMTP id UAA44954; Tue, 13 Oct 1998 20:31:03 +1000
Received: by au.ibm.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id CA25669C.0039C2F2 ; Tue, 13 Oct 1998 20:30:54 +1000
X-Lotus-FromDomain: IBMIN@IBMAU
To: stefan@accurata.se
cc: sgupta@cygnacom.com, dwightarthur@mindspring.com, ietf-pkix@imc.org
Message-ID: <CA25669C.0039C1C4.00@au.ibm.com>
Date: Tue, 13 Oct 1998 15:55:04 +0530
Subject: RE: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello,
A sort of tangential question.
I'm not sure if you have glanced through the I-D on Atomic Certificates.
I was just wondering if anyone had any suggestions as to negotiation of
required Attributes for such a setup.
imho, this concept permits hiding from the user lots of gory details about
required attributes, since the setup
permits it to be automated.
There are two questions here :
Negotiating the trusted root - (will affect chaining, as has been pointed
out)
Negotiating the required Attributes - (will be very different with Atomic
Certificates, imho)
We are thinking of a trial run on Atomic Certificates, and for that, we
need to have a pilot protocol that uses it.
Any comments are welcome.
Thanks,
Regards,
narry
PS: for those who have not read the draft at
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
here's a very brief writeup of the concept.
Atomic Certificates are basically X.509v3 certificates containing NO
subject Name, and containing exactly ONE
extension, with criticality bit set to true. The peer is expected to
collect Attribute Certificates, for different attributes
signed by different CAs over a period of time. The peer would mix-n-match
and send to the other peer ONLY those
certificates that are required by the other peer, for validation. All the
Atomic Certificates have the same public key.
The whole thing centers around the concept that Certificates are not
documents that identify an entity, but are
documents that attest to an attribute of an entity.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21453 for ietf-pkix-bks; Mon, 12 Oct 1998 14:43:08 -0700 (PDT)
Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21449 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 14:43:07 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maild.telia.com (8.8.8/8.8.8) with ESMTP id XAA25418; Mon, 12 Oct 1998 23:43:54 +0200 (CEST)
Received: from stefans (t3o68p97.telia.com [62.20.139.97]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id XAA03765; Mon, 12 Oct 1998 23:43:48 +0200 (CEST)
Message-Id: <3.0.32.19981012233953.00a39cf0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 12 Oct 1998 23:40:34 +0200
To: Sarbari Gupta <sgupta@cygnacom.com>, "'Dwight Arthur'" <dwightarthur@mindspring.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: NEW Data type for certificate selection ?
Cc: ietf-pkix@imc.org
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id OAA21450
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Sarbari,
As I see it I would not rule out any select criteria and say that in
general that criteria is better than another.
So personally I recognize your criteria solution as a very valid one in
some situations, as I also recognize Dwights policy OID as a valid criteria
in other cases.
To your question. Does the X.500 matching rule cover selection by issuer
name according to your scheme?
My conclusion is that it does. You can specify any set of Issuer name
attributes you want and you get a match as long as your presented
attributes matches those of the target certificate.
(If any X.500 expert have another opinion, I would like to here it.)
And as you see (Dwight), the policy OID is also covered by this structure.
The certificateMatch has the following structure (X.509 section 12.7.2):
certificateMatch MATCHING-RULE ::= {
SYNTAX CertificateAssertion
ID id-mr-certificateMatch }
CertificateAssertion ::= SEQUENCE {
serialNumber [0] CertificateSerialNumber OPTIONAL,
issuer [1] Name OPTIONAL,
subjectKeyIdentifier [2] SubjectKeyIdentifier OPTIONAL,
authorityKeyIdentifier [3] AuthorityKeyIdentifier OPTIONAL,
certificateValid [4] Time OPTIONAL,
privateKeyValid [5] GeneralizedTime OPTIONAL,
subjectPublicKeyAlgID [6] OBJECT IDENTIFIER OPTIONAL,
keyUsage [7] KeyUsage OPTIONAL,
subjectAltName [8] AltNameType OPTIONAL,
policy [9] CertPolicySet OPTIONAL,
pathToName [10] Name OPTIONAL }
AltNameType ::= CHOICE {
builtinNameForm ENUMERATED {
rfc822Name (1),
dNSName (2),
x400Address (3),
directoryName (4),
ediPartyName (5),
uniformResourceIdentifier (6),
iPAddress (7),
registeredId (8) },
otherNameForm OBJECT IDENTIFIER }
CertPolicySet ::= SEQUENCE (1..MAX) OF CertPolicyId
The following is defined in X.509, concerning Issuer name and policy OID:
This matching rule returns TRUE if all of the components
that are present in the presented value match the corresponding
components of the attribute value, as follows:
b) issuer matches if the value of this component in the
attribute value equals that in the presented
value;
j) policy matches if all of the policy elements identified
in one of the presented values are contained in the set of
policyElementIds in any of the policyInformation values in
the certificate policies extension in the stored attribute
value; there is no match if there is no certificate policies
extension in the stored attribute value;
/Stefan
At 11:28 AM 10/12/98 -0400, Sarbari Gupta wrote:
>I have been following this thread with great interest. Since the thread
>was rekindled, I wanted to offer another usage model that needs a
>slightly different selection criterion. I was not sure whether this
>model was discussed before on this list.
>
>One of the certificate selection mechanisms in use today is based on
>matching the issuer name. SSL implementations allow this form of
>selection. There is another variant of this model that may also be
>useful. In this variant, the certificate selection is based on a prefix
>of the issuer name. For example, the selection may be done based only on
>the country name and the organization name components of the issuer DN.
>Thus, if a large organization has multiple CAs, the selection criteria
>may logically be "a certificate issued by the organization" instead of
>the more restrictive "a certificate issued by a particular CA within the
>organization".
>
>Do the X.500 matching rules support this kind of selection? This model
>may be useful for SSL connections. It will certainly be useful for
>S/MIME implementations; if the peer's certificate is part of an
>organization-specific PKI, the S/MIME implementation could conceivably
>select an appropriate certificate (for the user) based on a prefix of
>the issuer DN of the peer's certificate. Ideally, the S/MIME
>implementation would support a configurable set of prioritized selection
>criteria that allows the automatic selection of one amongst a set of
>user certificates.
>
>- Sarbari Gupta
>=============================
>Sarbari Gupta
>CygnaCom Solutions
>(703)848-0883 ext 217
>sgupta@cygnacom.com
>=============================
>
>> -----Original Message-----
>> From: Dwight Arthur [SMTP:dwightarthur@mindspring.com]
>> Sent: Friday, October 09, 1998 3:31 PM
>> To: Stefan Santesson; Alan Lloyd; ietf-pkix@imc.org;
>> list@seis.nc-forum.com; cert-talk@structuredarts.com
>> Subject: RE: NEW Data type for certificate selection ?
>>
>> I apologize for posting this after the thread has been summarized and
>> closed. The summary did not mention the part of the discussion that
>> suggested policy oids as the basis for a solution. I would like to
>> expand on
>> this.
>>
>> Selecting the right certificate is an instance of the general problem
>> of
>> building the right chain. This problem, in turn, needs to be closely
>> aligned
>> with the trust model being used. Many or most of the examples given
>> were
>> drawn from the so-called "open" or public model in which parties with
>> no
>> prior relationship (NPR) establish a (very low) level of trust because
>> someone in the public CA business has issued a certificate asserting
>> that
>> the subject produced documentary evidence of a certain identity.
>>
>> Other models, imho more suitable for significant business use, are:
>>
>> a. The parties have an existing business relationship and one of the
>> parties
>> has issued the other a certificate as a token of that relationship.
>> This
>> certificate is then to be used for access control and signing in
>> facilities
>> offered by the issuer. I believe that Netscape's crypto.signText()
>> function
>> provides a fully satisfactory method of saying, "I will only accept
>> certificates I issued." In addition, the emerging AADS approach
>> supports
>> this without requiring actual certificates.
>>
>> b. The parties share a relationship with an intermediary (bank,
>> finance
>> company, expeditor, factor, etc) who guarantees (for a fee) the
>> parties to
>> each other. Again, crypto.signText() or equivalents could be used to
>> say, "I
>> am looking for a certificate issued by MonsterBank" or a slightly more
>> complex form of AADS could be used.
>>
>> c. The parties share membership in an organization which, through
>> member
>> agreements, binds all parties to acceptable business terms and risk
>> management procedures. Similar procedures can be used as in (b): "I am
>> looking for your certificate issued by S.W.I.F.T."
>>
>> d. Each party has a relationship with an intermediary that's a member
>> of an
>> organization such as described in (c). Now we are looking for
>> something more
>> complex, like, "I will accept and debit card issued by any bank that
>> participates in NYCE or CIRRUS but not STAR." These relationships
>> should
>> imho _not_ be recorded in the client certificates as the data may
>> change
>> during the life of the certificate. Nor, imho, should the server send
>> a list
>> of the thousands of member banks as a part of its signing request.
>> Instead,
>> CIRRUS etc should each establish a certificate policy and form
>> contracts
>> with each participating bank binding it to the policy. It should
>> register
>> the policy and obtain an OID, then allow each member bank to issue
>> certificates bearing the OID. Your bank may then issue a certificate
>> to you
>> carrying the CIRRUS and STAR oids. I may send a signing request
>> calling for
>> certificates bearing NYCE or CIRRUS OIDs. Your browser would then
>> respond
>> with your bank certificate because the CIRRUS OID matched. If you have
>> several matching certificates (because, for example, you have several
>> bank
>> cards) the browser would ask you to chose, but the list of
>> alternatives
>> would be only your CIRRUS or NYCE bank cards and would exclude your
>> drivers
>> license, your library card, etc. Fraudulent certificates issued by
>> BongoCerts with the NYCE OID would be defeated either by (1) OCSP to
>> the
>> NYCE responder, or (2) your browser sends a certificate chain
>> including your
>> certificate from your bank and your bank's certificate from NYCE.
>>
>> e. Finally, the model that I personally believe will account for the
>> most
>> profitable segment of eCommerce: the employee card. I do not want to
>> offer
>> my employee a certificate for accessing our bank, a separate
>> certificate for
>> accessing our broker, a separate certificate for accessing our office
>> supplies vendor, and a separate certificate for accessing her 401K
>> plan.
>> (Too much overhead, doesn't fit on a smartcard, too much risk that we
>> l miss
>> one when it's time to revoke.) Instead, I want to offer every employee
>> a
>> certificate that says, "this is an employee of this company" that
>> allows
>> access to the benefits plans, the ability to initiate (but not
>> authorize)
>> office supplies purchases, and access to the appropriate gender
>> washrooms. I
>> may also offer some employees a different certificate (or an attribute
>> certificate that supplements the identity certificate) that includes a
>> policy OID that says, this is an officer, the company stands behind
>> and
>> honors commitments made by this person. In my cross-certification with
>> the
>> office supplies vendor, I can map my "this is an officer" policy with
>> the
>> vendor's "authorized approver of purchases" policy. Further, I could
>> map my
>> "this is an officer" policy to my bank's "authorized signer" policy or
>> I
>> could create a different "authorized for high value financial
>> transactions"
>> policy and map it to the appropriate policies of my bank and my
>> broker.
>> (Note, I am not inventing this policy mapping stuff, it's straight out
>> of
>> X.509) Now, when some other bank sends my employee a signing request
>> it asks
>> for something like "a certificate bearing the authorized signer OID
>> issued
>> by a bank that's a member of some ACH network." In this case, it is
>> necessary but not sufficient to select the right certificate. It is
>> further
>> necessary to build a chain of certificates, leading back to some
>> appropriate
>> root, with the specifies policies (or mapped policies) at every
>> certificate
>> in the chain.
>>
>> Note that I am _not_ advocating roles or authorizations in the
>> certificate.
>> I am advocating policies, represented by OIDs, that specify issues
>> like
>> acceptable uses of certificates, applicable communities of interest,
>> etc.
>> where all subjects, issuers, and authorized relying parties are bound
>> by
>> contract to the policy.
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21058 for ietf-pkix-bks; Mon, 12 Oct 1998 14:03:01 -0700 (PDT)
Received: from relay.hq.tis.com (firewall-user@relay.hq.tis.com [192.94.214.100]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21054 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 14:02:59 -0700 (PDT)
Received: by relay.hq.tis.com; id RAA03301; Mon, 12 Oct 1998 17:08:03 -0400 (EDT)
Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.1) id xma003291; Mon, 12 Oct 98 17:07:55 -0400
Received: from balenson.hq.tis.com (balenson.hq.tis.com [10.33.80.11]) by clipper.hq.tis.com (8.9.1/8.9.1) with SMTP id RAA18692; Mon, 12 Oct 1998 17:02:52 -0400 (EDT)
Message-Id: <199810122102.RAA18692@clipper.hq.tis.com>
X-Sender: balenson@pop.hq.tis.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Mon, 12 Oct 1998 17:03:51 -0400
To: ietf-pkix@imc.org
From: "David M. Balenson" <balenson@tis.com>
Subject: NDSS '99 Registration Now Taking Place!!
Cc: balenson@tis.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
R E G I S T E R N O W ! !
THE INTERNET SOCIETY'S
1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
February 3-5, 1999
Catamaran Resort Hotel
San Diego, California
General Chair: Steve Welke, Trusted Computer Solutions
Program Chairs: Steve Kent, BBN Technologies
Gene Tsudik, USC/Information Sciences Institute
ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99
EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 1999
The 6th annual NDSS Symposium brings together researchers,
implementers, and users of network and distributed system security
technologies to discuss today's important security issues and
challenges. The Symposium provides a mix of technical papers and
panel presentations that describe promising new approaches to
security problems that are practical and, to the extent possible,
have been implemented. NDSS fosters the exchange of technical
information and encourages the Internet community to deploy available
security technologies and develop new solutions to unsolved problems.
KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems. Co-author of
"Privacy on the Line: The Politics of Wiretapping and Encryption."
THIS YEAR'S TOPICS INCLUDE:
- Secure Password-Based Protocol for Downloading a Private Key
- A Real-World Analysis of Kerberos Password Security
- Secure Remote Access to an Internal Web Server
- Security and the User
- Experimenting with Shared Generation of RSA Keys
- Addressing the Problem of Undetected Signature Key Compromise
- Practical Approach to Anonymity in Large Scale Electronic Voting Schemes
- New Approaches to BGP Security
- Distributed Policy Management for Java 1.2
- Distributed Execution with Remote Audit
- Trust-Based Authentication in Open Networks
- A Network Security Research Agenda
- PGRIP: PNNI Global Routing Infrastructure Protection
- A Cryptographic Countermeasure Against Connection Depletion Attacks
- IPSec: Friend or Foe?
EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Windows NT Security
- Cryptography
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)
- JAVA Security
FOR MORE INFORMATION contact the Internet Society:
Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
Phone: +1-703-648-9888
Fax: +1-703-648-9887
E-mail: ndss99reg@isoc.org
URL: http://www.isoc.org/ndss99/
SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high
visibility event. Contact Carla Rosenfeld at the Internet Society
at +1-703-648-9888 or send e-mail to carla@isoc.org.
THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.
----------------------------------------------------------------------------
David M. Balenson, Publicity Chair, NDSS '99
TIS Labs at Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738 USA
balenson@tis.com; 301-854-5358; fax 301-854-5363
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA18151 for ietf-pkix-bks; Mon, 12 Oct 1998 10:45:57 -0700 (PDT)
Received: from eng1.certicom.com (mailhost.certicom.com [209.121.99.2]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA18147 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 10:45:55 -0700 (PDT)
Received: from domino2.certicom.com (domino2.certicom.com [10.0.1.25]) by eng1.certicom.com (8.8.7/8.8.7) with SMTP id NAA20012; Mon, 12 Oct 1998 13:46:50 -0400 (EDT) (envelope-from plambert@certicom.com)
Received: by domino2.certicom.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id 8525669B.0061B0AD ; Mon, 12 Oct 1998 13:47:02 -0400
X-Lotus-FromDomain: CERTICOM
From: "Paul Lambert" <plambert@certicom.com>
To: "Robert W. Shirey" <rshirey@bbn.com>
cc: ietf-pkix@imc.org
Message-ID: <8825669B.006018AF.00@domino2.certicom.com>
Date: Mon, 12 Oct 1998 10:33:35 -0700
Subject: Re: Photuris
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Rob,
Photuris was not in PKIX,, but was an IPsec document. There is good
information on Photuris at:
http://wserver.physnet.uni-hamburg.de/provos/photuris/
I'm not sure if this contains the very latest draft.
Regards,
Paul A. Lambert
Certicom Corp.
San Mateo, CA
+1650-312-7996
"Robert W. Shirey" <rshirey@bbn.com> on 10/12/98 08:26:19 AM
To: ietf-pkix@imc.org
cc: (bcc: Paul Lambert/Certicom)
Subject: Photuris
Is the latest draft for Photuris still posted somewhere where I can
download it?
Regards, -Rob-
rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766
Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200
1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA17124 for ietf-pkix-bks; Mon, 12 Oct 1998 08:30:57 -0700 (PDT)
Received: from rosslyn.BBN.COM (ROSSLYN.BBN.COM [192.1.7.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA17119 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 08:30:56 -0700 (PDT)
Received: from RSHIREY.BBN.COM by rosslyn.BBN.COM id aa24914; 12 Oct 98 11:35 EDT
X-Sender: rshirey@rosslyn.bbn.com
Message-Id: <v03110700b247cfefad24@[192.1.7.164]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 12 Oct 1998 11:26:19 -0400
To: ietf-pkix@imc.org
From: "Robert W. Shirey" <rshirey@bbn.com>
Subject: Photuris
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Is the latest draft for Photuris still posted somewhere where I can
download it?
Regards, -Rob-
rshirey@bbn.com, Phone 703-284-4641, Reception 284-4600, Fax 284-2766
Robert W. Shirey, GTE Internetworking - Mail Stop 30/12B2, Suite 1200
1300 North Seventeenth Street, Arlington, Virginia 22209-3801 USA
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA17085 for ietf-pkix-bks; Mon, 12 Oct 1998 08:29:39 -0700 (PDT)
Received: from wuher.cygnacom.com (endor.cygnacom.com [205.177.169.102]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA17081 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 08:29:37 -0700 (PDT)
Received: by WUHER with Internet Mail Service (5.0.1458.49) id <T19XDX9Z>; Mon, 12 Oct 1998 11:28:44 -0400
Message-ID: <51BF55C30B4FD1118B4900207812701E1F9045@WUHER>
From: Sarbari Gupta <sgupta@cygnacom.com>
To: "'Dwight Arthur'" <dwightarthur@mindspring.com>
Cc: ietf-pkix@imc.org
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 12 Oct 1998 11:28:43 -0400
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I have been following this thread with great interest. Since the thread
was rekindled, I wanted to offer another usage model that needs a
slightly different selection criterion. I was not sure whether this
model was discussed before on this list.
One of the certificate selection mechanisms in use today is based on
matching the issuer name. SSL implementations allow this form of
selection. There is another variant of this model that may also be
useful. In this variant, the certificate selection is based on a prefix
of the issuer name. For example, the selection may be done based only on
the country name and the organization name components of the issuer DN.
Thus, if a large organization has multiple CAs, the selection criteria
may logically be "a certificate issued by the organization" instead of
the more restrictive "a certificate issued by a particular CA within the
organization".
Do the X.500 matching rules support this kind of selection? This model
may be useful for SSL connections. It will certainly be useful for
S/MIME implementations; if the peer's certificate is part of an
organization-specific PKI, the S/MIME implementation could conceivably
select an appropriate certificate (for the user) based on a prefix of
the issuer DN of the peer's certificate. Ideally, the S/MIME
implementation would support a configurable set of prioritized selection
criteria that allows the automatic selection of one amongst a set of
user certificates.
- Sarbari Gupta
=============================
Sarbari Gupta
CygnaCom Solutions
(703)848-0883 ext 217
sgupta@cygnacom.com
=============================
> -----Original Message-----
> From: Dwight Arthur [SMTP:dwightarthur@mindspring.com]
> Sent: Friday, October 09, 1998 3:31 PM
> To: Stefan Santesson; Alan Lloyd; ietf-pkix@imc.org;
> list@seis.nc-forum.com; cert-talk@structuredarts.com
> Subject: RE: NEW Data type for certificate selection ?
>
> I apologize for posting this after the thread has been summarized and
> closed. The summary did not mention the part of the discussion that
> suggested policy oids as the basis for a solution. I would like to
> expand on
> this.
>
> Selecting the right certificate is an instance of the general problem
> of
> building the right chain. This problem, in turn, needs to be closely
> aligned
> with the trust model being used. Many or most of the examples given
> were
> drawn from the so-called "open" or public model in which parties with
> no
> prior relationship (NPR) establish a (very low) level of trust because
> someone in the public CA business has issued a certificate asserting
> that
> the subject produced documentary evidence of a certain identity.
>
> Other models, imho more suitable for significant business use, are:
>
> a. The parties have an existing business relationship and one of the
> parties
> has issued the other a certificate as a token of that relationship.
> This
> certificate is then to be used for access control and signing in
> facilities
> offered by the issuer. I believe that Netscape's crypto.signText()
> function
> provides a fully satisfactory method of saying, "I will only accept
> certificates I issued." In addition, the emerging AADS approach
> supports
> this without requiring actual certificates.
>
> b. The parties share a relationship with an intermediary (bank,
> finance
> company, expeditor, factor, etc) who guarantees (for a fee) the
> parties to
> each other. Again, crypto.signText() or equivalents could be used to
> say, "I
> am looking for a certificate issued by MonsterBank" or a slightly more
> complex form of AADS could be used.
>
> c. The parties share membership in an organization which, through
> member
> agreements, binds all parties to acceptable business terms and risk
> management procedures. Similar procedures can be used as in (b): "I am
> looking for your certificate issued by S.W.I.F.T."
>
> d. Each party has a relationship with an intermediary that's a member
> of an
> organization such as described in (c). Now we are looking for
> something more
> complex, like, "I will accept and debit card issued by any bank that
> participates in NYCE or CIRRUS but not STAR." These relationships
> should
> imho _not_ be recorded in the client certificates as the data may
> change
> during the life of the certificate. Nor, imho, should the server send
> a list
> of the thousands of member banks as a part of its signing request.
> Instead,
> CIRRUS etc should each establish a certificate policy and form
> contracts
> with each participating bank binding it to the policy. It should
> register
> the policy and obtain an OID, then allow each member bank to issue
> certificates bearing the OID. Your bank may then issue a certificate
> to you
> carrying the CIRRUS and STAR oids. I may send a signing request
> calling for
> certificates bearing NYCE or CIRRUS OIDs. Your browser would then
> respond
> with your bank certificate because the CIRRUS OID matched. If you have
> several matching certificates (because, for example, you have several
> bank
> cards) the browser would ask you to chose, but the list of
> alternatives
> would be only your CIRRUS or NYCE bank cards and would exclude your
> drivers
> license, your library card, etc. Fraudulent certificates issued by
> BongoCerts with the NYCE OID would be defeated either by (1) OCSP to
> the
> NYCE responder, or (2) your browser sends a certificate chain
> including your
> certificate from your bank and your bank's certificate from NYCE.
>
> e. Finally, the model that I personally believe will account for the
> most
> profitable segment of eCommerce: the employee card. I do not want to
> offer
> my employee a certificate for accessing our bank, a separate
> certificate for
> accessing our broker, a separate certificate for accessing our office
> supplies vendor, and a separate certificate for accessing her 401K
> plan.
> (Too much overhead, doesn't fit on a smartcard, too much risk that we
> l miss
> one when it's time to revoke.) Instead, I want to offer every employee
> a
> certificate that says, "this is an employee of this company" that
> allows
> access to the benefits plans, the ability to initiate (but not
> authorize)
> office supplies purchases, and access to the appropriate gender
> washrooms. I
> may also offer some employees a different certificate (or an attribute
> certificate that supplements the identity certificate) that includes a
> policy OID that says, this is an officer, the company stands behind
> and
> honors commitments made by this person. In my cross-certification with
> the
> office supplies vendor, I can map my "this is an officer" policy with
> the
> vendor's "authorized approver of purchases" policy. Further, I could
> map my
> "this is an officer" policy to my bank's "authorized signer" policy or
> I
> could create a different "authorized for high value financial
> transactions"
> policy and map it to the appropriate policies of my bank and my
> broker.
> (Note, I am not inventing this policy mapping stuff, it's straight out
> of
> X.509) Now, when some other bank sends my employee a signing request
> it asks
> for something like "a certificate bearing the authorized signer OID
> issued
> by a bank that's a member of some ACH network." In this case, it is
> necessary but not sufficient to select the right certificate. It is
> further
> necessary to build a chain of certificates, leading back to some
> appropriate
> root, with the specifies policies (or mapped policies) at every
> certificate
> in the chain.
>
> Note that I am _not_ advocating roles or authorizations in the
> certificate.
> I am advocating policies, represented by OIDs, that specify issues
> like
> acceptable uses of certificates, applicable communities of interest,
> etc.
> where all subjects, issuers, and authorized relying parties are bound
> by
> contract to the policy.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA15343 for ietf-pkix-bks; Mon, 12 Oct 1998 04:06:47 -0700 (PDT)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA15339 for <ietf-pkix@imc.org>; Mon, 12 Oct 1998 04:06:45 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id NAA10967; Mon, 12 Oct 1998 13:06:23 +0200 (CEST)
Received: from stefans (t2o68p80.telia.com [62.20.138.200]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id NAA06826; Mon, 12 Oct 1998 13:06:04 +0200 (CEST)
Message-Id: <3.0.32.19981012125924.00a33b80@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 12 Oct 1998 13:03:04 +0200
To: Stephen Kent <kent@bbn.com>, "Dwight Arthur" <dwightarthur@mindspring.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: NEW Data type for certificate selection ?
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id EAA15340
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dwight and Stephen,
Thank you Dwight for valuable information.
Just some remarks.
1) I did not focus on a prticular selecting mechanism such as policy OID
over Issuer Name. I'm looking for selective mechanisms that will work
generally in standard products in closed and in open environments.
2) Selection by policy OID is covered by the discussed X.500
certificateMatch rule
3) Thank you for pointing out that Netscape have mechanisms for slecting
certificate by issuer in crypto.signText(). This was new to mee. I will
check this within our projects.
3) My primary concern is how to manage certificate selection by using
standard products. I'm not focusing on whether this is a closed or an open
PKI. In my cases the PKI is closed in most cases but the problem is still
relevant.
/Stefan Santesson
At 12:13 PM 10/11/98 -0400, Stephen Kent wrote:
>Dwight,
>
>Thanks for a good characterization of the underlying assumptions that have
>been driving much of this discussion. I agree completely! In a completely
>open, public PKI model, it's very hard to find the "right" certificate and
>I agree that this sort of PKI model is questionable for many reasons, not
>just in a business context. I'll send you a paper on the topic from last
>fall, separately, that I believe you will find consistent with the views
>articulated in your message.
>
>Steve
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA20088 for ietf-pkix-bks; Sun, 11 Oct 1998 09:12:50 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA20084 for <ietf-pkix@imc.org>; Sun, 11 Oct 1998 09:12:49 -0700 (PDT)
Received: from [128.33.238.25] (TC085.BBN.COM [128.33.238.85]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA20787; Sun, 11 Oct 1998 12:13:01 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com
Message-Id: <v04011704b24688f40e3f@[128.33.238.25]>
In-Reply-To: <000401bdf3bb$5f6f3740$3b8556d1@ns95lap005.nscc.com>
References: <3.0.32.19980928111642.00a76390@m1.403.telia.com>
Date: Sun, 11 Oct 1998 12:13:05 -0400
To: "Dwight Arthur" <dwightarthur@mindspring.com>
From: Stephen Kent <kent@bbn.com>
Subject: RE: NEW Data type for certificate selection ?
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Dwight,
Thanks for a good characterization of the underlying assumptions that have
been driving much of this discussion. I agree completely! In a completely
open, public PKI model, it's very hard to find the "right" certificate and
I agree that this sort of PKI model is questionable for many reasons, not
just in a business context. I'll send you a paper on the topic from last
fall, separately, that I believe you will find consistent with the views
articulated in your message.
Steve
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04708 for ietf-pkix-bks; Sat, 10 Oct 1998 07:34:53 -0700 (PDT)
Received: from vop.nucleus.com (vop.nucleus.com [207.34.93.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04704 for <ietf-pkix@imc.org>; Sat, 10 Oct 1998 07:34:52 -0700 (PDT)
Received: from loki (unverified [207.34.67.172]) by vop.nucleus.com (Vircom SMTPRS 1.0.1691) with SMTP id <B0003902608@vop.nucleus.com>; Sat, 10 Oct 1998 08:35:15 -0600
Message-Id: <3.0.5.32.19981010083939.009ca1b0@dreamwvr.com>
X-Sender: dreamwvr@dreamwvr.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 10 Oct 1998 08:39:39 -0600
To: pgut001@cs.auckland.ac.nz, cert-talk@structuredarts.com, ietf-pkix@imc.org
From: dreamwvr <dreamwvr@dreamwvr.com>
Subject: CERT
In-Reply-To: <199810100020.RAA23723@gateway-ext.StructuredArts.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
hi,
i am looking for some URLS that describe how to setup your own certificate
server on linux. I am interested for test purposes only. Also is this a
howto that describes how to add additional non default certificates to
communicator? All your assistance is appreciated.
Regards,
dreamwvr@dreamwvr.com
Reuters, London, February 29, 1998:
Scientists have announced discovering a meteorite which will strike the
earth in March, 2028. Millions of UNIX coders expressed relief for being
spared the UNIX epoch "crisis" of 2038.
_______________________________________________________________________
DREAMWVR.COM - TOTAL WEB INTEGRATION, DEVELOPMENT, DESIGN SERVICES.
Featuring Website Development and Web Strategies of a TOP Developer
<http://www.dreamwvr.com/dynamicduo.html> <mailto:dreamwvr@dreamwvr.com>
"As Unique as the Company You Keep." "===0 PGP Key Available
________________________________________________________________________
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA11978 for ietf-pkix-bks; Fri, 9 Oct 1998 18:12:26 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA11974 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 18:12:23 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id OAA16127; Sat, 10 Oct 1998 14:12:40 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz)
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90798195929090>; Sat, 10 Oct 1998 14:12:39 (NZDT)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cert-talk@structuredarts.com, ietf-pkix@imc.org
Subject: Interesting(?) sample certificate
Reply-To: pgut001@cs.auckland.ac.nz
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 10 Oct 1998 14:12:39 (NZDT)
Message-ID: <90798195929090@cs26.cs.auckland.ac.nz>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
For your edification I have prepared a sample cert which people may find
interesting. You can find it at
http://www.cs.auckland.ac.nz/~pgut001/pubs/dave.der, with the issuing cert at
http://www.cs.auckland.ac.nz/~pgut001/pubs/dave_ca.der. An ASN.1 dump of the
cert is:
SEQUENCE {
SEQUENCE {
[0] {
INTEGER 2
}
INTEGER 9188644
SEQUENCE {
OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER countryName (2 5 4 6)
PrintableString 'NZ'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
TeletexString 'Dave's Wetaburgers and CA'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
PrintableString 'Certification Division'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
PrintableString 'Dave Himself'
}
}
}
SEQUENCE {
UTCTime '981007082404Z'
UTCTime '990912032309Z'
}
SEQUENCE {
SET {
SEQUENCE {
OBJECT IDENTIFIER countryName (2 5 4 6)
PrintableString 'NZ'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationName (2 5 4 10)
TeletexString 'Dave's Wetaburgers'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
PrintableString 'Procurement'
}
}
SET {
SEQUENCE {
OBJECT IDENTIFIER commonName (2 5 4 3)
PrintableString 'Dave Smith'
}
}
}
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
NULL
}
BIT STRING 0 unused bits
30 48 02 41 00 C8 E1 BB 88 F5 87 48 7C A7 96 00
50 A5 03 13 BA 81 7C 8F DD 55 FB 88 4B F4 82 6D
15 82 D1 ED 2D 69 EC 65 43 C8 70 7C 0F 8B E9 EE
B5 B7 96 C5 4C 3B 95 71 D2 A7 23 80 89 0B 48 B5
2B 29 C9 5F 1D 02 03 01 00 01
}
[3] {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER keyUsage (2 5 29 15)
BOOLEAN TRUE
OCTET STRING, encapsulates {
BIT STRING 5 unused bits
'111'B
}
}
SEQUENCE {
OBJECT IDENTIFIER subjectAltName (2 5 29 17)
OCTET STRING, encapsulates {
SEQUENCE {
[0] {
OBJECT IDENTIFIER mpeg-1 (1 3 6 1 4 1 3029 42 11172 1)
[0] {
OCTET STRING
00 00 01 B3 16 01 20 83 02 AE 60 A4 00 00 01 B8
00 08 00 00 00 00 01 00 00 8A 75 00 00 00 01 01
2B FB AA 3E 68 96 93 A7 7E D3 7E F7 90 90 18 B0
60 C5 EE D9 B8 7C D9 77 1D 73 52 1A F4 06 F4 F5
F3 5E 9A 92 5E 10 00 93 38 06 45 F0 46 FA 2F 02
50 19 57 BB 75 DF 3B 04 02 92 12 4B 00 BB F4 23
A7 F0 2A 59 CB 03 C5 50 4C 24 F1 DB 1F 6E 02 7C
E4 C4 87 11 EA EF 22 05 00 27 0E 49 1B DF 67 28
[ Another 1220786 bytes skipped ]
}
}
[1] 'dave@wetas-r-us.com'
[6] 'http://www.wetas-r-us.com'
}
}
}
SEQUENCE {
OBJECT IDENTIFIER basicConstraints (2 5 29 19)
BOOLEAN TRUE
OCTET STRING, encapsulates {
SEQUENCE {}
}
}
}
}
}
SEQUENCE {
OBJECT IDENTIFIER sha1withRSAEncryption (1 2 840 113549 1 1 5)
NULL
}
BIT STRING 0 unused bits
78 B3 5F 74 E7 23 08 C2 FA E2 38 7F DE 08 F6 B2
59 E9 3F BE B9 8F 18 00 F5 72 47 FA 99 32 DB C1
32 BC 1E 9B 36 95 AD 2D 92 8C B3 B1 D4 71 23 FF
5E 73 48 47 F5 C4 5B 6F 40 76 81 78 28 8D D8 C0
}
Peter.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA10870 for ietf-pkix-bks; Fri, 9 Oct 1998 14:50:42 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA10866 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 14:50:40 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id TAA00707; Fri, 9 Oct 1998 19:51:07 -0200
Date: Fri, 9 Oct 1998 19:51:06 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Phillip M Hallam-Baker <pbaker@verisign.com>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, ietf-pkix@imc.org, Einar Stefferud <Stef@nma.com>
Subject: RE: Common misconception #10. was RE: NEW Data type forcertificate
In-Reply-To: <001801bdf3c0$aa5f88e0$9d07a8c0@pbaker-pc.verisign.com>
Message-ID: <Pine.LNX.4.02.9810091850060.542-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Fri, 9 Oct 1998, Phillip M Hallam-Baker wrote:
> Ed Gerck wrote:
>
>> My assertion was "every PKIX CA must inevitably disclaim all legal
>> liability to the user" -- not to the subscriber.
>
>A statement which is untrue, completely and utterly wrong.
>
Denial is good. But it is no more than a marketing technique when
Verisign's own warranty declaration and CPS say what I affirm and you
deny.
I also note, for the record and I have already made that clear, what
is called a CA "user" is not the subscriber that buys the cert
services from the CA, but the Joe Doe that needs to rely on the cert
presented by the subscriber and that has no relationship whatsoever
with the CA. Certainly, the majority of cases in international trade,
since not all users will also be customers of the very same CA.
This question gains in importance as we remember that there is no
international law system that uniquely defines matters, not even in
the same country. So, a cert user represents an open risk also in the
legal sense, and not only in terms of key-snatching, virus, etc.
Given the overabundance of lawyers in the US alone and the growing
attitude of finding culprits for one's own lack of foresight, any CA
that makes an offer to the whole world, capable of acceptance without
communication and by mere conduct, is suicidal.
Is this relevant to PKIX? No, if PKIX is being designed to work
within a company or in a bounded environment, where subscribers and
users share a common and pre-existent trusted environment. Yes, if
PKIX wants to address no-previous relationship cases worldwide.
>
>> BTW, you did not show any counterarguments.
>
>I believe that I countered your statement that a CPS cannot
>be audited by stating that the ABA was working on audit standards
>for that very purpose.
>
First, the statement that current CPSs cannot be audited was NOT mine
(as you unfortunately misstated) but YOUR own and public, verbatim
as:
The CPS is not a document designed for auditing use however. It
describes a 'specification', it does not describe details which may
be checked by a third party in a systematic manner."
Second, it is very probable that *any* future CPS standards (of which
there are none today) will NOT provide any assurance of correct
results -- just correct methods and within some broad assumtpions.
Which is however already granted by law such as by the UCC. Thus, the
"new" CPS standard will very probably simply deal with a convergence
of terms and clauses, while leaving open the door I mentioned you
saying.
But, while that remains to be seen it is perhaps clear that you
cannot cite non-existent CPS regulations to say that current CPSs are
or will be auditable in a next incarnation. Oftentimes, problems have
no solutions in a broader scope. In particular, I have reasonable
doubt that one could ever audit or warrant ***results*** in CA
certification.
>As an employee of the major CA on the Internet I am not going
>to speculate on the future liabilities or insurance which might
>be offered by VeriSign or any of its competitors here. The PKIX
>architecture does not prevent such products being offered or
>supported which was your claim.
>
I appreciate your technical and business competence.
However, I may indeed question why all the work if no public CA will
ever be able to offer public warranty on results, from a general
subscriber to the general public. Which is what the public needs.
>I will merely remind people that five years ago folk were loudly
>proclaiming that a public CA such as VeriSign was an impossibility.
I did not say that. In fact, I have recently affirmed it is a very
good business to be a CA. The question is ...what next?
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09988 for ietf-pkix-bks; Fri, 9 Oct 1998 13:09:25 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA09984 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 13:09:24 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA19908; Fri, 9 Oct 1998 13:06:52 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA29062; Fri, 9 Oct 1998 13:08:56 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Dwight Arthur" <dwightarthur@mindspring.com>, "Stefan Santesson" <stefan@accurata.se>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Subject: RE: NEW Data type for certificate selection ?
Date: Fri, 9 Oct 1998 16:09:16 -0400
Message-ID: <001a01bdf3c0$b0d28920$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <000401bdf3bb$5f6f3740$3b8556d1@ns95lap005.nscc.com>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> Note that I am _not_ advocating roles or authorizations in the
> certificate.
> I am advocating policies, represented by OIDs, that specify issues like
> acceptable uses of certificates, applicable communities of interest, etc.
> where all subjects, issuers, and authorized relying parties are bound by
> contract to the policy.
A very important distinction. If there is a private agreement to recognize
a particular OID as having a specific semantics the extension is logically
a simple reference to a commonly agreed standard.
The problem comes in attempting to create public standards for such
agreements ab initio. Clearly private agreements can be widely adopted
and evolve into public standards through use and convention. It is
very hard to invent public conventions however.
You may be interested in the eTerms project of the ICC which is essentially
a third party repository into which terms of this nature can be deposited.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA09982 for ietf-pkix-bks; Fri, 9 Oct 1998 13:08:42 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA09978 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 13:08:41 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id NAA19902; Fri, 9 Oct 1998 13:06:42 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id NAA29043; Fri, 9 Oct 1998 13:08:45 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ed Gerck" <egerck@laser.cps.softex.br>
Cc: "Anders Rundgren" <anders.rundgren@jaybis.com>, <ietf-pkix@imc.org>, "Einar Stefferud" <Stef@nma.com>
Subject: RE: Common misconception #10. was RE: NEW Data type forcertificate
Date: Fri, 9 Oct 1998 16:09:05 -0400
Message-ID: <001801bdf3c0$aa5f88e0$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <Pine.LNX.4.02.9810091615300.542-100000@laser.cps.softex.br>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> My assertion was "every PKIX CA must inevitably disclaim all legal
> liability to the user" -- not to the subscriber.
A statement which is untrue, completely and utterly wrong.
> BTW, you did not show any counterarguments.
I believe that I countered your statement that a CPS cannot
be audited by stating that the ABA was working on audit standards
for that very purpose.
As an employee of the major CA on the Internet I am not going
to speculate on the future liabilities or insurance which might
be offered by VeriSign or any of its competitors here. The PKIX
architecture does not prevent such products being offered or
supported which was your claim.
I will merely remind people that five years ago folk were loudly
proclaiming that a public CA such as VeriSign was an impossibility.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA09770 for ietf-pkix-bks; Fri, 9 Oct 1998 12:31:34 -0700 (PDT)
Received: from camel7.mindspring.com (camel7.mindspring.com [207.69.200.57]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA09766 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 12:31:33 -0700 (PDT)
Received: from ns95lap005.nscc.com (user-38ld19r.dialup.mindspring.com [209.86.133.59]) by camel7.mindspring.com (8.8.5/8.8.5) with SMTP id PAA10912; Fri, 9 Oct 1998 15:31:47 -0400 (EDT)
From: "Dwight Arthur" <dwightarthur@mindspring.com>
To: "Stefan Santesson" <stefan@accurata.se>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>, <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <cert-talk@structuredarts.com>
Subject: RE: NEW Data type for certificate selection ?
Date: Fri, 9 Oct 1998 15:31:12 -0400
Message-ID: <000401bdf3bb$5f6f3740$3b8556d1@ns95lap005.nscc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <3.0.32.19980928111642.00a76390@m1.403.telia.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I apologize for posting this after the thread has been summarized and
closed. The summary did not mention the part of the discussion that
suggested policy oids as the basis for a solution. I would like to expand on
this.
Selecting the right certificate is an instance of the general problem of
building the right chain. This problem, in turn, needs to be closely aligned
with the trust model being used. Many or most of the examples given were
drawn from the so-called "open" or public model in which parties with no
prior relationship (NPR) establish a (very low) level of trust because
someone in the public CA business has issued a certificate asserting that
the subject produced documentary evidence of a certain identity.
Other models, imho more suitable for significant business use, are:
a. The parties have an existing business relationship and one of the parties
has issued the other a certificate as a token of that relationship. This
certificate is then to be used for access control and signing in facilities
offered by the issuer. I believe that Netscape's crypto.signText() function
provides a fully satisfactory method of saying, "I will only accept
certificates I issued." In addition, the emerging AADS approach supports
this without requiring actual certificates.
b. The parties share a relationship with an intermediary (bank, finance
company, expeditor, factor, etc) who guarantees (for a fee) the parties to
each other. Again, crypto.signText() or equivalents could be used to say, "I
am looking for a certificate issued by MonsterBank" or a slightly more
complex form of AADS could be used.
c. The parties share membership in an organization which, through member
agreements, binds all parties to acceptable business terms and risk
management procedures. Similar procedures can be used as in (b): "I am
looking for your certificate issued by S.W.I.F.T."
d. Each party has a relationship with an intermediary that's a member of an
organization such as described in (c). Now we are looking for something more
complex, like, "I will accept and debit card issued by any bank that
participates in NYCE or CIRRUS but not STAR." These relationships should
imho _not_ be recorded in the client certificates as the data may change
during the life of the certificate. Nor, imho, should the server send a list
of the thousands of member banks as a part of its signing request. Instead,
CIRRUS etc should each establish a certificate policy and form contracts
with each participating bank binding it to the policy. It should register
the policy and obtain an OID, then allow each member bank to issue
certificates bearing the OID. Your bank may then issue a certificate to you
carrying the CIRRUS and STAR oids. I may send a signing request calling for
certificates bearing NYCE or CIRRUS OIDs. Your browser would then respond
with your bank certificate because the CIRRUS OID matched. If you have
several matching certificates (because, for example, you have several bank
cards) the browser would ask you to chose, but the list of alternatives
would be only your CIRRUS or NYCE bank cards and would exclude your drivers
license, your library card, etc. Fraudulent certificates issued by
BongoCerts with the NYCE OID would be defeated either by (1) OCSP to the
NYCE responder, or (2) your browser sends a certificate chain including your
certificate from your bank and your bank's certificate from NYCE.
e. Finally, the model that I personally believe will account for the most
profitable segment of eCommerce: the employee card. I do not want to offer
my employee a certificate for accessing our bank, a separate certificate for
accessing our broker, a separate certificate for accessing our office
supplies vendor, and a separate certificate for accessing her 401K plan.
(Too much overhead, doesn't fit on a smartcard, too much risk that we l miss
one when it's time to revoke.) Instead, I want to offer every employee a
certificate that says, "this is an employee of this company" that allows
access to the benefits plans, the ability to initiate (but not authorize)
office supplies purchases, and access to the appropriate gender washrooms. I
may also offer some employees a different certificate (or an attribute
certificate that supplements the identity certificate) that includes a
policy OID that says, this is an officer, the company stands behind and
honors commitments made by this person. In my cross-certification with the
office supplies vendor, I can map my "this is an officer" policy with the
vendor's "authorized approver of purchases" policy. Further, I could map my
"this is an officer" policy to my bank's "authorized signer" policy or I
could create a different "authorized for high value financial transactions"
policy and map it to the appropriate policies of my bank and my broker.
(Note, I am not inventing this policy mapping stuff, it's straight out of
X.509) Now, when some other bank sends my employee a signing request it asks
for something like "a certificate bearing the authorized signer OID issued
by a bank that's a member of some ACH network." In this case, it is
necessary but not sufficient to select the right certificate. It is further
necessary to build a chain of certificates, leading back to some appropriate
root, with the specifies policies (or mapped policies) at every certificate
in the chain.
Note that I am _not_ advocating roles or authorizations in the certificate.
I am advocating policies, represented by OIDs, that specify issues like
acceptable uses of certificates, applicable communities of interest, etc.
where all subjects, issuers, and authorized relying parties are bound by
contract to the policy.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA09332 for ietf-pkix-bks; Fri, 9 Oct 1998 11:34:20 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA09328 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 11:34:15 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id QAA00571; Fri, 9 Oct 1998 16:34:24 -0200
Date: Fri, 9 Oct 1998 16:34:24 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Phillip M Hallam-Baker <pbaker@verisign.com>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, ietf-pkix@imc.org, Einar Stefferud <Stef@nma.com>
Subject: RE: Common misconception #10. was RE: NEW Data type for certificate
In-Reply-To: <006201bdf3a5$08de9440$9d07a8c0@pbaker-pc.verisign.com>
Message-ID: <Pine.LNX.4.02.9810091615300.542-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Fri, 9 Oct 1998, Phillip M Hallam-Baker wrote:
>Ed,
>
> This has gone way off topic for PKIX. I don't see a limitation
>of the PKIX infrastructure being discussed, clearly the types of insurance
>you envision can be supported by PKIX. If a customer wants to purchase a
>cert carrying such insurance the technology clearly is not the impediment.
Phill:
If you believe that insurance is a topic for PKIX, pls go ahead.
If you believe that one-sided PKIX subscriber-CA insurance can solve
the security problem of many-sided PKIX user-subscriber security, pls
also go ahead.
>
> I really don't think that the tone of your argument is suitable
>for a PKIX discussion which has already gone off topic. You started off
>with a blanket assertion that every PKIX CA must inevitably disclaim
>all legal liability. That is simply not true.
>
My assertion was "every PKIX CA must inevitably disclaim all legal
liability to the user" -- not to the subscriber.
The fact that you, again, want to put a blank denial over a
qualified denial is misleading to say the least.
If you think that you can use the tone you want but others cannot
disagree in technical terms, as I did, then this is a "hollier than
thou attitude" which would be slightly amusing if PKIX would be
private and personal -- but which is unacepatble for a IETF
discussion, IMHO.
BTW, to say that it "is simply not true" is too simple -- sorry, no
cigar.
> I really don't think I want to continue to debate with someone
>who titles their emails 'common misconception #10'. It betrays an
>apparent intention to demonstrate the ignorance and wrong headedness
>of the other side.
>
No, it says what it is -- a common misconception, also rather old.
BTW, you did not show any counterarguments.
> You appear to be arguing that the emperor has not clothes and that you
>are the only taylor who can dress him.
That is again a blank statement you put out. But, again, I refuse to
be bound by words I did not say. Please, do not keep trying that
because I will keep denying I said so -- with the difference that I
can prove that I did not say it. Truth begins at samll values.
>Whether or not we accept your first
>premise I doubt many accept your second. The emperor has sufficient clothes
>for the weather he is currently going out in and by the time the weather is
>worse he will have donned his multi-layer alpine ski wear and hazardous
>environment encounter suit.
I doubt your own statement is on-topic for PKIX. To say that
something is "sufficient" demands proof -- which you did not show,
while I did show otherwise. Hence your paragraph above has no content
I acn measure.
Just don't try to convince the whole world that everyone should buy
into it just because you say it will be just fine. The very fact that
you did not answer one of the questions I posed already shows that
you are still talking about emperors while the Internet is already
beyond democracy.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA08655 for ietf-pkix-bks; Fri, 9 Oct 1998 09:51:01 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA08651 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 09:51:00 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id JAA15424; Fri, 9 Oct 1998 09:49:01 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id JAA14360; Fri, 9 Oct 1998 09:50:58 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ed Gerck" <egerck@laser.cps.softex.br>
Cc: "Anders Rundgren" <anders.rundgren@jaybis.com>, <ietf-pkix@imc.org>
Subject: RE: Common misconception #10. was RE: NEW Data type for certificate
Date: Fri, 9 Oct 1998 12:51:18 -0400
Message-ID: <006201bdf3a5$08de9440$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <Pine.LNX.4.02.9810071337220.392-100000@laser.cps.softex.br>
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
This has gone way off topic for PKIX. I don't see a limitation
of the PKIX infrastructure being discussed, clearly the types of insurance
you envision can be supported by PKIX. If a customer wants to purchase a
cert carrying such insurance the technology clearly is not the impediment.
I really don't think that the tone of your argument is suitable
for a PKIX discussion which has already gone off topic. You started off
with a blanket assertion that every PKIX CA must inevitably disclaim
all legal liability. That is simply not true.
I really don't think I want to continue to debate with someone
who titles their emails 'common misconception #10'. It betrays an
apparent intention to demonstrate the ignorance and wrong headedness
of the other side.
You appear to be arguing that the emperor has not clothes and that you
are the only taylor who can dress him. Whether or not we accept your first
premise I doubt many accept your second. The emperor has sufficient clothes
for the weather he is currently going out in and by the time the weather is
worse he will have donned his multi-layer alpine ski wear and hazardous
environment encounter suit.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA01533 for ietf-pkix-bks; Fri, 9 Oct 1998 01:50:48 -0700 (PDT)
Received: from ausmtp02.au.ibm.com ([202.135.136.105]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA01529 for <ietf-pkix@imc.org>; Fri, 9 Oct 1998 01:50:42 -0700 (PDT)
From: r1naray@in.ibm.com
Received: from f03n05e.au.ibm.com (f03n05s.au.ibm.com [9.185.166.73]) by ausmtp02.au.ibm.com (1.0.0) with ESMTP id SAA26070; Fri, 9 Oct 1998 18:48:24 +1000
Received: from au.ibm.com (f06n04s [9.185.166.98]) by f03n05e.au.ibm.com (8.8.7/8.8.7) with SMTP id SAA18478; Fri, 9 Oct 1998 18:50:34 +1000
Received: by au.ibm.com(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id CA256698.003BF108 ; Fri, 9 Oct 1998 18:50:27 +1000
X-Lotus-FromDomain: IBMIN@IBMAU
To: ietf-pkix@imc.org
cc: wford@verisign.com, kent@bbn.com
Message-ID: <65256698.002D346A.00@au.ibm.com>
Date: Fri, 9 Oct 1998 13:58:04 +0530
Subject: New ID - Atomic Certificates
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hello,
I'd like to bring to the attention of the work group, an I-D I've just
submitted, that I hope will follow the standards track.
Though I'd have liked very much to have submitted it through the group, I
was told by the work group chairs that I'd best submit it as an Independent
Internet Draft and bring it to the attention of the work group.
The I-D can be accessed at:
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
Thanks,
Regards,
Narayan Raghu
IBM Bangalore
India
ABSTRACT
The existing PKI has a few inherent limitations like:
1. It is implicitly assumed that the two trading parties have ONE
mutually trusted third party that can attest ALL of each
party's attributes. It provides no mechanism to separate out the
fields in a certificate for attestation by different Certification
Authorities.
2. This standard in no way gives the flexibility to expose only
certain fields of a certificate to the other party.
This memo proposes a model which, while working well within the
X.509v3 framework, overcomes these limitations by
breaking up a certificate into pre-signed "unit attestations"
referred to as "Atomic Certificates" and packaging them in the
X.509v3 format only at the time of sending the certificate to the
other party.
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08183 for ietf-pkix-bks; Thu, 8 Oct 1998 12:29:29 -0700 (PDT)
Received: from camel14.mindspring.com (camel14.mindspring.com [207.69.200.64]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08178 for <ietf-pkix@imc.org>; Thu, 8 Oct 1998 12:29:26 -0700 (PDT)
Received: from ns95lap005.nscc.com (pool-207-205-161-29.nwrk.grid.net [207.205.161.29]) by camel14.mindspring.com (8.8.5/8.8.5) with SMTP id PAA13977; Thu, 8 Oct 1998 15:29:19 -0400 (EDT)
From: "Dwight Arthur" <dwightarthur@mindspring.com>
To: "Stefan Santesson" <stefan@accurata.se>, "David Horvath" <dave@chromatix.com>, "Alan Lloyd" <Alan.Lloyd@OpenDirectory.com.au>
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>, <pgut001@cs.auckland.ac.nz>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 8 Oct 1998 15:28:48 -0400
Message-ID: <000601bdf2f1$df93fde0$1da1cdcf@ns95lap005.nscc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-reply-to: <3.0.32.19980930164259.00a84cc0@m1.403.telia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
A similar application has been tested by the Internet Council of the
National Automated Clearing House Association (NACHA) - see
www.internetcouncil.org
The Javascript "crypto.signText()" function implemented in Netscape
Communicator 4.04 permits a solution to the issue you describe. One of the
fields passed to the function delineates acceptable certificates, I believe
it is a list of acceptable signers.
--------------------------------------------------
p:(212) 412-8687 Dwight Arthur
f:(212) 908-2345 Managing Director: Systems
b:(917) 646-6682 National Securities Clearing
dwightarthur@mindspring.com 55 Water Street
http://www.nscc.com New York, NY 10041-0082
-----Original Message-----
From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org] On Behalf Of
Stefan Santesson
Sent: Wednesday, September 30, 1998 10:44 AM
To: David Horvath; Alan Lloyd
Cc: 'ietf-pkix@imc.org '; 'list@seis.nc-forum.com ';
'pgut001@cs.auckland.ac.nz '
Subject: Re: NEW Data type for certificate selection ?
David,
Thank's for putting this issue in the right focus.
Alan, I don't suggest any new certificate extensions
Ed, I don't want to define any universal criteria for how certificate
selection SHALL be done or any who decides what for whom, regulations.
All I want to do is to define some mechanisms that CAN be used, if
required, by local PKI-related services in order to make it POSSIBLE for
them to build working services with STANDARD components.
Let me highlight this again and describe a realistic problem relevant to me.
Bank A offer web-based banking applications. This requires the end user to
get a specific certificate issued by Bank A. The certificate and the
corresponding private key is processed through the standard web browser of
the client
Two certificates and private keys are used in the normal process.
1) Certificate for SSL (TLS) security
2) Certificate for non-repudiation protection of Bank transactions.
In addition to these certificates, a specific end-user may be populated
with several other certificates, un-known to the Bank.
The question is. How can this Bank create a web based application without
distributing a customized client plug-in for the purpose. Well the Bank can
get far using Java Scripts but it will fail due to the problem that the
end-user may have to select a certificate.
Believe me, THIS IS TOTALLY UN-ACCEPTABLE FOR A COMMERCIAL BANK APPLICATION.
I realize that today there is no way to do this without distributing
customized plug-in components to end-users, but I strongly would like to se
options developed that helps getting around this. The current matching
mechanism in SSL and TLS is just not good enough to solve the problem.
So If we instead had a standardized matching rule that could be invoked
into protocols and Java Scripts etc, then the situation would be much more
hopeful for the Bank in my case.
They would then construct a match rule that with high probability would
point out the right end-user certificate and invoke that matching rule both
in the TLS protocol and in the Java Script, forming their secure
transaction application.
It wouldn't have to be perfect, just good enough to handle some 95%+ of the
cases as long as the Bank could detect cases where it didn't work. Then the
non-working cases could be fixed by personal customer service.
I see even more use for this matching rule. It could be used in S/MIME so
specify a preferred encryption certificate for replies to a mail. Of course
this matching rule could be used for X.500 directories as well (that's what
it was built for). MY concern here is however not _where_ the certificates
are stored but, how to select 1 of several known certificates regardless of
where they reside.
Comments?
How do wee proceed ?
Could we have any comments from Microsoft and Netscape ?
/Stefan
At 11:15 AM 9/30/98 -0400, David Horvath wrote:
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Alan,
>
>While I personally agree that X.500 provides a mature and feature rich
>core to implement certificate repositories, I am having trouble
>understanding some of your assertions as to why X.500 is the answer to
>so many problems.
>
>It seems to me that the first step for locating certificates in a
>repository is to define the fields in the certificate object that are a
>prerequisite to perform the match. Matching rules are a good start and
>foster the thought process required to provide a well designed solution.
>Once the matching rules are defined, a protocol such as DAP or LDAP V3
>with extensions may be used to exploit the matching rules. In some
>cases, clients may choose not to use the matching rules and retrieve all
>certificates. Perhaps matching rules are not supported by the protocol
>(LDAP V2 or HTTP), therefore the client will collect all the
>certificates and perform the match locally. This may be even more
>efficient than submitting multiple searches with different variations of
>matching rules. It could easily be more efficient to submit one search
>and retrieve 10 certificates, then to submit 3 searches with different
>matching rules each time until the required certificate is found. This
>should be defined by local policies based on performance analysis.
>
>Once the rules for matching certificates are defined ( and I think X.500
>matching rules are an excellent start ) the distribution model can be
>analyzed. This is another case where X.500 may be superior to LDAP, but
>unless you have a well planned global infrastructure neither X.500 or
>LDAP can help with the distribution model.
>
>Dave Horvath
>
>Alan Lloyd wrote:
>>
>>
>> Snip
>>
>> ----------
>> From: pgut001@cs.auckland.ac.nz
>> To: cert-talk@structuredarts.com; ietf-pkix@imc.org;
>> list@seis.nc-forum.com
>> Sent: 9/29/98 1:01:30 PM
>> Subject: Re: NEW Data type for certificate selection ?
>>
>> Peter - you went through great lenghts to define the problem with
>> relationships between and searching directory based objects and a
>> distributed information issue and then you say:
>> "
>> If anyone has any useful solutions for this (apart from "We should
>> force
>> everyone to use an X.500 directory, that would solve everything" :-) I'd
>> be interested in hearing them.
>>
>> "
>> Oh well - that counts me out. I cannot do solutions - without the
>> solution :-)))
>> regards alan
>>
>> Peter.
>>
>
>
>----------------- SEIS mailing list (list@seis.nc-forum.com)
>Info about this list: http://www.nc-forum.com/seis
>SEIS Contact: info@seis.se
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA08174 for ietf-pkix-bks; Thu, 8 Oct 1998 12:28:45 -0700 (PDT)
Received: from camel14.mindspring.com (camel14.mindspring.com [207.69.200.64]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA08170 for <ietf-pkix@imc.org>; Thu, 8 Oct 1998 12:28:44 -0700 (PDT)
Received: from ns95lap005.nscc.com (pool-207-205-161-29.nwrk.grid.net [207.205.161.29]) by camel14.mindspring.com (8.8.5/8.8.5) with SMTP id PAA09094; Thu, 8 Oct 1998 15:29:06 -0400 (EDT)
From: "Dwight Arthur" <dwightarthur@mindspring.com>
To: "Marc Branchaud" <marcnarc@xcert.com>
Cc: <stefan@aqccurata.se>, <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 8 Oct 1998 15:28:33 -0400
Message-ID: <000501bdf2f1$d8146fa0$1da1cdcf@ns95lap005.nscc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26
In-reply-to: <199810020018.RAA07570@crack.x509.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
In banking applications for the "big market" I do not think that you can
assume that you know the issuing CA or its root. Effective "big market"
applications need to deal with the case where the Relying Party and the
Subject are involved with entirely separate banking entities that subscribe
to the necessary hierarchies, cross-certification communities, etc to
construct a usable chain.
In the US Securities Industry (http://www.sia.com/sirca/) we are seeking
ways to meet this need by the use of certificate policies. Certificates
usable for a particular purpose will be recognizable by the fact that they
reference the required policy OID (or, can map to it through policy
mappings).
There is a definite shortage of client-side and server-side protocols for
completing a certificate chain that's restricted to certificates meeting
policy requirements. I believe that we will be articulating some business
requirements by year end that will stimulate some further work in this area.
--------------------------------------------------
p:(212) 412-8687 Dwight Arthur
f:(212) 908-2345 Managing Director: Systems
b:(917) 646-6682 National Securities Clearing
dwightarthur@mindspring.com 55 Water Street
http://www.nscc.com New York, NY 10041-0082
-----Original Message-----
From: owner-ietf-pkix@imc.org [mailto:owner-ietf-pkix@imc.org] On Behalf Of
Marc Branchaud
Sent: Thursday, October 01, 1998 8:18 PM
To: 'ietf-pkix@imc.org '
Subject: Re: NEW Data type for certificate selection ?
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Stefan Santesson <stefan@accurata.se> scrawled:
> =
> Marc,
> =
> If I follow you right you suggest that I use the knowledge from the SSL=
> negotiation to select the proper non-repudiation cert for signing
> transactions. I have thought of that but I have my doubts.
> =
Not necessarily from the SSL handshake itself (although since that's
already there it would be an optimization). But the same kind of mechani=
sm
could be employed, i.e. "here's a list of CAs whose certs I can accept."
> It would be very easy for the server to link knowledge from the link le=
vel
> (SSL) to the Application level (Javascript). The question is if that is=
> possible at the client side, by only using standard components (existin=
g or
> coming).
> =
So, you have this new requirement that nobody's really though of yet, and=
=
you're wondering if existing or planned components will solve your =
problem. Hmmm....
> Suppose the following steps:
> 1) The client browser knows which certificate was used to set up the SS=
L
> channel.
> 2) The server transfer a Javascript to the client in order to create th=
e
> electronic transaction form
> 3) After completing the form the Javascript request a signature on the
> completed form before it's transferred to the server.
> =
> Now even if the non-repudiation certificate and the SSL certificate was=
> issued by the same CA, Will any existing or planned version of any brow=
ser
> have the logic needed to find the right certificate. Not in theory, in
> practice.
> =
In practice, no such Javascript program exists so, practically speaking,
one would have to plan one's Javascript program to have such functionalit=
y.
I'm not familiar with web scripting languages, but I imagine that it's
possible to get the issuer DN of the server's cert and/or all the certs
presented by the server in the SSL handshake. Whether that's existing or=
=
planned, I have no idea.
As for whatever matching rule is required, it will most likely be =
implemented by the applet than the browser. I expect few browser makers =
would be happy to write some kind of generic lookup function to answer =
queries of the form "I need a cert of type <fee> that has a <foo> and =
isn't <foe> but can be <fum>". They'd be much happier to simply expose =
the broswer's certificate store to the applet and let the applet do the =
search.
> If not, then the problem is real and needs a solution. And if a solutio=
n is
> needed I would like to see better selective mechanisms than just Issuer=
DN
> of the CA.
> =
This, I think, is the crucial issue. I'm having trouble seeing why
matching issuer DNs is inadequate. Is it because having a CA per =
application is impractical? Since we're talking about banking here, I =
can't believe that the answer would be "yes" [heck, with a moderate =
hierarchy, the user would only need one cert (from the root CA) to use al=
l =
of the bank's applications].
Please explain to me why saying "I need you to use a cert signed by one o=
f =
these CAs" isn't a good enough solution.
Marc
+------------------------------------------------------------------------=
+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC=
=2E
marcnarc@xcert.com PKI References page: www.xcert.co=
m
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------=
+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNhQbt1rdFXNdDxPlAQEtswL8CZltb8fpsRO5urWESF9Ps4FNVlO9rLui
8+eDmkaf9L7AnY+ljW7ZCYF0p8zk/f6d7xmpia+gxdQBxT6edKYOOTzsr2cwY3Hf
RITSfqoIf4XpQTy/N1lBRhGRLZ0qYYwR
=9JQx
-----END PGP SIGNATURE-----
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA06577 for ietf-pkix-bks; Wed, 7 Oct 1998 10:47:55 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA06572 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 10:47:51 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id PAA04465; Wed, 7 Oct 1998 15:47:25 -0200
Date: Wed, 7 Oct 1998 15:47:25 -0200 (EDT)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Phillip M Hallam-Baker <pbaker@verisign.com>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, ietf-pkix@imc.org, list@seis.nc-forum.com
Subject: Common misconception #10. was RE: NEW Data type for certificate
In-Reply-To: <000001bdf1fd$05426860$9d07a8c0@pbaker-pc.verisign.com>
Message-ID: <Pine.LNX.4.02.9810071337220.392-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Wed, 7 Oct 1998, Phillip M Hallam-Baker wrote:
> Ed Gerck wrote;
>> The uncertainty reaches a point of almost uselessness, where CAs
>> usually explicitly state in the certification contracts that the CA
>> is exempt of all or almost all responsibility regarding the
>> "certificate", its accuracy and its data. For example:
>
>Taking one part of a contract in isolation is misleading. The VeriSign
>contract has a 'disclaim all implied warranties clause', in other words
>it states that the only warranties provided are those explicitly stated.
>
Phill:
Which are zilch to the cert user, as Verisign's CPS affirm. Of
course, I am not talking about the cert subscriber (that has a
contract with Verisign and a limited warranty) but I am talking about
a general cert user -- who is not privy with that contract, at all,
and which is denied any liability from Verisign.
If I make an offer to the whole world, capable of acceptance without
communication by mere conduct, I can be contractually bound. The
classical example was the 19th century case of the Carbolic Smoke
Ball Company, which advertised an offer of money to any purchaser of
its product (from a retailer, not from the advertising manufacturer)
who contracted influenza after using it. A purchaser sued
successfully for the money.
The same principle governs modern cheque guarantee cards. The bank
promises anyone who accepts a cheque covered by the card that it will
honour the cheque. The bank can be compelled to do so.
So a CA who promises users that its certificates are correct can be
sued by a user.
Or, a CA that promises users that its CRLS are correct can be sued by
a user.
That does not undermine my conclusion, however, because CAs are ever
so careful that neither their certificates nor their CPSs contain any
promise open for acceptance in the way I have described above -- or
in the way that you have described -- or in the way that users
mistakenly may imagine.
It is that fact, rather than the impossibility of such a promise
being binding, that protects the CA.
This point is also contained, albeit more mildly, in my posting on
"If there is a business for CAs" (archives for mcg-talk, cert-talk,
e-carm, etc) and I thank Nicholas Bohm for the legal input on it. It
is also in the Overview paper at certover.pdf.
This is common misconception #10:
CAs have subscribers and users. Users have no contract to
CAs and are specifically excluded from any warranty or liability
by commercial CAs very well-written an public CPSs -- even though
users are called "relying-parties" in such CPSs. However, users
must understand that they are a "relying-party" of their own due
dilligence.
>The explicitly stated warranty consists of NetSure insurance in a sum
>that varies from $1,000 to $100,000 depending on the certificate
>category. If necessary higher sums could be agreed. This is real
>insurance underwritten by a leading insurer.
The NetSure insurance only applies to Verisign's subscribers -- who
pay for the insurance and are so insured ;-)
It does NOT apply to the world at large, the user, who is not privy
to the contract between Verisign and the subscriber. You would need
the whole world to sign and pay into that NetSure policy in order to
make it begin to be useful to users.. not a bad perspective for some,
but unlikely.
Further, just to make it clear why you cannot fight open risks with
insurance, suppose that 1,000 users have problems with just 1 cert
for ACME, issued by Verisign and insured by NetSure. I ask:
- Who is laible for what?
- Who should each of the 1,000 users sue: ACME, Verisign, the insurer
or, all?
- How much is each of the 1,000 users entitled to claim under
NetSure: the full certificate's insurance for each (thus, suppose,
1,000 x $1,000) or a rate of the total insurance (say $1,000 divided
by 1,000)?
- Who pays what NetSure does not pay but each 1,000 users will
certainly claim?
Thus, it is not misleading to single out that part, since that part
is what negates the user's rigths.
But, I am sure we all know this. Especially the guys that calculated
the NetSure insurance coverage and its exceptions, as well as the
guys that wrote Verisign's CPS.
So -- why the fuss? Perhaps, it is intersting to view common
misconception #10 under a different light. It was very well stated by
a Harvard-graduated lawyer, who declared:
> CAs and PKI rely on that same sort of systems trust. You trust
> that the CA, as an expert system, will do the identify
> verification, certification revocation, etc. properly. It's
> analogous to when you trust that the architect/civil engineer who
> designed your house (and who are part of a system of education,
> licensing, and bureaucratic approval) did it properly and don't
> worry about your house falling down.
To which I publicly responded, with:
The analogy you point out does NOT exist and this is a common
misconception. A relying-party (aka, the cert user) cannot rely upon
the CA as a house owner relies upon the expert engineer he hired,
for several reasons.
First, because there is no contract between a user and a CA while
the engineer was hired by the house owner or, in other words,
because the person who pays for the certificate is not the one who
relies on it. Second, because it is generally accepted that Internet
traffic is subject to so many possible sources of disturbance
(willingful or by chance) in so many possible routes that a CA
cannot present a guarantee of correct results, just of correct
methods -- which is also law doctrine for consultation work and data
processing in general. Third, because a certificate is an open-ended
risk. Fourth, because certificates cannot really be revoked, and so
represent an open assignment. For a list of 16+ causes, you can
check http://www.mcg.org.br/cert.htm
One other cause is that Verisign denies warranties to the public at
large -- as commented at the top.
Clearly, for any CA the majority of relationships is, albeit
indirectly, defined by CA/user. The number of CA/subscriber cases is
much smaller. This highlights the importance of this issue, since
users are also the ones that must primarily weigh potential losses.
Further, it is also clear that users may hold the subscribers to be
responsible. However, if the subscriber publicly denies any liability
to anyone in the world, then a user may also have only its own due
dilligence to rely upon.
>
>
>> As publicly declared by Phillip Hallam-Baker, a
>> Verisign consultant, not only are the CPSs indeed different and
>> self-made by each CA but they are not designed to be audited, either:
>> "There is not as yet a defined standard for CA practices against
>> which a company may be audited. In effect each company states their
>> own practices in their Certificate Practices Statement (CPS). The CPS
>> is not a document designed for auditing use however. It describes a
>> 'specification', it does not describe details which may be checked by
>> a third party in a systematic manner."
>
>Here you are quoting me out of context. This was in the context of
>your argument concerning the use of a standardized audit statement.
I provided the full reference, which was in hypertext under your
name and as reference [Bak98] in http://www.mcg.org.br/certover.pdf.
As referenced in: (long URL)
http://www.mcg.org.br/cgi-bin/lwg-mcg/MCG-TALK/archives/mcg/date/article-379.html
and anyone could search the archives for the full thread.
>
>Taking off the cuff statements out of mailing list exchanges and
>quoting them verbatim offline without checking the context seems
>somewhat odd behaviour.
As above, that is not the case. The reader can go to the original
thread and check the full contexts of all your messages -- which IMO
will not change anything in that isolated paragraph. Now, if you want
to imply that public mailing lists are not useful to provide
meaningful information without further checking, then I must agree as
we see how much misinformation is oftentimes put out through these
channels. Which we must oftentimes weed out and just get what seems
to be fitting to our own intelligence. Perhaps, this posting also
exemplifies that.
However, if you feel that you can issue a more accurate statement,
then I will be pleased to change them in all the certover.pdf,
certover.ps and cert.htm.htm files -- which have BTW been downloaded
more than 55,000 times in the last year and are cited in some books
and thesis on the subject.
>
>I was arguing that before you could use 'audit statements' in the
>manner you envisioned there had to be agreement on audit standards.
>Work on audit standards for a CPS is taking place. It is thus entirely
>misleading to take a specific objection to a specific use of auditing
>for a specirfic purpose and conclude that no CPS can ever be audited.
>
But, not the way they are -- and that was what you yourself wrote in
the quote above. Now, I ask: what does a subscriber buy from Verisign
today -- a cert issued acording to today's CPS that we both agree
cannot be audited or, based on a future Verisign's CPS? And, I also
ask: What should we discuss -- today's CPS risks or risks of future
CPSs we do not know of?
>
>Saying that a CPS issued by BongoCert Inc. may not necessarily prove
>to be auditable is not the same as saying that 'A CPS is not designed
>to be audited'. In fact a CPS can be designed to be auditable and
>the ability to conduct an audit may be considered a quality differentiator
>between CPSs.
>
>Rather than 'does not describe' I would instead restate this as
>'does not necessarily describe'.
>
Let me comment by parts. The relevant section of your quote began
with:
>>"In effect each company states their own practices in their
>> Certificate Practices Statement (CPS)."
This means that unless we believe in serendipity as a valid work tool
then we should expect that CPSs from different CAs do not
interoperate. This reflects BTW a basic flaw of laissez-faire
certification systems such as X.509 and PKIX, exactly where we would
need interoperation -- the semantic rules that certificate issuance
must obey are not defined by the standard but ad hoc by each company.
Who cares that the syntatic rules are clear (ahem...) in the
standard? Is that all?
>>"The CPS is not a document designed for auditing use however."
Clear -- like a car is not designed to fly, and does not fly. I also
think that if a CPS would allow what it is not designed to do (as you
seem to imply in your comment above) then that is a security flaw,
by itself no? I mean, what other unthought-of properties could one
spelunk from it? Will such "easter eggs" be good or bad for me? Meet
you in court, you say ....
>>"It describes a 'specification', it does not describe details which
>>may be checked by a third party in a systematic manner."
It says "it does not describe" and you want to change to "it does not
necessarily describe". Fine. However, are we not again relying on
serendipity? And, as Descartes affirmed: "Doubt until you have proof"
means that I can surely doubt such statement will ever support the
exsitence of even ONE auditable CPS, right?
>
>The problem I believe I was having with your argument was that the
>invocation of 'auditors' appeared to be used as a panacea as if the
>statement 'I have been audited' translated to the conclusion 'He is
>trustworthy' without taking account of how the audit was performed,
>who performed it and what the objective of the audit was.
>
I do not think that can be deduced from any of my postings or
articles. Nor inferred. Should I be bound by a word I did not say?
On the contrary, my posting considerably stressed that any reliance
derived from trust must depend on the exact underlying terms and
rules that support such trust:
Thus, in legal reliance terms, one trusts the name confirmation
procedures of the CA during certificate reliance, but one cannot
rely upon the name for other than its value as a representation of
the CA's authentication management act expressed in the CA's own
terms and rules.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
--- Meta-certificate Group Member -- http://www.mcg.org.br ---
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA04781 for ietf-pkix-bks; Wed, 7 Oct 1998 07:16:35 -0700 (PDT)
Received: from caladan.verisign.com (caladan.verisign.com [205.180.232.21]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA04777 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 07:16:34 -0700 (PDT)
Received: from mentat.verisign.com by caladan.verisign.com (8.8.5/BCH1.5) id HAA00874; Wed, 7 Oct 1998 07:13:53 -0700 (PDT)
Received: from pbaker-pc.verisign.com by mentat.verisign.com (8.8.5/BCH1.0) id HAA11347; Wed, 7 Oct 1998 07:15:46 -0700 (PDT)
From: "Phillip M Hallam-Baker" <pbaker@verisign.com>
To: "Ed Gerck" <egerck@laser.cps.softex.br>, "Anders Rundgren" <anders.rundgren@jaybis.com>
Cc: <ietf-pkix@imc.org>, <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
Date: Wed, 7 Oct 1998 10:16:04 -0400
Message-ID: <000001bdf1fd$05426860$9d07a8c0@pbaker-pc.verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <Pine.LNX.4.02.9810020308410.25643-100000@laser.cps.softex.br>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
> The uncertainty reaches a point of almost uselessness, where CAs
> usually explicitly state in the certification contracts that the CA
> is exempt of all or almost all responsibility regarding the
> "certificate", its accuracy and its data. For example:
Taking one part of a contract in isolation is misleading. The VeriSign
contract has a 'disclaim all implied warranties clause', in other words
it states that the only warranties provided are those explicitly stated.
The explicitly stated warranty consists of NetSure insurance in a sum
that varies from $1,000 to $100,000 depending on the certificate
category. If necessary higher sums could be agreed. This is real
insurance underwritten by a leading insurer.
> As publicly declared by Phillip Hallam-Baker, a
> Verisign consultant, not only are the CPSs indeed different and
> self-made by each CA but they are not designed to be audited, either:
> "There is not as yet a defined standard for CA practices against
> which a company may be audited. In effect each company states their
> own practices in their Certificate Practices Statement (CPS). The CPS
> is not a document designed for auditing use however. It describes a
> 'specification', it does not describe details which may be checked by
> a third party in a systematic manner."
Here you are quoting me out of context. This was in the context of
your argument concerning the use of a standardized audit statement.
Taking off the cuff statements out of mailing list exchanges and
quoting them verbatim offline without checking the context seems
somewhat odd behaviour.
I was arguing that before you could use 'audit statements' in the
manner you envisioned there had to be agreement on audit standards.
Work on audit standards for a CPS is taking place. It is thus entirely
misleading to take a specific objection to a specific use of auditing
for a specirfic purpose and conclude that no CPS can ever be audited.
Saying that a CPS issued by BongoCert Inc. may not necessarily prove
to be auditable is not the same as saying that 'A CPS is not designed
to be audited'. In fact a CPS can be designed to be auditable and
the ability to conduct an audit may be considered a quality differentiator
between CPSs.
Rather than 'does not describe' I would instead restate this as
'does not necessarily describe'.
The problem I believe I was having with your argument was that the
invocation of 'auditors' appeared to be used as a panacea as if the
statement 'I have been audited' translated to the conclusion 'He is
trustworthy' without taking account of how the audit was performed,
who performed it and what the objective of the audit was.
Phill
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA03754 for ietf-pkix-bks; Wed, 7 Oct 1998 04:05:57 -0700 (PDT)
Received: from noms.capgemini.fr (noms.capgemini.fr [194.3.247.254]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA03750 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 04:05:56 -0700 (PDT)
From: cgilmach@capgemini.es
Received: from prenoms.capgemini.fr (capmail [194.2.91.200]) by noms.capgemini.fr (8.8.7/8.8.7) with ESMTP id NAA05297 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 13:09:47 +0200 (MET DST)
Received: from dionisio.capgemini.es ([194.75.0.3] (may be forged)) by prenoms.capgemini.fr (8.8.6/8.8.6) with SMTP id NAA25249 for <ietf-pkix@imc.org>; Wed, 7 Oct 1998 13:05:42 +0200 (MET DST)
Received: by dionisio.capgemini.es(Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) id C1256696.003C353B ; Wed, 7 Oct 1998 12:57:37 +0200
X-Lotus-FromDomain: CAP
To: ietf-pkix@imc.org
Message-ID: <C1256696.003BC3C9.00@dionisio.capgemini.es>
Date: Wed, 7 Oct 1998 13:04:40 +0200
Subject: Re: DNS Name definition
Mime-Version: 1.0
Content-type: multipart/mixed; Boundary="0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y"
Content-Disposition: inline
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
--0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable
Jacques Lebastard <Jacques.Lebastard@bull.net> con fecha 10/06/98 05:37=
:42
PM
Destinatarios: PKI Mailing list <ietf-pkix@imc.org>
CC: (cci: Carlos Javier Gil Mach=EDn/BCN/CAP)
Asunto: DNS Name definition
=
--0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
I'm looking for the Standard document defining the format
of a DNS name. Does such an Internet RFC exist ?
--
Jacques LEBASTARD mailto:Jacques.Lebastard@bull.net
BULL SA - ISM AccessMaster http://www.openmaster.com/
Rue Jean Jaures - F3-2G-03 Tel: +33 1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 1 30 80 77 99
The RFCs 1034 and 1035 define the DNS format. There are several updates of
these documents; I think the lastest one is the 2038.
You can look at the RFC index at:
http://info.internet.isi.edu:80/in-notes/rfc/rfc-index.txt
Yours,
Carlos Gil.
----------------------------------------------------------------------
Carlos J. Gil Machin <cgilmach@capgemini.es>
Telecommunications Engineer
Cap Gemini Spain Tel. + 34 93 495 86 00
Avda. Diagonal, 640, 4th. Fax. + 34 93 405 90 54
08006 Barcelona SPAIN WWW: http://www.capgemini.es
PGP Fingerprint: 86BE 4FDF F2A3 A39D CCDD 6936 0E4E A79C 0E11 B7F0
----------------------------------------------------------------------
--0__=o8FazWdO6smd4hUEBoIbaajdL6OqxLSP3NzSPdR2bnTpPVxjs6IbbH0Y--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA06151 for ietf-pkix-bks; Tue, 6 Oct 1998 08:39:02 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA06144 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 08:38:52 -0700 (PDT)
Received: from bahamas.frcl.bull.fr (bahamas.frcl.bull.fr [129.182.22.122]) by clbull.frcl.bull.fr (8.8.2/8.8.2) with SMTP id RAA13327 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 17:37:30 +0200
Received: from localhost by bahamas.frcl.bull.fr (AIX 4.1/UCB 5.64/4.03) id AA21032; Tue, 6 Oct 1998 17:37:42 +0200
Message-Id: <361A3946.3D352C33@bull.net>
Date: Tue, 06 Oct 1998 17:37:42 +0200
From: Jacques Lebastard <Jacques.Lebastard@bull.net>
Organization: BULL SA - ISM/AccessMaster
X-Mailer: Mozilla 4.03 [en] (X11; I; AIX 4.1)
Mime-Version: 1.0
To: PKI Mailing list <ietf-pkix@imc.org>
Subject: DNS Name definition
References: <199810061501.IAA05512@mail.proper.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I'm looking for the Standard document defining the format
of a DNS name. Does such an Internet RFC exist ?
--
Jacques LEBASTARD mailto:Jacques.Lebastard@bull.net
BULL SA - ISM AccessMaster http://www.openmaster.com/
Rue Jean Jaures - F3-2G-03 Tel: +33 1 30 80 77 86
F-78340 Les Clayes sous Bois Fax: +33 1 30 80 77 99
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA05516 for ietf-pkix-bks; Tue, 6 Oct 1998 08:01:23 -0700 (PDT)
Received: from aum.proper.com (ts004d05.sea-wa.concentric.net [209.31.208.161]) by mail.proper.com (8.8.8/8.8.5) with SMTP id IAA05512 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 08:01:21 -0700 (PDT)
Message-Id: <199810061501.IAA05512@mail.proper.com>
X-Sender: phoffman@mail.imc.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1.0.63 (Beta)
Date: Tue, 06 Oct 1998 08:01:35 -0700
To: ietf-pkix@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Re: PKIX: DNS name constraint in Cert. Profile (Sept. 23, 1998)
In-Reply-To: <199810060119.LAA14517@cdn-mail.dn.itg.telecom.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
At 11:17 AM 10/6/98 +1000, Manger, James wrote:
>Either require a leading period in the constraint, e.g. ".foo.bar.com" (c.f.
>URI constraint); or replace the "adding to the left" sentence with "Any
>sub-domain satisfies the constraint.". Change "foo1.bar.com" to
>"bigfoo.bar.com" as an example that does not satisfy the constraint.
Extremely good point, and I believe that the latter ("any subdomain...")
should be used. If this clarification can be made before the RFC is issued,
it should be; otherwise, we should probably be starting a "clarifications"
draft and this should be in it.
--Paul Hoffman, Director
--Internet Mail Consortium
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA03851 for ietf-pkix-bks; Tue, 6 Oct 1998 05:27:23 -0700 (PDT)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA03847 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 05:27:21 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id OAA05234 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 14:27:32 +0200 (CEST)
Received: from stefans (t4o68p29.telia.com [62.20.139.149]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA28207 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 14:27:26 +0200 (CEST)
Message-Id: <3.0.32.19981006142344.00a3a5e0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 06 Oct 1998 14:24:25 +0200
To: "'pkix'" <ietf-pkix@imc.org>
From: Stefan Santesson <stefan@accurata.se>
Subject: Summary: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA03848
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
I have been asked by some private mailers to sum up this thread.
The problem originally addressed was:
Experiences until today has shown that successful services over Internet
allows users to access these services through their standard internet
software components, in particular e-mail clients and web browsers.
As soon as a service require a custom designed plug-in module to be
installed at the clients computer, a threshold mechanism is introduced that
dramatically limits the probability of success.
Unfortunately X.509 PKI dependent services are many times faced with this
problem. Today many browsers and e-mail clients have to be supplemented
with plug-ins to handle directory access, certificate selection,
non-repudiation services, smart card access etc. Many of these problems
will be solved by emerging protocols and standards (like directory access
and API to cryptographic tokens). However the certificate select problem
will continue to be at least partially unsolved, unless something is done
about it.
----
So one of the most important obstacles to remove before PKI-based security
can be introduced in a large scale, is the problem of certificate
selection, i.e. to solve how one out of several certificates is selected by
standard mechanisms in standard client products without having to rely on
the end users ability to pick the right certificate.
We have seen that on the "link level" there is a solution (in SSL and TLS).
Here the server can communicate to the client a list of CA:s accepted by
the server. Except from this it is total darkness.
At the application level there is no solutions. Java script may be used to
create data forms to be signed by the client, but the process to select a
proper user certificate is not covered.
The possible solution debated here was to define a general select mechanism
in the form of a defined data type, such as the X.500 match rule. This
mechanism could then be introduced into link level protocols as well as
application level command interpreters.
I end this debate with my conclusion that this problem space remains to be
solved. As working for some potential providers of public PKI-based
services over Internet I can only encourage any effort aimed at solving
this in a near future.
/Stefan Santesson
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA11378 for ietf-pkix-bks; Mon, 5 Oct 1998 18:40:10 -0700 (PDT)
Received: from mail.telstra.com.au (mail.telstra.com.au [192.148.160.16]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA11374 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 18:40:07 -0700 (PDT)
Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id LAA11437 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 11:39:28 +1000 (EST)
Received: from mail-gw.fwall.telstra.com.au(192.148.147.16) via SMTP by mail.telstra.com.au, id smtpd003254; Tue Oct 6 11:20:19 1998
Received: (from uucp@localhost) by mail-gw.fwall.telstra.com.au (8.8.2/8.6.9) id LAA04501 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 11:20:16 +1000 (EST)
Received: from cdn-mail.dn.itg.telecom.com.au(144.135.109.134) via SMTP by mail-gw.fwall.telstra.com.au, id smtpd004142; Tue Oct 6 11:19:49 1998
Received: from qbpde-nm03.corpmail.telstra.com.au (qbpde-nm03.corpmail.telstra.com.au [172.51.17.214]) by cdn-mail.dn.itg.telecom.com.au (8.8.2/8.6.9) with ESMTP id LAA14517 for <ietf-pkix@imc.org>; Tue, 6 Oct 1998 11:19:47 +1000 (EST)
Message-Id: <199810060119.LAA14517@cdn-mail.dn.itg.telecom.com.au>
Received: by qbpde-nm03.corpmail.telstra.com.au with Internet Mail Service (5.5.2232.9) id <4K0RA11H>; Tue, 6 Oct 1998 11:19:47 +1000
From: "Manger, James" <JManger@vtrlmel1.telstra.com.au>
To: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: PKIX: DNS name constraint in Cert. Profile (Sept. 23, 1998)
Date: Tue, 6 Oct 1998 11:17:32 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
<draft-ietf-pkix-ipki-part1-11.txt>
At a quick glance the latest draft looks good. The Name Constraints clause
(4.2.1.11) has been tightened up for URIs but the same is needed for DNS
restrictions. The relevant text is quoted below. A constraint
"foo.bar.com" should NOT be satisfied by "bigfoo.bar.com", yet this is
constructed "by simply adding to the left hand side" so it does satisfy the
constraint according to the draft.
Either require a leading period in the constraint, e.g. ".foo.bar.com" (c.f.
URI constraint); or replace the "adding to the left" sentence with "Any
sub-domain satisfies the constraint.". Change "foo1.bar.com" to
"bigfoo.bar.com" as an example that does not satisfy the constraint.
-----
INTERNET DRAFT September 23, 1998
4.2.1.11 Name Constraints
...
DNS name restrictions are expressed as foo.bar.com. Any DNS name that
can be constructed by simply adding to the left hand side of the name
satisfies the name constraint. For example, www.foo.bar.com would
satisfy the constraint but foo1.bar.com would not.
...
Housley, Ford, Polk, & Solo [Page 36]
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA07872 for ietf-pkix-bks; Mon, 5 Oct 1998 10:00:02 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA07868 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 10:00:01 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id JAA21407; Mon, 5 Oct 1998 09:56:41 -0700 (PDT)
Message-Id: <3.0.3.32.19981005095524.00b025b0@poptop.llnl.gov>
X-Sender: e048786@poptop.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 05 Oct 1998 09:55:24 -0700
To: =?iso-8859-1?Q?Sievänen?= Markku <markku.sievanen@setec.fi>, Anders Rundgren <anders.rundgren@jaybis.com>
From: Tony Bartoletti <azb@llnl.gov>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'pkix'" <ietf-pkix@imc.org>
In-Reply-To: <514651EC9177D111ABE700805F0D75DC17B27B@eemeli.setec.fi>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
All,
Sorry I was not clear. What I meant was that I send an (electronic) check
to whom I _think_ is Acme Hardware on Third Street, when in fact some
miscreant has posed as such to the CA/Directory Service in order to get
a fraudulent certificate or listing.
In such a case, I relied upon the CA/Directory to be authoritative. But
when they get hoodwinked (though they followed their own stated procedures)
I am left with little recourse. I may as well be hoodwinked directly, and
leave out the middleman;)
___tony___
Tony Bartoletti LL
SPI-NET GURU LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA07030 for ietf-pkix-bks; Mon, 5 Oct 1998 08:03:07 -0700 (PDT)
Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA07026 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 08:02:59 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.0.1461.28) id <4JBWNXD0>; Mon, 5 Oct 1998 17:09:19 +0200
Message-ID: <8160937F4F4CD111A93E00805FC17529A59FD5@ntsiaexch.office>
From: Santoni Adriano <santoni@sia.it>
To: "'Robert Zuccherato'" <robert.zuccherato@entrust.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: R: Time Stamp and Notary Drafts
Date: Mon, 5 Oct 1998 17:09:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1461.28)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA07027
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Thank you for you reply.
So, where you say "the nonce in the token must be present if the nonce is
present in the request. However, the nonce is mandatory in the request.
Thus, using the present protocol, the nonce is mandatory" ...you imply that
whatever value the requestor puts in the nonce field of his request, the TSA
must copy that same value in the nonce field of the response (token), right?
If things are going to stay that way, I'd suggest to issue a new draft
(well, when the time is right for doing that) with the field "nonce" in both
the TimeStampReq and the TimeStampToken structures marked OPTIONAL. The
criterium that "if the requestor sends it, the responder must also send it"
can be explained, and declared REQUIRED, in the text.
The reason for having a repository URL in the response would be that of
binding the TSA to mantain an available online repository of all timestamp
responses ever generated (or, well, a large enough sliding window of them),
so that people may retrieve them at will in case they ever need. After all,
a timestamp response is much like a certificate (it just do not bind people
to keys but hashes to times), and a CA is suposed to have such a repository.
However, I agree that this concept needs more thinking (and, yes, the
tsaFreeData would be the obvious place to put that sort of information,
lacking other possibilities).
Regards.
Adriano
> -----Messaggio originale-----
> Da: Robert Zuccherato [SMTP:robert.zuccherato@entrust.com]
> Inviato: lunedì 5 ottobre 1998 15.17
> A: 'Santoni Adriano'
> Cc: 'ietf-pkix@imc.org'
> Oggetto: RE: Time Stamp and Notary Drafts
>
> Thanks for your comments. My replies are embedded below.
>
> > ----------
> > From: Santoni Adriano[SMTP:santoni@sia.it]
> > Sent: Monday, October 05, 1998 5:15 AM
> > To: 'Robert Zuccherato'
> > Cc: 'ietf-pkix@imc.org'
> > Subject: R: Time Stamp and Notary Drafts
> >
> > Regarding the nonce field in timestamp requests and responses: the
> > draft
> > says (at page X) that the TSA must include the same nonce value the
> > requestor specified in his request, in case he did. But how is the TSA
> > going
> > to determine that the requestor did specify a nonne value? I can
> > imagine two
> > possible answers: either the nonce field is OPTIONAL in the
> > TimeStampReq,
> > too (and not only in the response), or a "blank" value is established
> > by
> > convention (e.g. zero).
> >
> I had a request to include a second type of time stamp request. This
> lower quality of service request would be http based and would just
> return a "blank" token without a message imprint or nonce. Basically,
> it would just be a signature on the current time. This would be a lower
> quality of service because without a trusted source of time, one could
> not verify that the returned token was "fresh". People would be able to
> just go to a web site and pick up one of these tokens.
>
> I am in the process of adding this option and have included the nonce in
> the token as OPTIONAL to allow for it, but haven't fully described it
> yet. If people want this service, I will include it. Otherwise, I
> won't and the option on the nonce will be removed.
>
> Notice however that the way things are presently described, the nonce in
> the token must be present if the nonce is present in the request.
> However, the nonce is mandatory in the request. Thus, using the present
> protocol, the nonce is mandatory.
>
> > Regarding the timestamp response (token): would not it be useful to
> > include
> > a pointer to an on-line repository, supposed to be run by the TSA,
> > were all
> > tokens are held and made available to everyone for browsing and
> > downloading?
> >
> I am not entirely sure of the usefulness of this service. How would
> such a repository be used? Could the tsaFreeData field be used for this
> pointer?
>
> > Remarks. The draft should make use, IMO, of the usual keywords (in
> > all-uppercase) indicating requirement levels (MUST, MUST NOT, SHOULD,
> > etc.)
> > as per RFC 2119.
> >
> Certainly.
>
> > A more elaborate explanation of how to intepret the
> > reqPolicy field and some real-world scenarios would also be helpful.
> >
> I agree. There is a need for a document describing time stamp policy
> and time stamp practice statements. These are all important issues.
> However, in this document we are only trying to describe the protocol
> that is to be used between these entities. Discussion of actual policy
> issues is outside of its scope.
>
> Robert.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06884 for ietf-pkix-bks; Mon, 5 Oct 1998 07:45:08 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA06880 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 07:45:07 -0700 (PDT)
Received: from [128.33.238.65] (TC065.BBN.COM [128.33.238.65]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id KAA18982 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 10:45:21 -0400 (EDT)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: kent@po1.bbn.com (Unverified)
Message-Id: <v04011701b23e8bad21d9@[128.33.238.58]>
Date: Mon, 5 Oct 1998 10:45:18 -0400
To: ietf-pkix@imc.org
From: Stephen Kent <kent@bbn.com>
Subject: CFP relevant to PKIX
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Call for Papers
IEEE Journal on Selected Areas in Communications (JSAC)
Special Issue on Network Security
Publication date: January, 2000
Recent years have seen great advances in the availability of security
technology for network users. The advances in standardization and
implementation are accompanied by continuing activity in the research
community to tackle the next generation of problems and to improve on
prior technology.
This special issue of JSAC will be devoted to recent research results
that describe or forecast significant changes in the feasibility of
delivering security solutions (such as major improvements in
cryptographic efficiency), or describe progress in areas that have
been especially difficult, or are relevant to newer technologies, such
as optical or mobile wireless communication. Of special interest are
papers that relate their results to use on the Internet today
or to use on next generation networks.
Papers are solicited in the following areas:
Cryptography-based network systems, such as
secure private networks
transactional security
Public-key infrastructures
Applying new cryptographic methods to network communication
New cryptographic protocols supporting secure network systems
Anonymous communication
Recent cryptographic theory advances
Optical network security
Mobile wireless network security
Formal analysis of network security systems
Trends in network-based attacks
Secure group communication
Policy expression and enforcement
Papers in strongly related areas, especially those involving novel
technologies, are also encouraged.
The guest editors for this issue are
Hilarie Orman, University of Arizona, Department of Computer Science
Ueli Maurer, Swiss Federal Institue of Technology (ETH)
Stephen Kent, BBN Technologies
Stephen Bellovin, AT&T Laboratories
The schedule for authors is as follows:
February 5, 1999, manuscripts are due
May 3, 1999, notification of acceptance
August 5, 1999, final manuscripts are due
Manuscripts to be considered for submission should be sent by email to
Hilarie Orman (ho@cs.arizona.edu) by February 5, 1999. The manuscripts
must be in Postscript, viewable in ghostscript. The manuscripts must
be in Postscript, viewable in ghostscript, or six copies can be sent
by mail; contact Hilarie Orman well prior to the deadline for the
mailing address. Please note the IEEE formatting requirements;
information for authors can be found at:
http://gump.bellcore.com:5000/Guidelines/info.html The JSAC home page
is at http://gump.bellcore.com:5000/.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA06779 for ietf-pkix-bks; Mon, 5 Oct 1998 07:24:36 -0700 (PDT)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA06775 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 07:24:34 -0700 (PDT)
Received: id KAA26081; Mon, 5 Oct 1998 10:20:30 -0400
Received: by gateway id <4CGY9Q32>; Mon, 5 Oct 1998 10:18:29 -0400
Message-ID: <D789F71F24B4D111955D00A0C99B4F500139B06C@sothmxs01.entrust.com>
From: Robert Zuccherato <robert.zuccherato@entrust.com>
To: "'Santoni Adriano'" <santoni@sia.it>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: RE: Time Stamp and Notary Drafts
Date: Mon, 5 Oct 1998 10:16:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Thanks for your comments. My replies are embedded below.
> ----------
> From: Santoni Adriano[SMTP:santoni@sia.it]
> Sent: Monday, October 05, 1998 5:15 AM
> To: 'Robert Zuccherato'
> Cc: 'ietf-pkix@imc.org'
> Subject: R: Time Stamp and Notary Drafts
>
> Regarding the nonce field in timestamp requests and responses: the
> draft
> says (at page X) that the TSA must include the same nonce value the
> requestor specified in his request, in case he did. But how is the TSA
> going
> to determine that the requestor did specify a nonne value? I can
> imagine two
> possible answers: either the nonce field is OPTIONAL in the
> TimeStampReq,
> too (and not only in the response), or a "blank" value is established
> by
> convention (e.g. zero).
>
I had a request to include a second type of time stamp request. This
lower quality of service request would be http based and would just
return a "blank" token without a message imprint or nonce. Basically,
it would just be a signature on the current time. This would be a lower
quality of service because without a trusted source of time, one could
not verify that the returned token was "fresh". People would be able to
just go to a web site and pick up one of these tokens.
I am in the process of adding this option and have included the nonce in
the token as OPTIONAL to allow for it, but haven't fully described it
yet. If people want this service, I will include it. Otherwise, I
won't and the option on the nonce will be removed.
Notice however that the way things are presently described, the nonce in
the token must be present if the nonce is present in the request.
However, the nonce is mandatory in the request. Thus, using the present
protocol, the nonce is mandatory.
> Regarding the timestamp response (token): would not it be useful to
> include
> a pointer to an on-line repository, supposed to be run by the TSA,
> were all
> tokens are held and made available to everyone for browsing and
> downloading?
>
I am not entirely sure of the usefulness of this service. How would
such a repository be used? Could the tsaFreeData field be used for this
pointer?
> Remarks. The draft should make use, IMO, of the usual keywords (in
> all-uppercase) indicating requirement levels (MUST, MUST NOT, SHOULD,
> etc.)
> as per RFC 2119.
>
Certainly.
> A more elaborate explanation of how to intepret the
> reqPolicy field and some real-world scenarios would also be helpful.
>
I agree. There is a need for a document describing time stamp policy
and time stamp practice statements. These are all important issues.
However, in this document we are only trying to describe the protocol
that is to be used between these entities. Discussion of actual policy
issues is outside of its scope.
Robert.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA03316 for ietf-pkix-bks; Mon, 5 Oct 1998 02:09:55 -0700 (PDT)
Received: from ntsiaexch.office (exchange.sia.it [192.106.192.201]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA03312 for <ietf-pkix@imc.org>; Mon, 5 Oct 1998 02:09:45 -0700 (PDT)
Received: by ntsiaexch.office with Internet Mail Service (5.0.1461.28) id <4JBWNWYQ>; Mon, 5 Oct 1998 11:15:49 +0200
Message-ID: <8160937F4F4CD111A93E00805FC17529A59FCB@ntsiaexch.office>
From: Santoni Adriano <santoni@sia.it>
To: "'Robert Zuccherato'" <robert.zuccherato@entrust.com>
Cc: "'ietf-pkix@imc.org'" <ietf-pkix@imc.org>
Subject: R: Time Stamp and Notary Drafts
Date: Mon, 5 Oct 1998 11:15:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1461.28)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id CAA03313
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Yes, I have a couple of questions and a few remarks.
Regarding the nonce field in timestamp requests and responses: the draft
says (at page X) that the TSA must include the same nonce value the
requestor specified in his request, in case he did. But how is the TSA going
to determine that the requestor did specify a nonne value? I can imagine two
possible answers: either the nonce field is OPTIONAL in the TimeStampReq,
too (and not only in the response), or a "blank" value is established by
convention (e.g. zero).
Regarding the timestamp response (token): would not it be useful to include
a pointer to an on-line repository, supposed to be run by the TSA, were all
tokens are held and made available to everyone for browsing and downloading?
Remarks. The draft should make use, IMO, of the usual keywords (in
all-uppercase) indicating requirement levels (MUST, MUST NOT, SHOULD, etc.)
as per RFC 2119. A more elaborate explanation of how to intepret the
reqPolicy field and some real-world scenarios would also be helpful.
Regards.
Adriano Santoni
__________________________________________
Ing. Adriano Santoni
Direzione Rete - Servizio Progettazione Rete Logica
Società Interbancaria per l'Automazione - SIA S.p.A.
Viale Certosa, 218 - I-20156 Milano
Vox: +39 2 3005 277
Fax: +39 2 38003333
Plain email: santoni@sia.it
S/MIME email: asantoni@sia.it
Website: http://www.sia.it
> -----Messaggio originale-----
> Da: Robert Zuccherato [SMTP:robert.zuccherato@entrust.com]
> Inviato: lunedì 28 settembre 1998 18.37
> A: 'ietf-pkix@imc.org'
> Oggetto: Time Stamp and Notary Drafts
>
> As some of you may have noticed, I have submitted the latest versions of
> our
> Time Stamp and Data Certification Server drafts as PKIX Internet Drafts,
> in
> accordance with the decisions made in Chicago. These drafts are based on
> the drafts that we have been submitting independently on these topics for
> some time now and reporting to PKIX on their progress.
>
> The Time Stamp Draft describes a protocol in which a trusted Time Stamp
> Authority provides evidence that a message existed at a particular point
> in
> time. It is available at:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-00.txt
>
> The Data Certification Server provides "notary" type services (signature
> validation, certificate path validation) in support of non-repudiation.
> This draft is available at:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dcs-00.txt
>
> As usual, comments are welcome.
>
> Robert Zuccherato.
>
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA29023 for ietf-pkix-bks; Sun, 4 Oct 1998 23:38:50 -0700 (PDT)
Received: from setec.fi (smtp.setec.fi [195.236.90.20]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA29015 for <ietf-pkix@imc.org>; Sun, 4 Oct 1998 23:38:48 -0700 (PDT)
Received: (qmail 11492 invoked by uid 65534); 5 Oct 1998 06:31:59 -0000
Received: from eemeli.setec.fi (10.1.1.1) by smtp.setec.fi with SMTP; 5 Oct 1998 06:31:59 -0000
Received: from eemeli.setec.fi (unverified [127.0.0.1]) by 127.0.0.1 (Data Fellows SMTPRS 2.04) with ESMTP id <B0000024976@127.0.0.1>; Mon, 05 Oct 1998 09:37:47 +0200
Received: by eemeli.setec.fi with Internet Mail Service (5.0.1458.49) id <4DGYKNMK>; Mon, 5 Oct 1998 09:37:47 +0200
Message-Id: <514651EC9177D111ABE700805F0D75DC17B27B@eemeli.setec.fi>
From: =?iso-8859-1?Q?Siev=E4nen_Markku?= <markku.sievanen@setec.fi>
To: "'Tony Bartoletti'" <azb@llnl.gov>
Cc: "'pkix'" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Mon, 5 Oct 1998 09:37:46 +0200
X-Priority: 3
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1458.49)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id XAA29018
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi!
Tony, don't mix the diffrent roles of PKI. CA is not responsible, if
your's "Acme Hardware" doesn't
return to You anything. CA is only responsible that there is a "secure
path" to validate the check, which is digitally signed. And in that role
CA and PKI infra works fine, if it is build up correctly with building
blocks like smart cards, certicate policies and so on.
Of course, in addition to that, You need "specific security protocols"
to different application sectors, like
e-commerce, to make the whole system work. These protocols might use
Notary Services to make sure,
that "You really get what you paid".
MaSi
> -----Original Message-----
> From: Tony Bartoletti [SMTP:azb@llnl.gov]
> Sent: Friday, October 02, 1998 9:00 PM
> To: Anders Rundgren; 'Ed Gerck'
> Cc: 'ietf-pkixÉimc.org '
> Subject: RE: NEW Data type for certificate selection ?
>
> At 07:59 AM 10/2/98 +0200, Anders Rundgren wrote:
> >Ed,
> >>The first usual misconception here is when people confuse trust in a
> >>certificate to trust in a certificate's contents -- too quite
> >>different animals. In fact, the first is directly defined under
> X.509
> >>or PKIX but the second depends on the CPS, which depends on each CA,
> >>which systematically negate it.
> >
> >Systematically negate it?
> >
> >Sorry, I fail to understand why it is technically, legally, etc.
> impossible to create trusted
> >CA services that issues certificates with contents that can actually
> be used. But as I said earlier,
> >Swedes are probably morons as we just do it anyway in spite of the
> fact that it does not work :-)
> >
> >Anders
>
> Anders,
>
> Current certification systems do "work", much as an ordinary telephone
> directory works. The analogy would be closer if the publisher of the
> phone book digitally signed each entry.
>
> The phone book works because most people are honest and want to help
> make things work. But I have no real way of knowing that the entry
> for "Acme Hardware, Third Street" is indeed a hardware store, or can
> be trusted to perform as I might expect it to.
>
> People expect a digital-sig PKI to somehow automatically provide the
> root of trust that is needed. Indeed, the terminology "root key",
> "root CA" suggests as much. But unless a third party can be relied
> upon to reimburse me for my losses, when I send a digital check to
> "Acme Hardware" and recieve nothing in return, this third party is
> really not much more than a telephone directory.
>
> We want more, and need more from PK technology. The emerging PKIs
> are a start, a component, and a limited one. Again, it does "work"
> in a statistical sense, because most people are not crooks.
>
> My 2 cents.
>
> ___tony___
>
>
>
> Tony Bartoletti LL
> SPI-NET GURU LL LL
> Computer Security Technology Center LL LL LL
> Lawrence Livermore National Lab LL LL LL
> PO Box 808, L - 303 LL LL LLLLLLLL
> Livermore, CA 94551-9900 LL LLLLLLLL
> email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA19309 for ietf-pkix-bks; Sat, 3 Oct 1998 00:46:20 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA19303 for <ietf-pkix@imc.org>; Sat, 3 Oct 1998 00:46:17 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA17633; Sat, 3 Oct 1998 09:46:12 +0200
Received: by HYDRA with Microsoft Mail id <01BDEEB1.C1719370@HYDRA>; Sat, 3 Oct 1998 09:39:45 +0200
Message-ID: <01BDEEB1.C1719370@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Tony Bartoletti'" <azb@llnl.gov>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'Ed Gerck'" <egerck@laser.cps.softex.br>
Subject: RE: NEW Data type for certificate selection ?
Date: Sat, 3 Oct 1998 09:39:43 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA19305
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Tony,
>But unless a third party can be relied
>upon to reimburse me for my losses, when I send a digital check to
>"Acme Hardware" and recieve nothing in return, this third party is
>really not much more than a telephone directory.
Well, I do not share your optimism (?) that such problems have technical
solutions because there are only a few digital ways to adjust for human errors.
That there ever will be third parties that guarantee all kind of losses is
highly unlikely. They simply have to guarantee that the certificates they
issue belongs to known entities. A DUN-number for a company, a
PPIT for a person or a valid credit-card number for a SET-certificate.
And of course run a CA in a sensible way...
That is not rocket-science and we don't need it either!
Biometrical PIN-code replacements will improve the trust you have in clients.
For servers I see few improvements except maybe that some data
can be searched for at public sites. I.e. they may have to agree to
that to get a certificate of the type that you want to trust.
Just my 2 öre
Anders Rundgren
Senior Internet E-commerce Architect
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA29829 for ietf-pkix-bks; Fri, 2 Oct 1998 12:01:43 -0700 (PDT)
Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.18.65]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29825 for <ietf-pkix@imc.org>; Fri, 2 Oct 1998 12:01:42 -0700 (PDT)
Received: from catalyst (catalyst.llnl.gov [128.115.223.10]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2) with SMTP id MAA20418; Fri, 2 Oct 1998 12:00:59 -0700 (PDT)
Message-Id: <3.0.3.32.19981002115946.00b18d50@poptop.llnl.gov>
X-Sender: e048786@poptop.llnl.gov
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Fri, 02 Oct 1998 11:59:46 -0700
To: Anders Rundgren <anders.rundgren@jaybis.com>, "'Ed Gerck'" <egerck@laser.cps.softex.br>
From: Tony Bartoletti <azb@llnl.gov>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
In-Reply-To: <01BDEDDA.A7BD0CC0@HYDRA>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
At 07:59 AM 10/2/98 +0200, Anders Rundgren wrote:
>Ed,
>>The first usual misconception here is when people confuse trust in a
>>certificate to trust in a certificate's contents -- too quite
>>different animals. In fact, the first is directly defined under X.509
>>or PKIX but the second depends on the CPS, which depends on each CA,
>>which systematically negate it.
>
>Systematically negate it?
>
>Sorry, I fail to understand why it is technically, legally, etc. impossible to create trusted
>CA services that issues certificates with contents that can actually be used. But as I said earlier,
>Swedes are probably morons as we just do it anyway in spite of the fact that it does not work :-)
>
>Anders
Anders,
Current certification systems do "work", much as an ordinary telephone
directory works. The analogy would be closer if the publisher of the
phone book digitally signed each entry.
The phone book works because most people are honest and want to help
make things work. But I have no real way of knowing that the entry
for "Acme Hardware, Third Street" is indeed a hardware store, or can
be trusted to perform as I might expect it to.
People expect a digital-sig PKI to somehow automatically provide the
root of trust that is needed. Indeed, the terminology "root key",
"root CA" suggests as much. But unless a third party can be relied
upon to reimburse me for my losses, when I send a digital check to
"Acme Hardware" and recieve nothing in return, this third party is
really not much more than a telephone directory.
We want more, and need more from PK technology. The emerging PKIs
are a start, a component, and a limited one. Again, it does "work"
in a statistical sense, because most people are not crooks.
My 2 cents.
___tony___
Tony Bartoletti LL
SPI-NET GURU LL LL
Computer Security Technology Center LL LL LL
Lawrence Livermore National Lab LL LL LL
PO Box 808, L - 303 LL LL LLLLLLLL
Livermore, CA 94551-9900 LL LLLLLLLL
email: azb@llnl.gov phone: 510-422-3881 LLLLLLLL
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27939 for ietf-pkix-bks; Fri, 2 Oct 1998 07:37:51 -0700 (PDT)
Received: from ns.interax.com (interax.com [207.78.8.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27935 for <ietf-pkix@IMC.ORG>; Fri, 2 Oct 1998 07:37:50 -0700 (PDT)
From: administrator@bvc.org
Received: from ntserver.bvc (NTSERVER [207.78.8.214]) by ns.interax.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id 4D9M8NY2; Fri, 2 Oct 1998 10:37:39 -0400
Received: by mis_server with Internet Mail Service (5.0.1460.8) id <ST2JLAN3>; Fri, 2 Oct 1998 08:44:29 -0400
Message-ID: <45B30763EBBDD1119458006097AC2E33037738@mis_server>
To: ietf-pkix@imc.org
Subject: RE: Notification: Inbound Mail Failure
Date: Fri, 2 Oct 1998 08:44:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
KWhite@BVC.Org is no longer a valid E-Mail Account. Please stop sending
these messages. Thank You.
-----Original Message-----
From: Administrator
Sent: Thursday, October 01, 1998 10:32 AM
To: Administrator
Subject: Notification: Inbound Mail Failure
The following recipients did not receive the attached mail. Reasons are
listed with each recipient:
<KWhite@BVC.ORG> KWhite@BVC.ORG
MSEXCH:IMS:Business Volunteerism Council:BVC:NTSERVER 0 (000C05A6)
Unknown Recipient
The message that caused this notification was:
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27928 for ietf-pkix-bks; Fri, 2 Oct 1998 07:37:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27924 for <ietf-pkix@imc.org>; Fri, 2 Oct 1998 07:37:23 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02436; Fri, 2 Oct 1998 10:36:52 -0400 (EDT)
Message-Id: <199810021436.KAA02436@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-ocsp-07.txt
Date: Fri, 02 Oct 1998 10:36:51 -0400
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
--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 : X.509 Internet Public Key Infrastructure
Online Certificate Status Protocol - OCSP
Author(s) : M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams
Filename : draft-ietf-pkix-ocsp-07.txt
Pages : 20
Date : 01-Oct-98
This document specifies a protocol useful in determining the current
status of a digital certificate without requiring CRLs. Additional
mechanisms addressing PKIX operational requirements are specified in
separate documents.
An overview of the protocol is provided in section 3. Functional
requirements are specified in section 4. Details of the protocol are
in section 5. We cover security issues with the protocol in section
6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
syntactic elements and appendix C specifies the mime types for the
messages.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document (in uppercase, as shown) are to be interpreted as described
in [RFC2119].
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-ocsp-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ocsp-07.txt
Internet-Drafts directories are located at:
Africa: ftp.is.co.za
Europe: ftp.nordu.net
ftp.nis.garr.it
Pacific Rim: munnari.oz.au
US East Coast: ftp.ietf.org
US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ietf.org. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-ocsp-07.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: <19981002102031.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ocsp-07.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-ocsp-07.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19981002102031.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA19323 for ietf-pkix-bks; Thu, 1 Oct 1998 23:46:00 -0700 (PDT)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA19262; Thu, 1 Oct 1998 23:45:28 -0700 (PDT)
Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id SAA17892; Fri, 2 Oct 1998 18:44:52 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz)
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <90731069200784>; Fri, 2 Oct 1998 18:44:52 (NZST)
From: pgut001@cs.auckland.ac.nz (Peter Gutmann)
To: cert-talk@structuredarts.com, ietf-pkix@imc.org, ietf-smime@imc.org
Subject: Updated ASN.1 dump program uploaded
Reply-To: pgut001@cs.auckland.ac.nz
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Fri, 2 Oct 1998 18:44:52 (NZST)
Message-ID: <90731069200784@cs26.cs.auckland.ac.nz>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
I've just uploaded the latest update of my ASN.1 dump/diagnostic tool to
http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.{c,cfg}. The main changes are
more OIDs in the config file, a kludge workaround for when it can't locate the
config file if argv[0] is set wrong (you can also tell it manually where the
file is with the -c option), and more options for picking apart ASN.1
objects. Run it with no args for a help screen.
Peter.
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA18754 for ietf-pkix-bks; Thu, 1 Oct 1998 23:29:25 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA18746 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 23:29:23 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id DAA29758; Fri, 2 Oct 1998 03:29:19 -0300
Date: Fri, 2 Oct 1998 03:29:18 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Anders Rundgren <anders.rundgren@jaybis.com>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <01BDEDDA.A7BD0CC0@HYDRA>
Message-ID: <Pine.LNX.4.02.9810020308410.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Fri, 2 Oct 1998, Anders Rundgren wrote:
> Ed Gerck wrote:
>>
>>The first usual misconception here is when people confuse trust in a
>>certificate to trust in a certificate's contents -- too quite
>>different animals. In fact, the first is directly defined under X.509
>>or PKIX but the second depends on the CPS, which depends on each CA,
>>which systematically negate it.
>
>Systematically negate it?
>
>Sorry, I fail to understand why it is technically, legally, etc. impossible to create trusted
>CA services that issues certificates with contents that can actually be used. But as I said earlier,
>Swedes are probably morons as we just do it anyway in spite of the fact that it does not work :-)
Anders:
;-) As I suggested in my earlier msg, let us please leave
water-splashing to the ducks! Looks fun, but no work is done.
Probably you just could not yet read the reference I provided, which
is at http://143.106.29.39/certover.pdf -- "Overview of Certification
Systems: X.509, CA, PGP and SKIP". There is also a (older but more
complete) HTML version at cert.htm
However, the very end of its section on X.509 has the following text,
which I think will address your concerns -- please read the rest of
the paper for the context. You can also check the "Misconception"
series in the mcg-talk archives and the posting "Is there a business
for CAs?" -- the address is http://143.106.29.39/emails.htm
====================================================================
....[snip]
This paper reviews the three most common certification methods in use
today, which are based on X.509 Certificates and Certification
Authorities, PGP and, SKIP. These methods are studied from a systemic
point of view. The main motivations for this paper are: (i) Conduct a
comparative review of the three methods, (ii) Unify a set of
references to the most important issues in certification and
encryption, as they are related to Internet needs and recent
governmental policies, (iii) Provide a basis for the evaluation of
other certification solutions available or to be developed, (iv)
Identify room for improvements on the current security level of
certification, that could be dealt with by other methods, (v) Access
the impact on Internet transaction security due to the security
control policy needs of Governments currently actively promoting such
policy solutions.
....[snip]
In summary, there are many reasons that may jeopardize a
"certificate", create a weak link or, give the wrong contextual clues
for on-the-spot decision making.
The uncertainty reaches a point of almost uselessness, where CAs
usually explicitly state in the certification contracts that the CA
is exempt of all or almost all responsibility regarding the
"certificate", its accuracy and its data. For example:
VERISIGN DISCLAIMS ANY WARRANTIES WITH RESPECT TO THE SERVICES
PROVIDED BY VERISIGN HEREUNDER INCLUDING WITHOUT LIMITATION ANY
AND ALL IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. VERISIGN MAKES NO REPRESENTATION OR WARRANTY
THAT ANY CA OR USER TO WHICH IT HAS ISSUED A DIGITAL ID IN
THE VERISIGN SECURE SERVER HIERARCHY IS IN FACT THE PERSON OR
ORGANIZATION IT CLAIMS TO BE WITH RESPECT TO THE INFORMATION
SUPPLIED TO VERISIGN. VERISIGN MAKES NO ASSURANCES OF THE
ACCURACY, AUTHENTICITY, INTEGRITY, OR RELIABILITY OF
INFORMATION CONTAINED IN DIGITAL IDS OR IN CRLs COMPILED,
PUBLISHED OR DISSEMINATED BY VERISIGN, OR OF THE
RESULTS OF CRYPTOGRAPHIC METHODS IMPLEMENTED.
However, the issuer's disclaimer (i.e., the CA's) is generally not
visible in the certificate itself, for all browsers and all
X.509 implementations.
Further, such CA disclaimers are part of the CA's CPS (Certification
Practice Statement, which is outside the scope of X.509 and
constitutes the governing law that the CA presents to potential
clients). Thus, it can be seen as a legally-enforced way to reduce
deliverables to almost zero -- which is an accepted legal practice to
effectively reduce liability to zero. So, the point is not so much
that CAs deliver a product with zero warranty (which could be
disputed in court even in countries with common-law systems) but that
CAs are delivering a product with almost zero content (which any
court would accept as envolving almost zero liability) -- as it is
clearly exemplified in the second and third sentences of the above
disclaimer ("...MAKES NO REPRESENTATION ..." and "...MAKES NO
ASSURANCES ...").
Actually, the content of a CA's services in relationship to the
subject's data is not zero because there are two items that X.509
mandates and that a CA must deliver in a certificate without content
disclaimers (but, which may still be limited in scope by the CPS):
(i) that the subject's public-key has a working private-key
counterpart elsewhere (with no warranties that the public/private key
pair is not artifically weakened, that it is actually in the
possession of the named subject and that no one else has obtained a
copy of it), and (ii) that the subject's DN is unique to that CA
(with no warranties that such DN contains the actual subject's name,
location or that the subject even exists or has a correctly spelled
name -- as in "Internet Serices"). There are other items in the
certificate which have no relationship to the data supplied by the
subject but which are necessary for the proper use of the certificate
as a secure transport for information in the X.509 model, such as its
serial number, date of issuance, validity, the CA's signature, etc.,
which usually also carry limited CPS warranties (e.g., as in the case
of fraud, computer viruses, etc.) that may further jeopardize the
secure use of the certificate, without the user being even aware of
it.
Now, having cited Verisign's disclaimer, it is important to
understand its reasoning and need. It does not say that Verisign has
no warranty on its services or that it does not take any liability on
them. It only says that Verisign has no warranties and accepts no
liability for services that Verisign does not recognize it provides.
The fact that Verisign does not provide what perhaps the majority may
think they provide is another point altogether. The solution is,
perhaps, much more to educate the majority than to expect a company
to do what is maybe technically unfeasible in X.509 terms. Thus, in
the author's opinion, Verisign's CPS is not at all at odds with X.509
or legislation -- so, it could very well be an example to be copied.
Maybe, it just truly represents the maximum one commercially and
technically could wish for in X.509's and CPS's terms.
Thus, for any generic CA one might expect a similar reasoning.
Indeed, if the only thing that a CA does (as per X.509) is to
challenge the subscriber's private-key in order to bind the
corresponding public-key with the subscriber's DN and, if it signs
the certificate with a CPS that says that any other data are being
copied as received but have not been verified (and have thus no
warranty) then the CA has no responsibility for the contents of the
certificate -- save the positive acknowledgement that the public-key
did have a counterpart when it was linked to that DN (where the CPS
could further provide exceptions for frauds, virus, MITM attacks,
etc.).
One may ask, why are such content limitations and disclaimers
necessary for certificates? First, a certificate is not like a car
that has a limited liablity in space and time (after all, a car is a
localized entity that can contain a limited number of people and only
one driver). A certificate can be endlessly multiplied and
simultaneously presented in a planet-wide area. Certificates are used
without limit in a chain of events, which can include other fully
unrelated certificates and people. With the growing attitude of
seeking large legal compensation for one's lack of foresight, the
liability pyramid created by a lesser disclaimer could easily extend
to the CA's client's clients and so on.
Insurance protection may help here, but there are several issues that
must be touched upon. The use of insurance always signals lack of
knowledge -- so it clearly cannot replace it. Further, there is no
insurance needed for a sure event and there is no insurance possible
for a sure risk. If a user (ie, a CA subscriber) is going to for pay
insurance to cover his liabilities and the CA's liabilities (which is
what it amounts to), then responsibility has gone full-circle and is
now only in the user's hands -- both to get adequate coverage and to
pay for it. While the CA has zero risk and cashes in as the middleman
between the user and the insurance companies. However, that does not
solve the risk problem for the user either, because one cannot make
the whole world sign up one huge insurance policy -- so the user and
the CA may be protected by the insurance policy that the user has
bought with their names as beneficiaries but that does not protect a
third-party (ie, the rest of the world). Last, since CA auditing does
not help here, then insurance does not have a reliable risk estimator
either, even for the CA subscriber.
Regarding recent legislation efforts, such as in Utah (US), Illinois
(US) and other legislation, it is clear form the above discussion
that demanding broader warrants by law can be self-defeating because
CAs may then be forced to reduce the deliverables to zero -- instead
of coming out and providing for more warranties. There simply is a
limit to what X.509 and the CA paradigm can offer regarding legal
certificate reliance and -- most importantly and often confused with
the former -- legal certificate content reliance. Law cannot push the
technical envelope of X.509.
When confronted with risk situations, a normal business solution is
to rely on auditing. However, auditing of a CA's certificates is also
a difficult, if not impossible, task. This is due to X.509, which
allows CA's practices and policies to be built upon islands of
self-regulation exactly on the most important issues of trust and
trust management. As publicly declared by Phillip Hallam-Baker, a
Verisign consultant, not only are the CPSs indeed different and
self-made by each CA but they are not designed to be audited, either:
"There is not as yet a defined standard for CA practices against
which a company may be audited. In effect each company states their
own practices in their Certificate Practices Statement (CPS). The CPS
is not a document designed for auditing use however. It describes a
'specification', it does not describe details which may be checked by
a third party in a systematic manner."
Thus, a X.509 certificate is essentially a bag of bytes, which
meaning and validity strongly depends on the CA. Moreover, in legal
reliance terms, one may trust the confirmation procedures of the CA
during certificate reliance, but one cannot rely upon them for other
than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules --
therefore, a X.509 certificate is neither necessarily meaningful nor
valid in a user's reference frame or for the user's purposes.
Last, when one waches for some time the different mailing lists that
collects doubts and questions on certification systems from users or,
when one reads the majority of the newspaper or magazine articles on
the subject, one cannot help but perceive a pervailing feeling in the
user community to the effect that a certificate is magically infused
with trustworthiness -- which would imply a deterministic and
absolute view of certification. For example, as one user wrote:
"Please provide me with a list of all trusted CAs so that I can enter
those certificates into my browser.", few understand that trust must
be evaluated relative to the user -- the party at risk. Thus, the
very names Trusted Third Party or trusted CA raise already several
questions:
- in relationship to whom?
- trusted by whom?
- trusted for what?
- trusted for how long?
-- etc.
How are these questions answered? Clearly, by each user (ie, verifier
or, relying party -- who is at risk) in its own domain, references
and terms. This means that certificates are essentially statements
from a CA, not fact, and that meaning and trust on a certificate
(like beauty) is in the eyes of the beholder, i.e., depends on each
user.
==================================================================
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
---- Meta-Certificate Group Member -- http://www.mcg.org.br ---
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA16831 for ietf-pkix-bks; Thu, 1 Oct 1998 23:06:37 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id XAA16823 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 23:06:34 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id IAA21520; Fri, 2 Oct 1998 08:06:26 +0200
Received: by HYDRA with Microsoft Mail id <01BDEDDA.A7BD0CC0@HYDRA>; Fri, 2 Oct 1998 08:00:00 +0200
Message-ID: <01BDEDDA.A7BD0CC0@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Ed Gerck'" <egerck@laser.cps.softex.br>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Fri, 2 Oct 1998 07:59:59 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
>The first usual misconception here is when people confuse trust in a
>certificate to trust in a certificate's contents -- too quite
>different animals. In fact, the first is directly defined under X.509
>or PKIX but the second depends on the CPS, which depends on each CA,
>which systematically negate it.
Systematically negate it?
Sorry, I fail to understand why it is technically, legally, etc. impossible to create trusted
CA services that issues certificates with contents that can actually be used. But as I said earlier,
Swedes are probably morons as we just do it anyway in spite of the fact that it does not work :-)
Anders
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02333 for ietf-pkix-bks; Thu, 1 Oct 1998 17:18:32 -0700 (PDT)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02329 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 17:18:31 -0700 (PDT)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id RAA07570 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 17:18:00 -0700 (PDT)
Message-Id: <199810020018.RAA07570@crack.x509.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: Your message of "Fri, 02 Oct 1998 00:47:37 +0200." <3.0.32.19981002004700.00a4f600@m1.403.telia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 01 Oct 1998 17:18:00 -0700
From: Marc Branchaud <marcnarc@xcert.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Stefan Santesson <stefan@accurata.se> scrawled:
> =
> Marc,
> =
> If I follow you right you suggest that I use the knowledge from the SSL=
> negotiation to select the proper non-repudiation cert for signing
> transactions. I have thought of that but I have my doubts.
> =
Not necessarily from the SSL handshake itself (although since that's
already there it would be an optimization). But the same kind of mechani=
sm
could be employed, i.e. "here's a list of CAs whose certs I can accept."
> It would be very easy for the server to link knowledge from the link le=
vel
> (SSL) to the Application level (Javascript). The question is if that is=
> possible at the client side, by only using standard components (existin=
g or
> coming).
> =
So, you have this new requirement that nobody's really though of yet, and=
=
you're wondering if existing or planned components will solve your =
problem. Hmmm....
> Suppose the following steps:
> 1) The client browser knows which certificate was used to set up the SS=
L
> channel.
> 2) The server transfer a Javascript to the client in order to create th=
e
> electronic transaction form
> 3) After completing the form the Javascript request a signature on the
> completed form before it's transferred to the server.
> =
> Now even if the non-repudiation certificate and the SSL certificate was=
> issued by the same CA, Will any existing or planned version of any brow=
ser
> have the logic needed to find the right certificate. Not in theory, in
> practice.
> =
In practice, no such Javascript program exists so, practically speaking,
one would have to plan one's Javascript program to have such functionalit=
y.
I'm not familiar with web scripting languages, but I imagine that it's
possible to get the issuer DN of the server's cert and/or all the certs
presented by the server in the SSL handshake. Whether that's existing or=
=
planned, I have no idea.
As for whatever matching rule is required, it will most likely be =
implemented by the applet than the browser. I expect few browser makers =
would be happy to write some kind of generic lookup function to answer =
queries of the form "I need a cert of type <fee> that has a <foo> and =
isn't <foe> but can be <fum>". They'd be much happier to simply expose =
the broswer's certificate store to the applet and let the applet do the =
search.
> If not, then the problem is real and needs a solution. And if a solutio=
n is
> needed I would like to see better selective mechanisms than just Issuer=
DN
> of the CA.
> =
This, I think, is the crucial issue. I'm having trouble seeing why
matching issuer DNs is inadequate. Is it because having a CA per =
application is impractical? Since we're talking about banking here, I =
can't believe that the answer would be "yes" [heck, with a moderate =
hierarchy, the user would only need one cert (from the root CA) to use al=
l =
of the bank's applications].
Please explain to me why saying "I need you to use a cert signed by one o=
f =
these CAs" isn't a good enough solution.
Marc
+------------------------------------------------------------------------=
+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC=
=2E
marcnarc@xcert.com PKI References page: www.xcert.co=
m
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------=
+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNhQbt1rdFXNdDxPlAQEtswL8CZltb8fpsRO5urWESF9Ps4FNVlO9rLui
8+eDmkaf9L7AnY+ljW7ZCYF0p8zk/f6d7xmpia+gxdQBxT6edKYOOTzsr2cwY3Hf
RITSfqoIf4XpQTy/N1lBRhGRLZ0qYYwR
=9JQx
-----END PGP SIGNATURE-----
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA01845 for ietf-pkix-bks; Thu, 1 Oct 1998 15:43:31 -0700 (PDT)
Received: from maila.telia.com (root@maila.telia.com [194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA01841 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 15:43:29 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id AAA15750; Fri, 2 Oct 1998 00:50:36 +0200 (CEST)
Received: from stefans (t1o68p113.telia.com [62.20.138.113]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id AAA15138; Fri, 2 Oct 1998 00:50:34 +0200 (CEST)
Message-Id: <3.0.32.19981002004700.00a4f600@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 02 Oct 1998 00:47:37 +0200
To: Marc Branchaud <marcnarc@xcert.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id PAA01842
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Marc,
If I follow you right you suggest that I use the knowledge from the SSL
negotiation to select the proper non-repudiation cert for signing
transactions. I have thought of that but I have my doubts.
It would be very easy for the server to link knowledge from the link level
(SSL) to the Application level (Javascript). The question is if that is
possible at the client side, by only using standard components (existing or
coming).
Suppose the following steps:
1) The client browser knows which certificate was used to set up the SSL
channel.
2) The server transfer a Javascript to the client in order to create the
electronic transaction form
3) After completing the form the Javascript request a signature on the
completed form before it's transferred to the server.
Now even if the non-repudiation certificate and the SSL certificate was
issued by the same CA, Will any existing or planned version of any browser
have the logic needed to find the right certificate. Not in theory, in
practice.
If not, then the problem is real and needs a solution. And if a solution is
needed I would like to see better selective mechanisms than just Issuer DN
of the CA.
/Stefan
At 11:28 AM 10/1/98 -0700, Marc Branchaud wrote:
>Content-Type: text/plain; charset=iso-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>
>Stefan, your bank application here actually requires two functions:
>
>(1) An automated way to select the non-repudiation cert to be used in ste=
>p =
>
>4, and (2) a way to let browser users create a non-repudiable signature =
>
>(setting aside for the moment the definition of what that is).
>
>This thread started out as a quest for (1). Well, that can easily be =
>
>achieved using existing mechanisms such as SSL. You already mentioned th=
>e =
>
>plastic card analogy, and it can work exactly the same way: the non-rep c=
>ert =
>
>and the SSL server's cert can share a common parent CA. When the browser=
> =
>
>receives the SSL server's cert chain the in SSL handshake, it can know th=
>at =
>
>only certs signed by one of those CAs should be used for these transactio=
>ns.
>
>It's just like the plastic cards, where the logo (DN) of the place you're=
>
>doing buisiness with matches the logo (DN) on one of your cards and so yo=
>u
>know which card to use.
>
>Now, (2) is a completely different problem, and is one that, unlike (1),
>currently requires some kind of plugin, seeing as how there is currently =
>no
>such thing as "signing a web form". However, selecting the proper cert i=
>s
>easy, since the "transaction form" that gets filled out came from a secur=
>e
>site and the SSL handshake contains enough info to match a CA to one of t=
>he
>user's certs. All that is required to to select one of the matching cert=
>s
>that has the nonRepudiation bit set, then present it to the user so that =
>he
>knows it's getting used when he clicks the button.
>
> Marc
>
>+------------------------------------------------------------------------=
>+
> Marc Branchaud \/
> Chief PKI Architect /\CERT INTERNATIONAL INC=
>=2E
> marcnarc@xcert.com PKI References page: www.xcert.co=
>m
> 604-640-6227 www.xcert.com/~marcnarc/PKI/
>+------------------------------------------------------------------------=
>+
> PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
>
>
>Stefan Santesson <stefan@accurata.se> scrawled:
>> =
>
>> Ed,
>> =
>
>> Now this is getting really exciting. I really want to understand what y=
>ou
>> are suggesting.
>> =
>
>> How would you create a Bank application over https: ?
>> Here is some simple design requirements:
>> 1) First a secure channel shall be created (using SSL/TLS)
>> 2) Through the secure channel the customer is allowed to view accounts,=
>
>> exchange rates etc.
>> 3) The customer is allowed to enter payment transactions.
>> 4) Each payment transaction shall be individually signed using the
>> customers non-repudiation certificate issued for the purpose.
>> 5) Each transaction signature shall require the customers conscious
>> acceptance.
>> =
>
>> Now. How can you create this function without a plug-in and without usi=
>ng
>> Javascript or similar.
>> I would be vary happy to know this.
>> =
>
>> /Stefan
>> =
>
>> At 12:29 PM 10/1/98 -0300, Ed Gerck wrote:
>> >On Thu, 1 Oct 1998, Stefan Santesson wrote:
>> >
>> >>Hi Ed,
>> >>
>> >>I'm just trying to understand what you are saying.
>> >>
>> >>Are what you are saying, that you would solve the problem generally b=
>y, for
>> >>each issuer, having a different Issuer DN, per certificate type? =
>
>> >>Well I have thought of that for the SSL/TLS case but I don't like it.=
>
>> >
>> >Stefan:
>> >
>> >;-)
>> >
>> >May I remind you that you wrote:
>> > =
>
>> > I realize that today there is no way to do this without distributing
>> > customized plug-in components to end-users
>> >
>> >However, there are actually TWO ways, as I mentioned in my previous
>> >postings, that do not involve plug-ins and do not need Javascript
>> >either (btw, a security risk right there).
>> >
>> >
>> >>Simply because many planned CA-services does not work that way and I'=
>m not
>> >>convinced that they should either.
>> >
>> >;-) Simply because you perhaps want to make commercial CA-services
>> >mandatory to Banks. However, that is neither needed to Banks nor
>> >desirable security wise.
>> >
>> >Further, if you want to name an objection, please do so. Generic
>> >"does not work that way", without qualifying the "that" or why -- is
>> >not useful in a discussion. SMTP carries only written words yet, not
>> >thoughts ;-)
>> >
>> >Can you be specific?
>> >
>> >>
>> >>The next question is, how do I use the SSL/TLS negotiation to pick th=
>e
>> >>right certificate for creating a signed object in a Java script?
>> >
>> >As I explained before, there are TWO ways to pick the intended
>> >certificate and no other cert. However, pls consider abandoning
>> >Javascripts to provide *functionality* -- even though JS may add
>> >embellishments. Several major companies and security concerned
>> >individuals do not use JS at all.
>> >
>> >Cheers,
>> >
>> >Ed Gerck
>> >______________________________________________________________________=
>
>> >Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br=
>
>> >http://novaware.cps.softex.br
>> > -- Member of the Meta-Certificate Group -- http://www.mcg.org.br =
>
>> >
>> >
>> >
>> >
>> >
>> -------------------------------------------------------------------
>> Stefan Santesson <stefan@accurata.se>
>> Accurata Systems=E4kerhet AB =
>
>> Lotsgatan 27 D Tel. +46-40 152211 =
>
>> 216 42 Malm=F6 Fax. +46-40 150790 =
>
>> Sweden Mobile +46-70 5247799
>> =
>
>> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
>> -------------------------------------------------------------------
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA29873 for ietf-pkix-bks; Thu, 1 Oct 1998 11:21:45 -0700 (PDT)
Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA29869 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 11:21:44 -0700 (PDT)
Received: from crack (localhost [127.0.0.1]) by crack.x509.com (8.8.7/XCERT) with ESMTP id LAA24399 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 11:28:20 -0700 (PDT)
Message-Id: <199810011828.LAA24399@crack.x509.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: Your message of "Thu, 01 Oct 1998 17:40:35 +0200." <3.0.32.19981001173958.00a24a00@m1.403.telia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 01 Oct 1998 11:28:20 -0700
From: Marc Branchaud <marcnarc@xcert.com>
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Stefan, your bank application here actually requires two functions:
(1) An automated way to select the non-repudiation cert to be used in ste=
p =
4, and (2) a way to let browser users create a non-repudiable signature =
(setting aside for the moment the definition of what that is).
This thread started out as a quest for (1). Well, that can easily be =
achieved using existing mechanisms such as SSL. You already mentioned th=
e =
plastic card analogy, and it can work exactly the same way: the non-rep c=
ert =
and the SSL server's cert can share a common parent CA. When the browser=
=
receives the SSL server's cert chain the in SSL handshake, it can know th=
at =
only certs signed by one of those CAs should be used for these transactio=
ns.
It's just like the plastic cards, where the logo (DN) of the place you're=
doing buisiness with matches the logo (DN) on one of your cards and so yo=
u
know which card to use.
Now, (2) is a completely different problem, and is one that, unlike (1),
currently requires some kind of plugin, seeing as how there is currently =
no
such thing as "signing a web form". However, selecting the proper cert i=
s
easy, since the "transaction form" that gets filled out came from a secur=
e
site and the SSL handshake contains enough info to match a CA to one of t=
he
user's certs. All that is required to to select one of the matching cert=
s
that has the nonRepudiation bit set, then present it to the user so that =
he
knows it's getting used when he clicks the button.
Marc
+------------------------------------------------------------------------=
+
Marc Branchaud \/
Chief PKI Architect /\CERT INTERNATIONAL INC=
=2E
marcnarc@xcert.com PKI References page: www.xcert.co=
m
604-640-6227 www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------=
+
PGP key fingerprint: 60 11 4B 9D 4E E5 2F 47 BD C5 C2 BF 26 DF 5A E1
Stefan Santesson <stefan@accurata.se> scrawled:
> =
> Ed,
> =
> Now this is getting really exciting. I really want to understand what y=
ou
> are suggesting.
> =
> How would you create a Bank application over https: ?
> Here is some simple design requirements:
> 1) First a secure channel shall be created (using SSL/TLS)
> 2) Through the secure channel the customer is allowed to view accounts,=
> exchange rates etc.
> 3) The customer is allowed to enter payment transactions.
> 4) Each payment transaction shall be individually signed using the
> customers non-repudiation certificate issued for the purpose.
> 5) Each transaction signature shall require the customers conscious
> acceptance.
> =
> Now. How can you create this function without a plug-in and without usi=
ng
> Javascript or similar.
> I would be vary happy to know this.
> =
> /Stefan
> =
> At 12:29 PM 10/1/98 -0300, Ed Gerck wrote:
> >On Thu, 1 Oct 1998, Stefan Santesson wrote:
> >
> >>Hi Ed,
> >>
> >>I'm just trying to understand what you are saying.
> >>
> >>Are what you are saying, that you would solve the problem generally b=
y, for
> >>each issuer, having a different Issuer DN, per certificate type? =
> >>Well I have thought of that for the SSL/TLS case but I don't like it.=
> >
> >Stefan:
> >
> >;-)
> >
> >May I remind you that you wrote:
> > =
> > I realize that today there is no way to do this without distributing
> > customized plug-in components to end-users
> >
> >However, there are actually TWO ways, as I mentioned in my previous
> >postings, that do not involve plug-ins and do not need Javascript
> >either (btw, a security risk right there).
> >
> >
> >>Simply because many planned CA-services does not work that way and I'=
m not
> >>convinced that they should either.
> >
> >;-) Simply because you perhaps want to make commercial CA-services
> >mandatory to Banks. However, that is neither needed to Banks nor
> >desirable security wise.
> >
> >Further, if you want to name an objection, please do so. Generic
> >"does not work that way", without qualifying the "that" or why -- is
> >not useful in a discussion. SMTP carries only written words yet, not
> >thoughts ;-)
> >
> >Can you be specific?
> >
> >>
> >>The next question is, how do I use the SSL/TLS negotiation to pick th=
e
> >>right certificate for creating a signed object in a Java script?
> >
> >As I explained before, there are TWO ways to pick the intended
> >certificate and no other cert. However, pls consider abandoning
> >Javascripts to provide *functionality* -- even though JS may add
> >embellishments. Several major companies and security concerned
> >individuals do not use JS at all.
> >
> >Cheers,
> >
> >Ed Gerck
> >______________________________________________________________________=
> >Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br=
> >http://novaware.cps.softex.br
> > -- Member of the Meta-Certificate Group -- http://www.mcg.org.br =
> >
> >
> >
> >
> >
> -------------------------------------------------------------------
> Stefan Santesson <stefan@accurata.se>
> Accurata Systems=E4kerhet AB =
> Lotsgatan 27 D Tel. +46-40 152211 =
> 216 42 Malm=F6 Fax. +46-40 150790 =
> Sweden Mobile +46-70 5247799
> =
> PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
> -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQB1AwUBNhPJw1rdFXNdDxPlAQEUDAL5Ab6kPwIeZiFlyLPHn/Kb5Tqb4x9G1fhJ
yqhoagj3lZuCk1UuO6648160+1u/zNwDCPbxDFIb6luWe68T16Jo7MxZnjZfKPK0
e2pSYkpwHht9mnYSMgA/AKNUQGq/Vrzk
=Xpjl
-----END PGP SIGNATURE-----
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA29447 for ietf-pkix-bks; Thu, 1 Oct 1998 10:24:57 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA29442 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 10:24:49 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id OAA28802; Thu, 1 Oct 1998 14:31:09 -0300
Date: Thu, 1 Oct 1998 14:31:09 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Anders Rundgren <anders.rundgren@jaybis.com>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, list@seis.nc-forum.com
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <01BDED68.1E552480@HYDRA>
Message-ID: <Pine.LNX.4.02.9810011355240.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Anders Rundgren wrote:
>Ed,
>You failed to comment on the *technical* part of my suggestion and went
>immediately to politics! Please spend some time on that part in spite
>of the fact that you think Swedes are morons (we must be as we have used PPITs
>extensively the last 30 years or so). And even morons want solutions to their
>stupid little problems. :-)
Anders:
I liked very much my visits to Sweden and Stockholm is specially
pretty, though I missed its Spring and Summer. It is also the leading
place in the world for ultra-short high-power Ti:Saphire lasers --
also selling to other Instituts in Europe including the Max-Planck in
Germany. One of the most hilarious things that happened to me in
Sweden was when I read a political comment in one of your neswpapers,
with an excellent drawing to go with it, that depicted two
politicians in a washbasin throwing words to one another -- and it
read "like ducks in a washbasin, happiliy throwing water at each
other and thinking that they are doing something great!"
I remember this now as I expect a better fate for this discussion.
>
>Note that unlike some certificates, certificates with PPITs
>are never published on a directory server. You may though check its status with
>OCSP or similar in case you (as a trusted party) received such a certificate.
I wish to copy one of my earlier remarks on this, as I think it shows
that I had no qualms with what you say above:
However, if we accept that there may be valid uses for "public-key
certs" which are not public, with all the security and privacy risks
that may ensue from such usage (such as when Bill trusts Monica that
trusts Linda; or, when Bill cannot revoke a token that was given to
Monica and which unfortunately Monica had to surrender) -- then we
must consider that each "non-public" public-key cert and private-key
will be handled either by a special application or by an interactive
and possibly customized procedure in a general application (eg, a
web browser). Which then answers subproblems (1) and (2) also for
"non-public" public-key certs.
>
>>> but to allow users to authenticate themselves
>>>using a valid certificate (be it electronical or physical) where the certificate
>>>receiver only must know what issuers (and domain) to trust.
>
>>This has nothing to do with YAPITs. It has to do with issuer trust
>>and key challenge-response.
>
>Not at all. challenge-response verifies that you really are in the possession of the certificate.
>In the physical world you compare the ID-card picture with the face of the card-holder.
>
No, I think you overshoot the target. The point being that after a
sucessful challenge-response with client/server authentication in
SSL, you have a secure channel that you and your party can trust at
most as you both currently trust the CA cert used to authenticate the
server/client certs (I say at most because, of course, that trust
also depends on your certs, your applications, etc. and not only on
the CA cert). Through that secure channel now you transit with
whatever information you may need and the other party be willing to
provide, be it PPITs, or YAPITs, or credit card numbers of course.
The first usual misconception here is when people confuse trust in a
certificate to trust in a certificate's contents -- too quite
different animals. In fact, the first is directly defined under X.509
or PKIX but the second depends on the CPS, which depends on each CA,
which systematically negate it.
The second usual misconception (derived from the first) is when
people confuse reliance on a cert with reliance on a cert's contents.
In legal reliance terms, one may trust the confirmation procedures of
the CA during certificate reliance, but one cannot rely upon them for
other than their value as a representation of the CA's authentication
management act expressed in the CA's own terms and rules --
therefore, a X.509 certificate is neither necessarily meaningful nor
valid in a user's reference frame or for the user's purposes. [Cf.
http://www.mcg.org.br/certover.pdf or cert.htm]
>>Each country/company/person can do as they please, but in a
>>competitive world market the one with least information exposure has
>>a large advantadge. BTW, is that not what security is all about ? ;-)
>
>Security has many faces. That you really are communicating with
>the right person is one example :-)
Which is not warranted by X.509/PKIX, neither by commercial CAs' CPS,
nor by commercial CAs' quarantees, nor by law (eg, the US UCC).
Unfortunately, it is also a common misconception (number three) to
think otherwise.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA29112 for ietf-pkix-bks; Thu, 1 Oct 1998 09:46:50 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA29108 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 09:46:48 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id NAA28777; Thu, 1 Oct 1998 13:53:42 -0300
Date: Thu, 1 Oct 1998 13:53:42 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: Anders Rundgren <anders.rundgren@jaybis.com>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19981001172310.00a3daa0@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9810011341570.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Stefan Santesson wrote:
>
>Ed,
>
>I just want to clearify that I don't want to see any YAPITs (or any other
>speciffic attribute) hardcoded by design into any certificate slection
>mechanism.
Stefan:
I am really glad you are taking private data such as SSN out of the
picture and out of the data that you need to have in a public cert --
for the second time in this thread.
>But I don't want to stop anyone from using it as selective criteria either.
However, I do want to guarantee that no one will be forced or coaxed
into accepting that "selective criteria". As I said, if you want to
have enough rope to hang yourself (eg, as in C) that is fine but just
don't make it mandatory to thy neighbor.
>
>To me the YAPIT (Yet Another Personal Information Token) discussion belongs
>in completely different dimension independent of the certificate select
>problem space. (even if it is an interesting subject).
>
Agreed -- iff it is taken out of that picture! As it is being done
now, again.
However, another point of my msg still remains. Can you pls address
my reply to your affirmation below:
>>> PPITs are not only designed to make big-brothers job easier :-),
>>> but to allow users to authenticate themselves using a valid
>>> certificate (be it electronical or physical) where the
>>> certificate receiver only must know what issuers (and domain) to
>>> trust.
where PPIT is your name for YAPTI and I commented:
>>This has nothing to do with YAPITs. It has to do with issuer trust
>>and key challenge-response.
>>
>>I affirm that a certificate may only be its signature in size -- a 20
>>byte string -- and that suffices to allow anything you can do with
>>any kilobyte-size X509v3 cert, or even mega-byte size. So, YAPTIs do
>>not really belong to certs as a functional need. To ignore this is to
>>ignore what certificates are.
>>
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28983 for ietf-pkix-bks; Thu, 1 Oct 1998 09:33:11 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA28979 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 09:33:08 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id NAA28768; Thu, 1 Oct 1998 13:40:10 -0300
Date: Thu, 1 Oct 1998 13:40:10 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19981001173958.00a24a00@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9810011329590.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Stefan Santesson wrote:
>--- Message on the SEIS mailing list (list@seis.nc-forum.com)
>
>Ed,
>
>Now this is getting really exciting. I really want to understand what you
>are suggesting.
>
>How would you create a Bank application over https: ?
;-) commercial enquiries pls to sales@novaware.com.br
>Here is some simple design requirements:
>1) First a secure channel shall be created (using SSL/TLS)
as explained in my previous postings, with server and client
authentication in SSL.
>2) Through the secure channel the customer is allowed to view accounts,
>exchange rates etc.
a question for a proper cgi-bin or Java servlet at the Bank's server.
>3) The customer is allowed to enter payment transactions.
sure, why not? He has (1) and (2) above at his disposal -- with all
needed functionality.
>4) Each payment transaction shall be individually signed using the
>customers non-repudiation certificate issued for the purpose.
as explained in my previous postings, with TWO options for that
implementation.
>5) Each transaction signature shall require the customers conscious
>acceptance.
>
;-) that you can NEVER guarantee over the Internet! Pls re-state your
goals and NEVER depend on that assumption.
>Now. How can you create this function without a plug-in and without using
>Javascript or similar.
>I would be vary happy to know this.
Well, I already tried to explain -- twice and with TWO options. Can
you tell me step by step, preferably by directly quoting my words of
the first posting where the solution was detailed, where is the
disconnect?
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA28875 for ietf-pkix-bks; Thu, 1 Oct 1998 09:19:35 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id JAA28871 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 09:19:33 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id SAA85194; Thu, 1 Oct 1998 18:26:32 +0200
Received: by HYDRA with Microsoft Mail id <01BDED68.1E552480@HYDRA>; Thu, 1 Oct 1998 18:20:07 +0200
Message-ID: <01BDED68.1E552480@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Ed Gerck'" <egerck@laser.cps.softex.br>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 18:20:06 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
You failed to comment on the *technical* part of my suggestion and went
immediately to politics! Please spend some time on that part in spite
of the fact that you think Swedes are morons (we must be as we have used PPITs
extensively the last 30 years or so). And even morons want solutions to their
stupid little problems. :-)
Note that unlike some certificates, certificates with PPITs
are never published on a directory server. You may though check its status with
OCSP or similar in case you (as a trusted party) received such a certificate.
>> but to allow users to authenticate themselves
>>using a valid certificate (be it electronical or physical) where the certificate
>>receiver only must know what issuers (and domain) to trust.
>This has nothing to do with YAPITs. It has to do with issuer trust
>and key challenge-response.
Not at all. challenge-response verifies that you really are in the possession of the certificate.
In the physical world you compare the ID-card picture with the face of the card-holder.
>Each country/company/person can do as they please, but in a
>competitive world market the one with least information exposure has
>a large advantadge. BTW, is that not what security is all about ? ;-)
Security has many faces. That you really are communicating with the right person is one example :-)
In the competitive world market there are always tradeoffs between "features" that
usually are in some conflict with each other. Like price and speed.
Convenience is also a selling point
Giving a PPIT to an employer is not the same thing as giving up your soul.
Giving a PPIT to everyone is surely stupid, not recommendable, but is unlikely
to give you half as much *real* problems as a publicly known e-mail addresses
or telephone numbers!
But lets get back to the technical track otherwise we must change mailing-list!
Anders
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28500 for ietf-pkix-bks; Thu, 1 Oct 1998 08:36:26 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28496 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:36:25 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id RAA14893; Thu, 1 Oct 1998 17:43:32 +0200 (CEST)
Received: from stefans (t1o68p85.telia.com [62.20.138.85]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id RAA29929; Thu, 1 Oct 1998 17:43:31 +0200 (CEST)
Message-Id: <3.0.32.19981001173958.00a24a00@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 17:40:35 +0200
To: Ed Gerck <egerck@laser.cps.softex.br>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA28497
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
Now this is getting really exciting. I really want to understand what you
are suggesting.
How would you create a Bank application over https: ?
Here is some simple design requirements:
1) First a secure channel shall be created (using SSL/TLS)
2) Through the secure channel the customer is allowed to view accounts,
exchange rates etc.
3) The customer is allowed to enter payment transactions.
4) Each payment transaction shall be individually signed using the
customers non-repudiation certificate issued for the purpose.
5) Each transaction signature shall require the customers conscious
acceptance.
Now. How can you create this function without a plug-in and without using
Javascript or similar.
I would be vary happy to know this.
/Stefan
At 12:29 PM 10/1/98 -0300, Ed Gerck wrote:
>On Thu, 1 Oct 1998, Stefan Santesson wrote:
>
>>Hi Ed,
>>
>>I'm just trying to understand what you are saying.
>>
>>Are what you are saying, that you would solve the problem generally by, for
>>each issuer, having a different Issuer DN, per certificate type?
>>Well I have thought of that for the SSL/TLS case but I don't like it.
>
>Stefan:
>
>;-)
>
>May I remind you that you wrote:
>
> I realize that today there is no way to do this without distributing
> customized plug-in components to end-users
>
>However, there are actually TWO ways, as I mentioned in my previous
>postings, that do not involve plug-ins and do not need Javascript
>either (btw, a security risk right there).
>
>
>>Simply because many planned CA-services does not work that way and I'm not
>>convinced that they should either.
>
>;-) Simply because you perhaps want to make commercial CA-services
>mandatory to Banks. However, that is neither needed to Banks nor
>desirable security wise.
>
>Further, if you want to name an objection, please do so. Generic
>"does not work that way", without qualifying the "that" or why -- is
>not useful in a discussion. SMTP carries only written words yet, not
>thoughts ;-)
>
>Can you be specific?
>
>>
>>The next question is, how do I use the SSL/TLS negotiation to pick the
>>right certificate for creating a signed object in a Java script?
>
>As I explained before, there are TWO ways to pick the intended
>certificate and no other cert. However, pls consider abandoning
>Javascripts to provide *functionality* -- even though JS may add
>embellishments. Several major companies and security concerned
>individuals do not use JS at all.
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
>http://novaware.cps.softex.br
> -- Member of the Meta-Certificate Group -- http://www.mcg.org.br
>
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28389 for ietf-pkix-bks; Thu, 1 Oct 1998 08:27:34 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28385 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:27:29 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28706; Thu, 1 Oct 1998 12:34:01 -0300
Date: Thu, 1 Oct 1998 12:33:58 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Paul Koning <pkoning@xedia.com>
cc: ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <199810011311.JAA00124@tonga.xedia.com>
Message-ID: <Pine.LNX.4.02.9810011230190.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Paul Koning wrote:
>>>>>> "Ed" == Ed Gerck <egerck@laser.cps.softex.br> writes:
>
> Ed> On Thu, 1 Oct 1998, Stefan Santesson wrote:
> >>...
> >> You and I can argue for centuries if certificates handled in
> >> browsers should, or should not, be allowed to contain SSN.
>
> Ed> No, I don't argue. As I wrote two msgs ago, some think they have
> Ed> valid reasons for it and I do not disagree with the need to
> Ed> preserve freedom.
>
>Unfortunately, the world (or at least the country) is infested with
>organizations that think they have a valid reason to ask for a SSN
>when in fact they have neither a valid reason nor any legal authority
>to do so. Some, if you pound on the table enough, will yield. (For
>example, my medical insurance started by asking for it, but when
>pushed conceded that they could make up a number instead. Surprised
>me; most outfits of that type don't have enough sense to see that.)
>
>So I would say that anything protocol mechanism that encourages this
>sort of abuse is evil and must be resisted.
Agreed 100%, especially in a public protocol. That is why I wrote
"some think thay have valid reasons".
However, freedom is never lost all at once (Hume) also means that
I must respect the desire of others -- as long and if and only if
that does not collide with mine.
Thanks,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28359 for ietf-pkix-bks; Thu, 1 Oct 1998 08:23:18 -0700 (PDT)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28355 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:23:16 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailb.telia.com (8.8.8/8.8.8) with ESMTP id RAA09379; Thu, 1 Oct 1998 17:30:22 +0200 (CEST)
Received: from stefans (t1o68p9.telia.com [62.20.138.9]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id RAA25917; Thu, 1 Oct 1998 17:30:20 +0200 (CEST)
Message-Id: <3.0.32.19981001172310.00a3daa0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 17:27:25 +0200
To: Ed Gerck <egerck@laser.cps.softex.br>, Anders Rundgren <anders.rundgren@jaybis.com>
From: Stefan Santesson <stefan@accurata.se>
Subject: RE: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA28356
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Ed,
I just want to clearify that I don't want to see any YAPITs (or any other
speciffic attribute) hardcoded by design into any certificate slection
mechanism.
But I don't want to stop anyone from using it as selective criteria either.
To me the YAPIT (Yet Another Personal Information Token) discussion belongs
in completely different dimension independent of the certificate select
problem space. (even if it is an interesting subject).
/Stefan
At 12:09 PM 10/1/98 -0300, Ed Gerck wrote:
>On Thu, 1 Oct 1998, Anders Rundgren wrote:
>
>>Hi Ed,
>>>Your suggestion:
>>>
>>>The solution is to add "salt" -- like it is done in UNIX passwords.
>>>For example, you can add 50 chars of salt or as many as you want -- a
>>>passphrase. The point here is that since you know the SSN and the
>>>salt, no one else can guess the SSN from a dictionary attack on only
>>>9 digits. Better still, you can change the hash in a new cert and
>>>keep the SSN constant, by changing the salt, so no one can verify
>>>your SSN in a new cert without your cooperation.
>>
>>As my countryman Stefan already pointed out we can argue for centuries
about the
>>use of SSNs or as I would call them: PPIT - Persistent Personal Identity
Tag.
>>
>>Assuming that you *actually* *have* *such* *a* *scheme* you loose all the
benefits of
>>PPITs by applying your "salted" methods to PPITs. PPITs are not only
designed to
>>make big-brothers job easier :-),
>
>Anders:
>
>I think you can call YAPITs (Yet Another Personal Information Token)
>whatever you like and I will further grant anyone the right to make
>his private information public -- IF he so desires. However, NOT by
>design, which is what you apparently defend to allow as a legitimate
>feature of a "security design". What you imply is similar to the
>"rationale" for GAK-ware considerations.
>
>> but to allow users to authenticate themselves
>>using a valid certificate (be it electronical or physical) where the
certificate
>>receiver only must know what issuers (and domain) to trust.
>>
>
>This has nothing to do with YAPITs. It has to do with issuer trust
>and key challenge-response.
>
>I affirm that a certificate may only be its signature in size -- a 20
>byte string -- and that suffices to allow anything you can do with
>any kilobyte-size X509v3 cert, or even mega-byte size. So, YAPTIs do
>not really belong to certs as a functional need. To ignore this is to
>ignore what certificates are.
>
>
>>This is a major benefit for
>>all parties as you can have a life-time password/userid replacement with
>>full security (technically speaking) independent on actual certificate.
>
>You are unfortunately fully mistaken. What you describe is similar to
>Faustus' dilemma: your security now versus your soul forever. Well,
>we all know how it ends. You cannot trade your life-long privacy in
>exchange for some degree of security now.
>
>> It simply
>>cuts costs and confusion (at the expense of personal integrity).
>
>If an expense cannot be paid back (as privacy cannot) then it is not
>an expense -- it is called a loss, in any country and possibly also
>in yours as you speak about your countryman above.
>
>I'd rather think non-parochially and strive to find and define
>methods which assert equal security rights -- irrespective of
>computational power, influence or supplier.
>
> > If this is
>>good or not is something the market (and in some cases national laws)
>>will decide. My personal opinion is that if successful PKIs (Stefan!) are
>>established based on PPITs the disbeliveers *may* change their mind.
>>
>
>Each country/company/person can do as they please, but in a
>competitive world market the one with least information exposure has
>a large advantadge. BTW, is that not what security is all about ? ;-)
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
>http://novaware.cps.softex.br
>
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28352 for ietf-pkix-bks; Thu, 1 Oct 1998 08:23:15 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28348 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:23:11 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28694; Thu, 1 Oct 1998 12:29:08 -0300
Date: Thu, 1 Oct 1998 12:29:07 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Stefan Santesson <stefan@accurata.se>
cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <3.0.32.19981001092359.00a2a820@m1.403.telia.com>
Message-ID: <Pine.LNX.4.02.9810011215550.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Stefan Santesson wrote:
>Hi Ed,
>
>I'm just trying to understand what you are saying.
>
>Are what you are saying, that you would solve the problem generally by, for
>each issuer, having a different Issuer DN, per certificate type?
>Well I have thought of that for the SSL/TLS case but I don't like it.
Stefan:
;-)
May I remind you that you wrote:
I realize that today there is no way to do this without distributing
customized plug-in components to end-users
However, there are actually TWO ways, as I mentioned in my previous
postings, that do not involve plug-ins and do not need Javascript
either (btw, a security risk right there).
>Simply because many planned CA-services does not work that way and I'm not
>convinced that they should either.
;-) Simply because you perhaps want to make commercial CA-services
mandatory to Banks. However, that is neither needed to Banks nor
desirable security wise.
Further, if you want to name an objection, please do so. Generic
"does not work that way", without qualifying the "that" or why -- is
not useful in a discussion. SMTP carries only written words yet, not
thoughts ;-)
Can you be specific?
>
>The next question is, how do I use the SSL/TLS negotiation to pick the
>right certificate for creating a signed object in a Java script?
As I explained before, there are TWO ways to pick the intended
certificate and no other cert. However, pls consider abandoning
Javascripts to provide *functionality* -- even though JS may add
embellishments. Several major companies and security concerned
individuals do not use JS at all.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
-- Member of the Meta-Certificate Group -- http://www.mcg.org.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28184 for ietf-pkix-bks; Thu, 1 Oct 1998 08:09:10 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28180 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:09:08 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28677; Thu, 1 Oct 1998 12:15:22 -0300
Date: Thu, 1 Oct 1998 12:15:20 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: "Olle E. Johansson" <oej@webway.se>
cc: Stefan Santesson <stefan@accurata.se>, David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
In-Reply-To: <36132C4B.8FB88F64@webway.se>
Message-ID: <Pine.LNX.4.02.9810011210380.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Olle E. Johansson wrote:
>Stefan Santesson wrote:
>
>> 1) In SSL the server may select preferred client certificate by Issuer DN,
>> and "certificate type"
>> 2) You suggest hashed SSN (social security numbers) using "salt"
>>
>Even if I don't know all the details in your scheme, I would like to put
>up a privacy warning here. A user might not want _any_ server to search
>the database of user certificates.
Olle:
As you can read in my previous full msg (where that part was taken
from), Stefan did not copy the following paragraph -- which I would
like to highlight and which fully answers your concern:
It is important to note that *if* the customer's browser fails to
authenticate the Bank's server, then this will generate a fatal
handshake-failure alert in SSL if the non-authenticated Bank still
tries to go into phase 2 above -- so, the second phase is privacy
protected by the first.
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
-- Member of the Meta-Certificate Group -- http://www.mcg.org.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA28135 for ietf-pkix-bks; Thu, 1 Oct 1998 08:03:47 -0700 (PDT)
Received: from laser.cps.softex.br (laser.cps.softex.br [143.106.29.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA28128 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 08:03:38 -0700 (PDT)
Received: from laser (laser [143.106.29.34]) by laser.cps.softex.br (8.8.7/8.8.7) with SMTP id MAA28673; Thu, 1 Oct 1998 12:09:59 -0300
Date: Thu, 1 Oct 1998 12:09:57 -0300 (EST)
From: Ed Gerck <egerck@laser.cps.softex.br>
To: Anders Rundgren <anders.rundgren@jaybis.com>
cc: "'Stefan Santesson'" <stefan@accurata.se>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: RE: NEW Data type for certificate selection ?
In-Reply-To: <01BDED1A.E60F0AC0@HYDRA>
Message-ID: <Pine.LNX.4.02.9810011143170.25643-100000@laser.cps.softex.br>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
On Thu, 1 Oct 1998, Anders Rundgren wrote:
>Hi Ed,
>>Your suggestion:
>>
>>The solution is to add "salt" -- like it is done in UNIX passwords.
>>For example, you can add 50 chars of salt or as many as you want -- a
>>passphrase. The point here is that since you know the SSN and the
>>salt, no one else can guess the SSN from a dictionary attack on only
>>9 digits. Better still, you can change the hash in a new cert and
>>keep the SSN constant, by changing the salt, so no one can verify
>>your SSN in a new cert without your cooperation.
>
>As my countryman Stefan already pointed out we can argue for centuries about the
>use of SSNs or as I would call them: PPIT - Persistent Personal Identity Tag.
>
>Assuming that you *actually* *have* *such* *a* *scheme* you loose all the benefits of
>PPITs by applying your "salted" methods to PPITs. PPITs are not only designed to
>make big-brothers job easier :-),
Anders:
I think you can call YAPITs (Yet Another Personal Information Token)
whatever you like and I will further grant anyone the right to make
his private information public -- IF he so desires. However, NOT by
design, which is what you apparently defend to allow as a legitimate
feature of a "security design". What you imply is similar to the
"rationale" for GAK-ware considerations.
> but to allow users to authenticate themselves
>using a valid certificate (be it electronical or physical) where the certificate
>receiver only must know what issuers (and domain) to trust.
>
This has nothing to do with YAPITs. It has to do with issuer trust
and key challenge-response.
I affirm that a certificate may only be its signature in size -- a 20
byte string -- and that suffices to allow anything you can do with
any kilobyte-size X509v3 cert, or even mega-byte size. So, YAPTIs do
not really belong to certs as a functional need. To ignore this is to
ignore what certificates are.
>This is a major benefit for
>all parties as you can have a life-time password/userid replacement with
>full security (technically speaking) independent on actual certificate.
You are unfortunately fully mistaken. What you describe is similar to
Faustus' dilemma: your security now versus your soul forever. Well,
we all know how it ends. You cannot trade your life-long privacy in
exchange for some degree of security now.
> It simply
>cuts costs and confusion (at the expense of personal integrity).
If an expense cannot be paid back (as privacy cannot) then it is not
an expense -- it is called a loss, in any country and possibly also
in yours as you speak about your countryman above.
I'd rather think non-parochially and strive to find and define
methods which assert equal security rights -- irrespective of
computational power, influence or supplier.
> If this is
>good or not is something the market (and in some cases national laws)
>will decide. My personal opinion is that if successful PKIs (Stefan!) are
>established based on PPITs the disbeliveers *may* change their mind.
>
Each country/company/person can do as they please, but in a
competitive world market the one with least information exposure has
a large advantadge. BTW, is that not what security is all about ? ;-)
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
http://novaware.cps.softex.br
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA27722 for ietf-pkix-bks; Thu, 1 Oct 1998 07:14:37 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA27718 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 07:14:36 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA05486; Thu, 1 Oct 1998 10:21:11 -0400 (EDT)
Message-Id: <199810011421.KAA05486@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-roadmap-00.txt
Date: Thu, 01 Oct 1998 10:21:11 -0400
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
--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 PKIX Roadmap
Author(s) : A. Arsenault, S. Turner
Filename : draft-ietf-pkix-roadmap-00.txt
Pages : 26
Date : 30-Sep-98
This document provides an overview or 'roadmap' of the work done by the
IETF PKIX working group. It describes some of the terminology used in
the working group's documents, and the theory behind an X.509-based PKI.
It identifies each document developed by the PKIX working group, and
describes the relationships among the various document. It also
provides advice to would-be PKIX implementors about some of the issues
discussed at length during PKIX development, in hopes of making it
easier to build implementations that will actually interoperate.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-pkix-roadmap-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-00.txt
Internet-Drafts directories are located at:
Africa: ftp.is.co.za
Europe: ftp.nordu.net
ftp.nis.garr.it
Pacific Rim: munnari.oz.au
US East Coast: ftp.ietf.org
US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv@ietf.org. In the body type:
"FILE /internet-drafts/draft-ietf-pkix-roadmap-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: <19980930102705.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-roadmap-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-pkix-roadmap-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19980930102705.I-D@ietf.org>
--OtherAccess--
--NextPart--
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA27202 for ietf-pkix-bks; Thu, 1 Oct 1998 06:06:39 -0700 (PDT)
Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA27198 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 06:06:38 -0700 (PDT)
Received: from xedia.com by relay4.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfjfg19152; Thu, 1 Oct 1998 09:11:52 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08642; Thu, 1 Oct 98 09:10:28 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA00124; Thu, 1 Oct 1998 09:11:37 -0400
Date: Thu, 1 Oct 1998 09:11:37 -0400
Message-Id: <199810011311.JAA00124@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: egerck@laser.cps.softex.br
Cc: ietf-pkix@imc.org
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com> <Pine.LNX.4.02.9810010015150.25643-100000@laser.cps.softex.br>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
>>>>> "Ed" == Ed Gerck <egerck@laser.cps.softex.br> writes:
Ed> On Thu, 1 Oct 1998, Stefan Santesson wrote:
>>...
>> You and I can argue for centuries if certificates handled in
>> browsers should, or should not, be allowed to contain SSN.
Ed> No, I don't argue. As I wrote two msgs ago, some think they have
Ed> valid reasons for it and I do not disagree with the need to
Ed> preserve freedom.
Unfortunately, the world (or at least the country) is infested with
organizations that think they have a valid reason to ask for a SSN
when in fact they have neither a valid reason nor any legal authority
to do so. Some, if you pound on the table enough, will yield. (For
example, my medical insurance started by asking for it, but when
pushed conceded that they could make up a number instead. Surprised
me; most outfits of that type don't have enough sense to see that.)
So I would say that anything protocol mechanism that encourages this
sort of abuse is evil and must be resisted.
paul
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA27094 for ietf-pkix-bks; Thu, 1 Oct 1998 05:52:12 -0700 (PDT)
Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA27090 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 05:52:10 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id OAA17953; Thu, 1 Oct 1998 14:59:15 +0200 (CEST)
Received: from stefans (t1o68p66.telia.com [62.20.138.66]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id OAA11341; Thu, 1 Oct 1998 14:59:10 +0200 (CEST)
Message-Id: <3.0.32.19981001145537.00a3a4e0@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 14:56:18 +0200
To: Andreas Berger <aberger@darmstadt.gmd.de>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id FAA27091
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
There are similarities with phone numbers, but an even better example is to
compare with plastic cards in your wallet.
Say that every plastic card is a certificate given to you to be used in a
certain context. When you by gas you use your petrol card, when you borrow
books you use your library card.
The service context determines which certificate (plastic) you are using.
In a computer environment this is the same. Depending on the service
context you will use different certificates and different private keys for
signatures and decryption.
To day there is no "good" way to communicate the "service context" to the
certificate selecting function in the client. What is proposed here is that
we define a mechanism for this so that a context aware server may help the
client to select a suitable certificate.
This is relevant for a wide range of application and service levels, from
communication services (SSL/TLS) up to application levels (S/MIME and Java
scripts). But regardless of implementation level a general data type could
be used to specify the certificate match rule. X.509 have defined 2
relevant match rules. certificateMatch and certificateExactMatch.
So all we basically have to do is to convince the TLS, S/MIME and Java
peoples to include this in their protocols and client-server products.
/Stefan
At 01:52 PM 10/1/98 +0100, Andreas Berger wrote:
>Is the problem of selecting certificates somewhat similar to the
>selection of telephone numbers?
>
>Example:
>
>have an application select a FAX number for my home phone from an
>address book entry. The numbers itself (the certificate) cannot be
>distinguished from other numbers, it is the attribute name "FAX, home"
>(or something like this) that shows the designated use of the number.
>
>A little difference exists, in that certificates usually contain some
>information about the intended use. But this information is not encoded
>in a uniform way. The decision is usually left to the application (which
>is the problem to be solved here?).
>
>Andreas
>--
>Fifty-three percent of Fortune 1000 executives think the
>Arch Deluxe is something that helps to run a computer.
>-- Jericho Communications
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id EAA26677 for ietf-pkix-bks; Thu, 1 Oct 1998 04:46:34 -0700 (PDT)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id EAA26673 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 04:46:32 -0700 (PDT)
Received: from darmstadt.gmd.de (pc-venedig [141.12.33.63]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id NAA05623; Thu, 1 Oct 1998 13:52:26 +0200 (MET DST)
Message-ID: <36137B2B.2ABE314@darmstadt.gmd.de>
Date: Thu, 01 Oct 1998 13:52:59 +0100
From: Andreas Berger <aberger@darmstadt.gmd.de>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Stefan Santesson <stefan@accurata.se>
CC: Ed Gerck <egerck@laser.cps.softex.br>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19981001092359.00a2a820@m1.403.telia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Is the problem of selecting certificates somewhat similar to the
selection of telephone numbers?
Example:
have an application select a FAX number for my home phone from an
address book entry. The numbers itself (the certificate) cannot be
distinguished from other numbers, it is the attribute name "FAX, home"
(or something like this) that shows the designated use of the number.
A little difference exists, in that certificates usually contain some
information about the intended use. But this information is not encoded
in a uniform way. The decision is usually left to the application (which
is the problem to be solved here?).
Andreas
--
Fifty-three percent of Fortune 1000 executives think the
Arch Deluxe is something that helps to run a computer.
-- Jericho Communications
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA21470 for ietf-pkix-bks; Thu, 1 Oct 1998 00:20:30 -0700 (PDT)
Received: from mailc.telia.com (root@mailc.telia.com [194.22.190.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA21464 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 00:20:28 -0700 (PDT)
Received: from d1o68.telia.com (root@d1o68.telia.com [62.20.138.241]) by mailc.telia.com (8.8.8/8.8.8) with ESMTP id JAA01602; Thu, 1 Oct 1998 09:27:32 +0200 (CEST)
Received: from stefans (t1o68p117.telia.com [62.20.138.117]) by d1o68.telia.com (8.8.8/8.8.5) with SMTP id JAA02214; Thu, 1 Oct 1998 09:27:31 +0200 (CEST)
Message-Id: <3.0.32.19981001092359.00a2a820@m1.403.telia.com>
X-Sender: u40400192@m1.403.telia.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 01 Oct 1998 09:24:36 +0200
To: Ed Gerck <egerck@laser.cps.softex.br>
From: Stefan Santesson <stefan@accurata.se>
Subject: Re: NEW Data type for certificate selection ?
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id AAA21467
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Ed,
I'm just trying to understand what you are saying.
Are what you are saying, that you would solve the problem generally by, for
each issuer, having a different Issuer DN, per certificate type?
Well I have thought of that for the SSL/TLS case but I don't like it.
Simply because many planned CA-services does not work that way and I'm not
convinced that they should either.
The next question is, how do I use the SSL/TLS negotiation to pick the
right certificate for creating a signed object in a Java script?
/Stefan
At 12:48 AM 10/1/98 -0300, Ed Gerck wrote:
>On Thu, 1 Oct 1998, Stefan Santesson wrote:
>
>>Ed,
>>
>>Thank you for very interesting input. If I may try a very compressed sum of
>>your discussion it would be:
>>
>>1) In SSL the server may select preferred client certificate by Issuer DN,
>>and "certificate type"
>
>Stefan:
>
>pls add in your 1) "if the server is non-anonymous"
>
>pls add also a 0) "a self-signed common CA cert for the server and
>user certs can make your life and the customer's life a lot more
>pleasant"
>
>>2) You suggest hashed SSN (social security numbers) using "salt"
>
>if you must add SSN-based info in a public cert, IMO yes!
>
>>
>>Regarding "certificate type" I can't find this as an active selection
>>mechanism. It is however mentioned as prerequisite that the certificate
>>type have to match the selected key exchange algorithm.
>>
>
>I fail to see why you "can't find this as an active selection
>mechanism" together with the issuer DN, even if you want to keep the
>same type for your repudiable and non-repudiable cases (which I
>possibly would not, but that is another story). As I wrote:
>
>>> (for higher security) with a different CA cert for each type.
>
>and, again, later in the same msg:
>
>>> Or, for higher security, the Bank can use different CA certs for
>>> each type and send their DNs accordingly, in each case.
>>>
>
>so, all you need is to have different "types" (ie, DNs) of CA certs,
>where both "types" should be signed by the same root CA cert of
>course and the public-key root CA cert should be included in the
>distribution.
>
>Can you pls explain what causes selection difficulties for you in the
>above scenario?
>
>>Regardless of this I fail to see how this can be used to pick the right
>>"non-repudiation" certificate in the Java script application.
>
>Please read above, I hope it is clearer now.
>
>> I also fail
>>to understand if you suggest that the current SSL/TLS functions solves all
>>my problems or just a part of them.
>>
>
>;-) If "all your problems" is what you stated, sure, all at one stop.
>
>>Do you suggest that a more general matching mechanism is not needed?
>>
>
>If the problem is what you defined, yes.
>
>>/Stefan
>>
>>P.s
>>Regarding hashed SSN with salt, I don't get how the "salt" solves this. If
>>the salt is unknown then the SSN can't be checked and if the salt is known
>>the dictionary attack is still possible.
>
>
>1. The salt is only known to those entities that should know the SSN
>-- not to the evildoer that is trying to get SSNs from a list of
>cached client certs, in a common access area or in memory.
>
>2. the salt is treated as client's private information -- and kept
>separate from the cert, in a protected area together with other
>private information from the client.
>
>BTW, this is similar to "dividing" a SSN "signature" into two parts,
>one public (in the cert) and another private (the salt).
>
>> I would say that your "salt" is
>>equal to suggest that the SSN should be encrypted with a secret key (where
>>the "salt" is being that secret key).
>>
>
>Yes, certainly -- but it is more appropriately called a keyed-MAC.
>
>BTW, I am glad that you now repudiate your phrase after your P.s
>above ;-)
>
>
>>You and I can argue for centuries if certificates handled in browsers
>>should, or should not, be allowed to contain SSN.
>
>No, I don't argue. As I wrote two msgs ago, some think they have
>valid reasons for it and I do not disagree with the need to preserve
>freedom. In that, I follow the C maxim -- even though I think that
>security work is perhaps not the best place to leave enough rope so
>that you may hang yourself with it if you so want or don't think it
>is dangerous...
>
>
>Cheers,
>
>Ed Gerck
>______________________________________________________________________
>Dr.rer.nat. E. Gerck egerck@novaware.cps.softex.br
>http://novaware.cps.softex.br
>
>
>
-------------------------------------------------------------------
Stefan Santesson <stefan@accurata.se>
Accurata Systemsäkerhet AB
Lotsgatan 27 D Tel. +46-40 152211
216 42 Malmö Fax. +46-40 150790
Sweden Mobile +46-70 5247799
PGP fingerprint: 89BC 6C79 5B3D 591B 8547 1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA20810 for ietf-pkix-bks; Thu, 1 Oct 1998 00:08:22 -0700 (PDT)
Received: from maila.telia.com (root@[194.236.189.4]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA20802 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 00:08:20 -0700 (PDT)
Received: from webway.se (t3o61p28.telia.com [195.67.228.148]) by maila.telia.com (8.8.8/8.8.8) with ESMTP id JAA16567; Thu, 1 Oct 1998 09:14:16 +0200 (CEST)
Message-ID: <36132C4B.8FB88F64@webway.se>
Date: Thu, 01 Oct 1998 09:16:27 +0200
From: "Olle E. Johansson" <oej@webway.se>
Organization: WebWay AB
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: Stefan Santesson <stefan@accurata.se>
CC: Ed Gerck <egerck@laser.cps.softex.br>, David Horvath <dave@chromatix.com>, Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>, "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>, "'list@seis.nc-forum.com '" <list@seis.nc-forum.com>, "'pgut001@cs.auckland.ac.nz '" <pgut001@cs.auckland.ac.nz>
Subject: Re: NEW Data type for certificate selection ?
References: <3.0.32.19981001003423.00a2d2b0@m1.403.telia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Stefan Santesson wrote:
> 1) In SSL the server may select preferred client certificate by Issuer DN,
> and "certificate type"
> 2) You suggest hashed SSN (social security numbers) using "salt"
>
Even if I don't know all the details in your scheme, I would like to put
up a privacy warning here. A user might not want _any_ server to search
the database of user certificates. The user might have certificates he
doesn't want a server, or rather the company running the server, to know
about.
It's like cookies...
Regards,
Olle
--
Olle E. Johansson, oej@webway.se
Mobile +46 70 593 68 51, phone +46 8 590 722 40, fax +46 8 590 759 80
WebWay AB, Sweden, http://www.webway.se
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA20776 for ietf-pkix-bks; Thu, 1 Oct 1998 00:07:30 -0700 (PDT)
Received: from caesar.udac.se (caesar.udac.se [193.44.79.10]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA20772 for <ietf-pkix@imc.org>; Thu, 1 Oct 1998 00:07:24 -0700 (PDT)
Received: from HYDRA ([195.67.109.114]) by caesar.udac.se (8.7.3/NetworkC-1) with SMTP id JAA26790; Thu, 1 Oct 1998 09:13:46 +0200
Received: by HYDRA with Microsoft Mail id <01BDED1A.E60F0AC0@HYDRA>; Thu, 1 Oct 1998 09:07:22 +0200
Message-ID: <01BDED1A.E60F0AC0@HYDRA>
From: Anders Rundgren <anders.rundgren@jaybis.com>
To: "'Ed Gerck'" <egerck@laser.cps.softex.br>, "'Stefan Santesson'" <stefan@accurata.se>
Cc: "'ietf-pkix@imc.org '" <ietf-pkix@imc.org>
Subject: RE: NEW Data type for certificate selection ?
Date: Thu, 1 Oct 1998 09:07:20 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-pkix@imc.org
Precedence: bulk
Hi Ed,
>Your suggestion:
>
>The solution is to add "salt" -- like it is done in UNIX passwords.
>For example, you can add 50 chars of salt or as many as you want -- a
>passphrase. The point here is that since you know the SSN and the
>salt, no one else can guess the SSN from a dictionary attack on only
>9 digits. Better still, you can change the hash in a new cert and
>keep the SSN constant, by changing the salt, so no one can verify
>your SSN in a new cert without your cooperation.
As my countryman Stefan already pointed out we can argue for centuries about the
use of SSNs or as I would call them: PPIT - Persistent Personal Identity Tag.
Assuming that you *actually* *have* *such* *a* *scheme* you loose all the benefits of
PPITs by applying your "salted" methods to PPITs. PPITs are not only designed to
make big-brothers job easier :-), but to allow users to authenticate themselves
using a valid certificate (be it electronical or physical) where the certificate
receiver only must know what issuers (and domain) to trust. This is a major benefit for
all parties as you can have a life-time password/userid replacement with
full security (technically speaking) independent on actual certificate. It simply
cuts costs and confusion (at the expense of personal integrity). If this is
good or not is something the market (and in some cases national laws)
will decide. My personal opinion is that if successful PKIs (Stefan!) are
established based on PPITs the disbeliveers *may* change their mind.
The general-purpose browser solution is as follows:
The authenticating server may surely *suggest* a list of possible certificate types
that it may accept because it is always *you* (the user) that should manually
select the proper one. In case you feel that a cert with PPIT could create a disaster
if you accidentally gave it to a wrong server the solution would be to have a local
(user-defined) set of valid servers (i.e. their public keys).
To insert a new server would require a few more clicks. I.e. similar to ActiveX
controls or signed Java Applets. Such servers would typically be
governmental (who gave you the PPIT) and a *few* other parties that
you hopefully trust like your bank or employer. A similar scheme could be used
for defining a list of valid receivers of mail signed with a cert containing an PPIT
(or other sensitive information).
Anders Rundgren
Senior Internet E-commerce Architect