Subject: Re: Comments on draft-ietf-pkix-ac509prof-05.txt

From: [email-masked]
Date: Wed, 18 Oct 2000 18:29:28 -0400

Since ObjectDigestInfo is already in the standard, those new syntaxes
I suggested earlier today are redundant, and I hope that I will be forgiven
for them.  IMO the correct thing to do in the profile is to recommend that
all uses of baseCertificateID SHOULD also use the objectDigestInfo field
with digestedObjectType publicKeyCert.  In those cases where entityName is
used with underlying PKC authentication but it is the AA's intent that only
one PKC be permitted, the objectDigestInfo field with digestedObjectType
publicKeyCert SHOULD also be used.
     Do we need a new extension to permit the listing of multiple PKC's (by
cert digest) for the same entityName when it is the AA's intent to allow
the use of such for a single AC and all the intended PKC's already exist?

          Tom Gindin

Russ Housley <[email-masked]> on 10/18/2000 02:23:10 PM

To:   Polar Humenn <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked], [email-masked]
Subject:  Re: Comments on draft-ietf-pkix-ac509prof-05.txt

An attribute or extension is the only acceptable approach to me, unless we
coordinate with X.509 agrees to make the same change to the base syntax.

Russ

At 02:09 PM 10/18/2000 -0400, Polar Humenn wrote:
>On Wed, 18 Oct 2000, Russ Housley wrote:
>
> > Polar:
> >
> > You are proposing syntax that is no longer compatible with X.509.  I am
> > very unhappy with such a deviation.
>
>Hmmm. I only went on that taking into account Tom and Denises suggestion.
>Do you feel that an attribute extension would be warranted instead?
>
>Cheers,
>-Polar
>
> >
> > Russ
> >
> >
> >    At 12:38 PM 10/18/2000 -0400, Polar Humenn wrote:
> > >On Wed, 18 Oct 2000, Denis Pinkas wrote:
> > >
> > > >> [SNIP]
> > > >    ESSCertID ::=  SEQUENCE {
> > > >         certHash                 Hash,
> > > >         issuerSerial             IssuerSerial OPTIONAL
> > > >    }
> > > >
> > > > and, in that case, having IssuerSerial present.
> > > >
> > > > Then we would need some additional text in the explanations to say
> that the
> > > > hash of the certificate should also be tested.
> > > >
> > > > In this way, at the time of verification, there is no ambiguity
> about the
> > > > link between the AC and the certificate, even if the CA has the
same
> > > name as
> > > > another CA certified from a different root key.
> > >
> > >Dennis,
> > >
> > >I still think that this solution doesn't quite solve the problem, but
is a
> > >good start.  In fact Tom Gindin's suggestion just came in and includes
> > >yours. So I'll sort of work off of that.
> > >
> > >The fact is that the entityName option still contains a DN and the RP
MUST
> > >be prepared to accept it. However, on what conditions should the RP
accept
> > >the Holder as a DN? (Especially if this verification is offloaded to
some
> > >remote verification engine).
> > >
> > >Perhaps there is a way to word the USE of a DN entityName?
> > >
> > >When using an AC that contains the Holder specification as a DN
entityName
> > >option, the DN MUST verifiable and uniquely name an entity within the
PKI
> > >of the AA, (i.e. resolved under the same RootCA as the AC). The AA
MUST
> > >ONLY create AttributeCertificates with the Holder as a DN entityName
in
> > >this fashion. This constraint is subject to the entire PKI for which
the
> > >AA belongs belongs to behave in its creation of unique DN. Therefore,
> > >verification is subject to the trust the RP places in the AA and its
PKI
> > >together to conform to this behavior.
> > >
> > >[Note: this approach still does not solve the problem that Denis
brings up
> > >below as comment 43. A subordinate CA may be compromised within the
PKI of
> > >the AA and create impostor certificates, grabbing privileges.]
> > >
> > >Therefore, it would still probably be better to use the Issuer/Serial
and
> > >a hash of the Issuer's certificate, even if in the same PKI.
> > >
> > >Of course, when an application authenticates to an RP using PKCs this
ties
> > >the authorization to a particular certificate. Apparently that was not
> > >desirable due to the effect of key rollover and new certificates being
> > >issued to the same subject entity.
> > >
> > >However, I think that if as Carlise pointed out, that if the DN is
only
> > >used in the case of a single trusted Root, then everything will be
fine.
> > >
> > >So, as Russ asked me to propose text, here it goes:
> > >
> > >Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
> > >that is already defined in the document for the certificate Hash).
> > >
> > >Section 4.1:
> > >
> > >    Holder ::= SEQUENCE {
> > >         baseCertificateID   [0] IssuerSerial OPTIONAL,
> > >                 -- the issuer and serial number of
> > >                 -- the holder's Public Key Certificate
> > >         entityName          [1] GeneralNames OPTIONAL,
> > >                 -- the name of the claimant or role
> > >         objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
> > >                 -- if present, version must be v2
> > >         verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
> > >    }
> > >
> > >    IssuerSerialCertID ::=  SEQUENCE {
> > >         isserCertDigest          ObjectDigestInfo,
> > >         issuerSerial             IssuerSerial
> > >    }
> > >
> > >In section 4.2.2 Holder add:
> > >
> > >When using an entityName that contains a DN, the DN MUST verifiably
and
> > >uniquely name an entity within the PKI of the AC issuer. The PKC named
by
> > >the DN MUST verify back to the root CA of the AC issuer. The AC issuer
> > >MUST ONLY create AttributeCertificates with the Holder as a DN
entityName
> > >in this fashion. This constraint is subject to the entire PKI for
which
> > >the AC issuer belongs to behave in its creation of unique DNs.
Therefore,
> > >verification is also subject to the trust the RP places in the AC
issuer's
> > >PKI to conform to this behavior.
> > >
> > >In Section 5 the AC Validation Criteria is as follows: (keeping 1 as
1,
> > >inserting 2, 3, and 4 below, and renumbering accordingly).
> > >
> > >To be valid an AC MUST satisfy all of the following:
> > >
> > >1. The AC signature MUST be cryptographically correct, and the AC
> > >    issuer's entire PKC certification path MUST be verified in
> > >    accordance with [PKIXPROF].
> > >
> > >2. When the AC holder is named by a DN using the entityName option,
> > >    the holder's PK certificate MUST be uniquely found under the same
root
> > >    CA as the AC issuer. The entire certification path of that PKC
MUST be
> > >    verified in accordance with [PKIXPROF].
> > >
> > >3. When the AC holder is named by a baseCertificateId, the issuer's PK
> > >    certificate MUST be uniquely found under the same root CA as
> > >    the AC issuer. The entire certificate path of that PKC MUST
> > >    be verified in accordance with [PKIXPROF].
> > >
> > >4. When the AC holder is named by a verifiedBaseCertificateID, the
> > >    named holder issuer's PKC must be found, and that PKC MUST
correctly
> > >    digest to the digest value contained in the
verifiedBaseCertificateID.
> > >    The entire certificate path starting with the holder's PKC and the
PKC
> > >    of the issuer the holder's PKC MUST be verified in accordance
> > >    with [PKIXPROF].
> > >
> > >.....
> > >
> > >Note: there is *still* a problem with AC targeting and proxying using
> > >just DNs.
> > >
> > >Cheers,
> > >-Polar
> > >
> > >
> > >-------------------------------------------------------------------
> > >Polar Humenn                  Adiron, LLC
> > >mailto:[email-masked]      2-212 CST
> > >Phone: 315-443-3171           Syracuse, NY 13244-4100
> > >Fax:   315-443-4745           http://www.adiron.com
> >
>
>-------------------------------------------------------------------
>Polar Humenn                  Adiron, LLC
>mailto:[email-masked]      2-212 CST
>Phone: 315-443-3171           Syracuse, NY 13244-4100
>Fax:   315-443-4745           http://www.adiron.com

---

From: Polar Humenn <[email-masked]>
Date: Wed, 18 Oct 2000 21:50:23 -0400 (EDT)

Tom,

I like your suggestion of tying the AC to a particular certificate, or a
effectively its public key.

The requirements I stated in my proposed text for using only DNs to 
identify the Holder or its issuer are flawed.

They required the AA to decide the root CA certificate was used to
identify the Holder along with itself , i.e. a single PKI as Carlisle
suggested.  Unfortunately, I think that is not such a good idea since
cross-certifications can be all over the place. Therefore, that
requirement for using only DNs to identify Holders isn't even good enough.

The AA may not have any idea of who the RPs are or will be. (I think this
was mentioned before). Specifically, I can imagine, that whoever the AA
thinks is its root CA may not be what the RP thinks the AA's root CA is
because of cross-certification. Correct? If this is the case, how could
the RP really tell what the AA thought the root of its PKI is?

In other words, the RP would have to find the root CA certificate that was
used by the AA to make its decision that the Holder's DN was actually
within the AA's PKI. Unfortunately that is on the other side of the
stockade fence. The RP may have the "can't get there from here" problem
with respect to finding the exact root CA cert that the AA used to make
its decision about the Holder being in its own PKI.

The AC has to point to the Holder PKC, as Tom's suggestion point out, so
the RP emphatically knows who has been authorized by the AC.

It seems that one of the key factors here that is causing the problems is
that is NOT desirable to restrict the AC to an entity certificate (or
really its public key). This seems to be the crux of the problem. If the
AC were restricted to the public key, then the problem goes away.

I am tending to agree with Bob Juenema that affixing privileges to names
in this arena is pretty dangerous. Especially for critical applications.
At least there is that option of basing the AC on the public key of the
holder. Although unfortunately, the profile says that it doesn't have to
be supported.

So, is verifiably TRUSTED, unique, worldwide DN naming with enforceable,
recursively consistent naming constraints, a reality? If not then the AC
cannot name the Holder via DN unless it knows who the RPs will be and
knows that the RPs know who the Holders will eventually. That would be a
highly controlled, closed, and protected environment.

I understand how it's suppose to work. Mathematically, there should be a
least upper bound for all AA, RP, and Holders based on public key
signatures through the proper cross-certifications amongst all parties.
Names are completely factored out of that reasoning, only public keys
matter.

In practice, I don't see ACs with just DNs working all the time because of
naming conflicts, and I don't see a way to make that work unless all
parties are guarranteed to work in environmental constraints, perhaps
by legal means instead of technical ones. 

I'll regretfully back off, as I cannot really see how to make it work
verifiably in general.

The solution in an wide open environment must be to always bind the AC to
the public key. Alternatively, the only reason I can see to bind the AC to
the holders PKC is to ensure proper advisory information is used, such as
in auditing with the subject Alt names, and other possibly other policy
constraints. Is that correct?

Cheers,
-Polar

---

From: Dale Gustafson <[email-masked]>
Date: Thu, 19 Oct 2000 08:50:10 -0500

Polar,

To attempt to get at your concern about what happens when the holder needs to
update their signature key and certificate -- perhaps we could consider adding an
optional URI pointer to the AC that tells the RP where to find the AA's "key
update" service.

If requested by an RP, the service would be able to, given a particular AC,
provide a newer PKC (or list of PKCs) that can be used to verify the holder's
digital signature.  Conceivably, this is one method that would allow an AC to
reliably reference PKCs that do not exist at the time the AC is issued.

Questions:
----------

Is this additional capability important enough that a (perhaps not-free) service
would be a viable solution ?

Is it almost always better / cheaper / faster to simply reissue the AC(s)
whenever the holder's PKC is updated / replaced?

Are there technical reasons why this approach wouldn't work?

Best Regards,

Dale Gustafson

---

From: Polar Humenn <[email-masked]>
Date: Thu, 19 Oct 2000 11:08:09 -0400 (EDT)

Hi Doug et al,

BTW, I took OMG Electronic Commerce Group <[email-masked]> off the list,
because Doug Moss complained.

> optional URI pointer to the AC that tells the RP where to find the AA's "key

I don't think it's my concern any longer. I cannot see how an AC can
reference an entity by a DN, because that DN has no hope of being unique
unless there is a ubiquitous TRUSTED directory. That is impossible.

An AC can only reference a public key. If the public key is updated, the
AC must be updated as well.

Quite frankly, I'd like to understand why attribute certificates are
needed at all? Why not just put the attributes in the subject's PKC?

The correlation problem is more complex than certificate verification
itself. The certificate chain verification problem is so complex servers
were invented to do it for us, creating yet another kink in the trust
model. Is there now a need to create server that verifies the PK
certificate chain and AC and its certificate chain together?

I've talked with a couple of vendors so far, and they just create
extensions in their X.509 certificates for various things concerning
access control and auditing. This seems to be much cheaper. Also, that way
they don't have to change anything, like SSL stacks, and other things that
just look at PK certificate particulars. Relying party software that
doesn't pay attention to the new attributes also doesn't have to be
re-engineered. An if it does, it only has to look in the PKC, and not
other information delivered by other protocols, i.e. the AC.

Is the only real reason for the attribute certificate to issue attributes
to identifiers that do not have public/private keys, such as a Kerberos
name, or an email name?

Cheers,
-Polar

---

From: "Stephen McConnell" <[email-masked]>
Date: Thu, 19 Oct 2000 18:10:13 +0200

Polar et. al.

Some comments from an OMG/EC perspective:

	- EC has a significant subscribed list of end-user
	  organisations that will end up using this stuff,
	  possibly not in the pure IETF model of data
	  structures, but in terms of the real application
        level problems based on the emerging CSIv2
	  OMG's cross-domain security interoperability spec).

  	- Members of EC are watching closely the CSIv2 process,
	  because we know the CORBA security doesn't work beyond a
	  single enterprise, and the CSIv2 is the silver bullet.
	  Because CSIv2 depends on Attribute Certificates, this
	  means  that the strength of CSIv2 is limited by the
	  strength of X509 (2000).  If there are holes in X509
	  (2000) it means that there are holes in CSIv2.  CSIv2 has
	  been adopted. It will be presumably enter a finalisation
	  phase during the next meeting.  Based on several emails
	  sent out on this thread, my conclusion is that
	  X509 (2000) isn't ready for prime time - adding a
	  "by-the-way there are security holes and there are
	  optional vendor fixes (if they want to) but, ooh,
	  by the way, you, the customer, you should be selecting
	  your provider on the basis your technical due-diligence"
	  (etc.) ... simply sucks. But lets look at what this means
	  in terms of the impact on CSIv2:

	  1. CSIv2 is dependent on the strength of X509 (2000), in
	     particular, the dependence that CSIv2 places on
	     Attribute Certificates

	  2. Holes have been identified by Polar in the Attribute
	     Certificate model and confirmed by several other
	     authorities on this list.

	  3. What I'm missing here is this thread is the distinction
	     between the following:

		   OMG CSIv2 functionality

	            - why CSIv2 needs Attribute Certificates
			  in the first place ?

			- is there any reason why CSIv2 cannot use
			  X509 Classic instead ?

		   OMG PKI Service functionality

			- currently defines mechanisms for
			  certificate issue and verification,

			- is missing an extendable valuetype
			  definition of a certificate to sync X509
			  and CSIv2 with the PKI service

		   Application level functionality

			- getting a clear distinction between
			  application level (which is where I would
		  	  have through Attribute Certificates are
			  relevant) as opposed to CSIv2 service
			  functionality.

Cheers, Steve.

P.S.  Please consider this email as a vote for fully expanded acronyms.  For
myself, AA stands for "Alcoholics Anonymous" and AC stands for "Andersen
Consulting"!

---

From: "Don Flinn" <[email-masked]>
Date: Mon, 23 Oct 2000 10:49:23 -0400

I assert that CSIv2 does not have the problem that Polar uncovered. Let's
see if I can defend that assertion -:)

CSIv2 defines a wire protocol to facilitate secure interoperability.
Therefore, if CSIv2 provides a way to support the resolution of the problem
that Polar uncovered then CSIv2 is sound.

CSIv2 provides for the transfer of a chain of Authentication Certificates
for the initiating client and a second chain of a Privilege Attribute
Certificates (PAC) followed by the Authentication Certificate chain
verifying the AA who issued the PAC.

The Holder field in the PAC points to one and only one Authentication
Certificate identified by a CA and serial number which is unique to that CA.

Given the above, there are a series of trust relationships that must be
supported by a security service implementation of CSIv2 and an application
using that security service - namely:

The Application must trust the AA.  This can be accomplished by the
application, supported by the security service implementation, using an
authentication certificate in the PAC chain.  For example, the application
stores authentication certificats of trusted AA's.  The security service
implementation verifies the chain against one of the stored, trusted AA
authentication certificates.

The application must trust the user's SSL certificate when using the default
CSIv2 mechanism, SSL. (A similar statement holds true for other mechanisms.)
This is accomplished the same way as above but for the user's certificate,
i.e. establish trust in the user's CA or some CA in the chain.

The AA must trust the CA that issued the user's certificate.  In this case I
am using the Holder field in the PAC.  The AA points to a user certificate
issued by a CA that it trusts.

The CA has done due diligence in issuing the user certificate.  This is what
I meant by the AA trusting the user's CA, i.e. the AA assures that the CA
referenced in the Holder field of the PAC it issues has done its due
diligence with respect to the user.

Given the above trust relationships lets look at the two "Henry Ford's".
Henry Ford is defined by CA-1 as, e.g.
o=Ford Motors,c=US,ou=Truck Division,ou=accounting_derborn,CN=Henry Ford.
If the CA has done its due diligence then there can be only one Henry Ford
with that full X.501 name.  If the full X.501 name does not point to a
unique Henry Ford then that CA has not done its due diligence and can be
sued to recover any damages done by its lack of due diligence.  If CA-2
issues a certificate with the same full X.501 name then it is the same Henry
Ford as that identified by CA-1, if CA-2 has done its due diligence. (I
bring up law suites as an example of the recourses of an aggrieved party.
An analogy is a bank which you trust and to which you have recourse if they
fail in their due diligence and cost you money.  This is not the purview of
the technology but of the law.)

If the AA issues a PAC that points to a incompetent or bogus CA then it has
not done its due diligence and can be sued to recover any damage done by its
negligence.

The trust relationships that I defined above are not the purview of CSIv2
*nor* the draft-ietf-pkix-ac509prof-05 specifications.  The specification of
the trust relationships are the purview of a higher level protocol or
specification.  CSIv2 and the draft-ietf-pkix-ac509prof-05 specifications
provide the protocols to support the ability to establish the trust
relationships.  Note that I am not ignoring all the excellent discussion on
the original thread related to tightening the language of the
draft-ietf-pkix-ac509prof-05 specification.  What I am cautioning against is
"throwing out the baby with the bathwater"  and mixing the intent and
purview of these two specificcations with those of a higher level
specification.

OMG is in the early stages of writing a Request for Proposal (RFP) which
will/should address the higher level AA issues.  This RFP, I assert, should
specify authentication servers and services and define their
responsibilities as well as the interfaces to interact with them in a
Federated situation.  The specification is tentatively called the
Authorization Token Layer Acquisition Service, ATLAS, and has a mailing
list - [email-masked] .  All who are interested in this issue are
cordially invited to join.

Don

> -----Original Message-----
> From: Stephen McConnell [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 12:10 PM
> To: Polar Humenn; Dale Gustafson
> Cc: [email-masked]; [email-masked]; [email-masked]; Electronic
> Commerce DTF
> Subject: Impact on OMG's CSIv2 (was - RE: Comments on
> draft-ietf-pkix-ac509prof-05.txt)
>
>
>
> Polar et. al.
>

---

From: Polar Humenn <[email-masked]>
Date: Mon, 23 Oct 2000 11:41:14 -0400 (EDT)

Don,

In general PKI, has the problem that I "uncovered" with the Attribute
Certificate. So therefore CSIv2 does have this problem as well, especially
if it must rely on products and services in this space.

Trust relationships that you cite may be mandated by contract law,
provided you have contracts! However, if one is throwing around cliches,
then how about this one "Locking the barn door after the horse got out",
or "Houston, we have a problem". In open interoperable environments, you
may not have contracts, you may not have practical recourse of the law
anyway, say in international deployments.

All you can really get from PKI is the fact that the same entity that is
identified in the Attribute Certificate (the Holder) is the same entity
the Relying Party is correlating it with. That Holder is the "holder" of
the private key, not merely something named by an arbitrary DN. The
Attribute Certificate Issuer must be able to provide evidence that he is
indeed identifying the holder of a private key. A DN alone doesn't do it.
A DN of the entities issuer doesn't do it either for the same reasons.

BTW, a DN is just a bag of bits as far as I'm concerned. Its conventional
use cannot be enforced or relied upon. Its structure only serves as a
"tool" or an optimization of finding "things" that may be related to it.
You cannot infer an the subject's issuer from the subject's DN. If the
attribute certificate is not tied to a public key and you trust that. You
must have a highly constrained environment. That's not "interoperable".

Below you state only *one* situation in which all parties MUST "trust"
each other by basically subscribe to one TRUSTED DN server (which does DUE
DILIGENCE on updates), where all names are unique and all party's business
practices concerning DNs are well known to all parties, and contracts are
written on it between all parties together. Otherwise, you'll just get
into a finger pointing situation. If we want to make that a requirement
for CSIv2, then so be it. 

Cheers,
-Polar

---

From: Stephen Kent <[email-masked]>
Date: Mon, 23 Oct 2000 13:01:12 -0400

Polar,

As you and I discussed off list, while one cannot guarantee DN 
uniqueness across all CAs, one can use the nameConstraints extension 
in a cross-certificate to ensure that certificates issued by a given 
CA, and evaluated in the domain of the issuer of the cross 
certificate, are within a specified name space. This approach 
addresses the naming concern cited in your message.

Steve