Re: criticality conformance
Mark S Feldman <feldman@tis.com> Fri, 17 May 1996 19:34 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23673; 17 May 96 15:34 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa23669; 17 May 96 15:34 EDT
Received: from neptune.tis.com by CNRI.Reston.VA.US id aa14968; 17 May 96 15:34 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa06341; 17 May 96 15:03 EDT
Received: from relay.tis.com by neptune.TIS.COM id aa06322; 17 May 96 14:58 EDT
Received: by relay.tis.com; id OAA19302; Fri, 17 May 1996 14:59:53 -0400
Received: from sol.tis.com(192.33.112.100) by relay.tis.com via smap (V3.1) id xma019296; Fri, 17 May 96 14:59:23 -0400
Received: from pulsar.tis.com by tis.com (4.1/SUN-5.64) id AA15847; Fri, 17 May 96 14:59:35 EDT
Message-Id: <9605171859.AA15847@tis.com>
To: peter@verisign.com
Cc: Mark S Feldman <feldman@tis.com>, pem-dev@tis.com, solo@bbn.com, hoa@rsa.com
Subject: Re: criticality conformance
In-Reply-To: Your message of "Fri, 17 May 1996 09:20:54 PDT." <319CA766.27E3@verisign.com> --------
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/moss-signature"; micalg="md5"; boundary="----- =_aaaaaaaaaa0"
Date: Fri, 17 May 1996 15:01:59 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark S Feldman <feldman@tis.com>
X-Orig-Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk
... > Steve Crocker trained you well in constantly saying (so that people > might eventually believe you) X.509 cannot occur as there is no > infrastructure. Steve Crocker aside, I believe that X.509 can occur and hope that it does. > Turns out (now there is money flowing the certs business) the > infrastructure was there all along. I'll grant you that there are communities using certificates and some of those communities are large, but that's not the same as an infrastructure. The communities using certificates are doing so for their own purposes and their certificates are not necessarily used or accepted by others. It's a start. It's better than what we had before (nothing), but still has a way to go before it reaches infrasturture status. > D&B have huge organizational dbs, suitable for auth managament, and > Equifax have huge residential dbs suitable for... Yes, D&B, Equifax, TRW and the like *could* cache such information and make it available, which is pretty much what they do now with credit information. They may be part of the solution in the future, but they're not right now. > The directory problem has been solved by the Web; see several > directory services now available at URLs, and cert distribution within > those only required a mime-type... Solved? No, Making progress? Yes. > With refienement, LDAP may well be integrated into the Web as a > locator protocol for more refined service access, but its immaterial > functionally. > > > In the end, isn't the application granting a privilege the sole > > arbiter of the validity of a certificate? Maybe, as I said > > previously, "validity" is the wrong word. A certificate may be > > perfectly valid in the X.509 sense, but it may not be "valid for a > > particular purpose." > > Of course. certs only perform key distirbution. That key may be > obtained over such a channel which allows the applciation to assume > the properties are suitable for a given use. In practice such > properties come down to a policy oid, which the app can select on, and > know represent an authenicated channel of authoitative keying. > Subscriber agreement during certiifcate management then allows > consumers to decide whether the policies are suitable for use in > support of purpose A or B, or none. The cert is itself immaterial; > what matters is its background management procedures embodied in the > policy id. I would argue that some (many?) decisions are going to be made out-of-band, without the aid of policy ids. If you want to put more information in a certificate so that an application has more information on which to base a decision, great, but applications need not act on any particular information in that certificate. > > A specific extensions can easily be critical or non-critical in all > > cases. Being able to say otherwise in the certificate with the > > criticality flag creates confusion (I think this is similar to your > > original question). It is a shame that the OID space for extensions > > can't be divided into critical and non-critical (say, even and odd), > > creating an atomic bond between the extension and its criticality -- no > > need for external, possibly ambiguous, rules identifying extensions as > > critical or not. > > We can do this. IETF PKIX creates a pkix oid in the internet space, > and has two subtrees. Into one or the other it reassigns the numbers > of the ISO oids, and all IETF people use the IANA versions. Its only a > number, but with pkix-profiled criticality specialization suggested by > TIS. This is exactly how IETF needs to add value to the raw ISO work, > to make it practicable. Sounds good to me. Would be nice if such basic changes could be folded back into the ISO standard so that there would be fewer differences between pure ISO and the IETF defined use. Mark
- criticality conformance Peter Williams
- Re: criticality conformance Mark S Feldman
- Re: criticality conformance Peter Williams
- Re: criticality conformance Mark S Feldman