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