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

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 23 Oct 2000 17:56:47 -0600

Dale,  

You are of course entitled to your opinion,  and who knows -- you might even be correct in your assertions!  Accurate crystal balls are hard to come by..  But I would submit that the discussions on this list indicate that there is far from unanimous consensus as whether or not there is a genuine need for attribute certificates.  Certainly my position at present is that I see NO such compelling need, and I am highly skeptical of the wisdom of adding more and more complexity on top of a PKI that field experience is showing to be of daunting complexity  when it comes to implementing it and making it all work.

Saying that does NOT mean that I don't see the need for a Privilege Management Infrastructure (PMI) , however -- far from it.  In fact, it is increasingly obvious (at least to me), that PMI is going to be where the real action is, and that the vision of say five to ten years ago of stranger-to-stranger electronic commerce being facilitated by Identity certificates seems less and less likely to materialize.  (The problem, of course, is that even if I know beyond a shadow of a doubt what someone's name is, and even if that name is globally unique, that doesn't mean that he has any money in the bank, or that he is particularly trustworthy, or that I know where to send the sheriff after he drives off with my Maserati demonstrator car and never returns, leaving his electronic driver's license with me as some kind of collateral.)

But please allow me to break apart your hypothesis line by line -- maybe we can identity some individual elements that we can agree on, and move forward from there.

>Al, Polar,
>
>Let me also try to summarize.
>
>I think we've arrived at the current state because the group genuinely perceives
>the need for Attribute Certificates.  

As I said, that level of consensus is far from obvious, and there is NO marketing data I am aware of that would support such a contention.

>I think there is a common sense that there
>is or will soon be a compelling need for secure applications to distribute and
>utilize tamper-resistant, application specific data elements within the global
>PKI.  

On the other hand, I DO agree with that statement -- individual applications really need to be able to specify or determine which  end-entities are entitled to perform certain functions.  One way to do this is to use a directory that is trusted by the Relying Party, and to look up the relevant attributes within that directory.  Unfortunately, although it might be technically possible to harmonize the schemas and eventually federate multiple directories defining such levels of privilege, at present it seems to be an impossible management problem to solve.  So we DO need to distribute "attributes" (rights) within a PKI/PMI infrastructure -- no argument about that.  The question is whether that implies the need for Attribute Certificates per se.

>It is envisioned that authoritative entities will deploy Attribute
>Authority systems that manage the life cycle of these special certificates.  

I could agree with that.

>We
>further speculate that each authoritative entity will work with it's various
>constituents to define the form, fit, and function of a specific attribute
>certificate that will be utilized by a well-defined set of applications.  This
>application specific certificate's format and content will be updated from time
>to time as the applications evolve, etc. under some management process
>controlled by the authoritative entity.

If by that you were to mean a standard X.509 v3 cert that contained specific rights attributes, I would agree.
>
>Past experience has strongly suggested what NOT to do but has not necessarily
>indicated the most appropriate course of action.
>
>Logically, and assuming the need is real, there are at least three possible
>approaches:
>
>1. Embed the Attribute Certificate information in x.509 v3 Identification
>Certificates

This is of course my strong preference.
>
>Each industry or market group (banking, finance, insurance, communications,
>government, et. al.) can create a set non-critical extensions that allow their
>application-specific information to be carried in a common public key
>certificate or certificates.

Agreed.  Actually, what is likely to happen is that individual enterprises will define a set of rights that will fit their needs, and then they will try to communicate those rights to someone else, who will have used a slightly different set of semantics and/or syntactic definitions, and those will then have to be harmonized with policy-based controls applied at each Relying Party.  Then some of the industry leaders will get together and define a common schema for such rights, so that everyone can interpret all of the other certificates, assuming the trust the issuing CA.
>
>In the near term (at least) this is the most effective approach because each
>design can take a free ride on all of the PKI infrastructure that is being put
>in place at great expense.  

Exactly.

>The downside is that the combined certificate
>retains all of the properties of a public key certificate irrespective of
>whether that makes sense for the attribute information and the secure
>application(s) that will utilize it.

Well, maybe and maybe not.  The assumption you are making is that only one certificate is created, that contains everything.  That might be desirable, especially for relatively static attributes, but it isn't absolutely necessary.  For that matter, the certificate that specifies a user's rights might not contain the user's DN at all -- it certainly wouldn't have to.  But on the other hand, the general requirement for auditing is probably going to require that the user be identified somehow, which at a minimum means a user ID.  And requiring the user to enter a user ID requires a password to confirm it. And although server-enforced passwords have some value as a means of providing multifactor authentication and to prevent a complete collapse if the user's private key is compromised, it seems rather a nuisance to enter all of this when the same information could easily be included int eh certificate itself.
>
>2. Embed the x.509 v3 Identification Certificate in the Attribute Certificate
>
>This has been suggested in the past but was not well received, likely because it
>was obvious that significant additional overhead would be added to each
>attribute certificate but it could not be shown that such a close coupling of
>the attribute certificate and public key certificate would have technical merit
>that justifies the cost.  Problems of keeping the ID certificate and attribute
>together are eliminated but there are still two certificate chains.  The
>infrastructure for and deployment of ID certificates can be utilized "as is".

This is just the flip side of putting the rights information int he X.509 cert, but this adds the expense of validating two certificate chains.
>
>3. Provide a Link from the Attribute Certificate to the Public Key Certificate
>
>This approach appeared at the outset to be the most elegant and, most
>importantly, appeared to be the most flexible.  It has just now become more
>apparent that creating a reliable, "dynamic" link between the two certificates
>is difficult.  This has been discussed at length recently.

If people can really, really establish the need for an independent attribute certificate, which I am prepared to accept in theory if not in practice, then at a minimum this coupling seems to require a cryptographic linkage between the attribute cert and the PKI cert.  And that very linkage means that the attribute cert effectively expires or is revoked along with the PKI certs, since the linkage would  no longer be valid.
>
>Perhaps others can recall other approaches that have been suggested.

The fourth approach, which really hasn't been discussed, is simply to put the "rights" attribute in a directory which is trusted by the Relying Party.  That certainly works, but it lacks a bit of cryptographic elegance, of course.  Now, someone will probably say that the directory isn't sufficiently trusted, to which I would say that the attributes in the directory could be signed. Now we are almost back to an attribute cert, except that it is the Relying Party's organization that is doing the signing, so presumably the checking is simpler.  
>
>My sense is that the real value of a separate attribute certificate is that it
>invites others with specific application expertise to join the process "earlier"
>without making everyone's work overly complex -- if (and only if) that's true,
>will people be willing to pay some reasonable price to accomplish the necessary
>up-front planning.
>
>What appears to be missing is a framework that enables secure application
>builders to understand when they can "have at it" knowing they have a reasonably
>stable environment around them.  That is, allows and encourages their innovative
>work to move forward in  parallel with that of other industry and market
>groups.  In order for that to happen, there needs to be a common understanding
>that the basic problem is bounded and within range.
>
>A framework for attribute certificates might better define many of the things we
>have recently discussed:
>
> - encode / decode methods supported (ASN.1, XML, other)
> - commonly used data elements
> - encryption methods (selected attributes, full certificate)
> - delivery methods (SSL, S/MIME, directories, other)
> - certificate path creation / signature validation
> - certificate status checking
> - summary:  distinction between ID certificates and attribute certificates
> - other ?
>
>Perhaps this has already been done elsewhere.  I suspect even an all-knowing
>expert would have to look long and hard at the overall requirements for
>attribute certificates before deciding that a single approach would suffice.
>
>Comments?
>
>Best Regards,
>
>Dale Gustafson

You might guess that I would not have been quite so sure of myself in this area if we hadn't already done something in this area, and you would be right.  I believe, but don't know the details, that some other vendors have done similar things.

But Novell has already issued several million certificates that provide the necessary infrastructure to support these kinds of systems, and we are willing to license the technology to anyone who will agree to honor the semantics of the attributes, in particular what we refer to as the certificate quality portion of the Novell Security Attributes.

For more information, cf. http://developer.novell.com/repository/attributes/certattrs_v10.htm.  For those of you who may have looked at that document previously, it hasn't changed, but I am about to update it, and so I would be delighted to receive comments and suggestions for improvements.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

---

From: Dale Gustafson <[email-masked]>
Date: Wed, 25 Oct 2000 08:48:23 -0500

Hi Bob,

A couple of comments:

1) I meant the group clearly appears to agree there is a "need" for the functionality of what has been called an Attribute Certificate (e.g., a tamper-resistant data object containing application or user group specific data), not the separate AC form described in the draft.  Obviously there is substantial agreement on that particular form as well since we do have a well-crafted draft document on the table.

2) Didn't intend to imply the typical user would have only one or two key pairs / certificates.

3) A complex AC (that includes an embedded PKC) hasn't been discussed much.  It's not the same as an ID certificate that includes special attributes.  The distinction between AC and PKC is well articulated in the draft and I think would apply here as well.  A combo object has distinct implications beyond that.  I suggest we don't have the bandpass to discuss this right now.

4) At this time, I think it's much more important to make an effort to find / enhance the value of the approach outlined in the draft and resist the temptation to dismiss it.  It's too easy to find fault with a good, new idea before it's had a chance to become fully developed.

5) At first I was a little troubled by the implication that the only way to to move ahead in a timely fashion with this stuff is for individual vendors to create essentially proprietary solutions, albeit using all standards-defined components.  But it's more important to get the necessary interoperability standards in place -- so the real issue is whether others rally around your proposal and "how long it takes" for that to happen.  Good Luck.

Best Regards,

--dg

---

From: Steve Hanna <[email-masked]>
Date: Thu, 26 Oct 2000 11:28:31 -0400

It seems to me that this discussion boils down to a rehash of some old,
oft-debated issues: whether to use names in certificates and how
authorization information and other attributes can be accessed securely.
Here's my summary:

If your PMI is based on names (using ACs whose Holder is only a
baseCertificateID and/or entityName, for instance), you must be very
careful about how you map names to public keys. In particular, you must
ensure that you can't be tricked into mapping the name of an authorized
user to the public key of an unauthorized user.

But that's exactly the job of a PKI! If you can't run a PKI securely,
why bother implementing a PMI? It *is* possible to run a secure PKI.
Have a small number of trust anchors (one is best). Make sure that they
(and any cross-certified CAs) are managed carefully to ensure that
duplicate names are not possible. If you want to include less trusted
CAs and certificates in your PKI, use name constraints and certificate
policies to ensure that they cannot be used to gain access to more
secure applications.

If you can't run a PKI securely or don't believe in names, you can base
your PMI on public keys instead (by using ObjectDigestInfo). But I see
no reason why we should recommend this in general. So I don't support
discouraging the use of baseCertificateID or entityName (although a
warning about their dependence on PKI integrity would be wise).

Likewise, if you don't want to use ACs for your PMI, you are perfectly
welcome to include attributes in a PKC or store privilege information in
a directory (or in a database or whereever you like). But many customers
want to separate management of authorization and authentication. Let's
enable this by moving the AttrCert profile forward.

Steve Hanna