Subject: Re: I-D ACTION:draft-ietf-pkix-acmc-01.txt

From: Denis Pinkas <[email-masked]>
Date: Tue, 21 May 2002 15:17:05 +0200

Comments on drafts "Attribute Certificate Request Message Format" and
"Attribute Certificate Management Messages over CMS" (March 2002)

The two drafts are very technical, hard to read, inter-related and do
not have sufficient explanations to allow a rapid and easy understanding for
everyone. It can be observed that no comment has been sent up to now on
acmc.

It is assumed that managing ACs is as simple as managing PKCs and thus that
protocols able to manage PKCs, with a few modifications, will be able to
manage ACs. This assumption is incorrect.

The way ACs are managed is very different from the way PKCs are managed and
for that reason it is not believed that extending CRMF and CMC is the right
way. Whether some extension to CMP would be able to do the job better will
not be discussed either. The problem is that is that we have a solution
without requirements, so it is hard to say whether or not the solution fits
the requirements. 

It would be appropriate to write of the requirements first, so that we can
all understand how a proposal would fit these requirements.

Before looking into some of these requirements, it is important to
understand the major differences with a PKC.

When a PKC is requested, a template of the PKC is provided together with
registration information. From that request, a *single *certificate will be
created later on, and will be given back to the requester and/or placed in a
repository.

When an attribute (beware, *not* an AC) is registered, that attribute is
provided together with registration information. No AC is created from that
request. The registration information consists of two main components:

   - the definition of the attribute itself, together with some 
     constraints that apply to it (see later) and the revocation 
     conditions for that attribute.

   - the way to link the "to-be-created-ACs" with an entity, most of 
     the time by linking it to a PKC. In that case providing the PKC is 
     not always sufficient since the subject DN may not be explicit 
     enough and thus information (or some link) from the CA that has 
     created the PKC may be necessary.

Attribute registration is usually not done by the end user that will
become ultimately the AC holder. Various attributes can be registered. Some
attributes may be registered with some constraints like, the validity period
of ACs that may be issued later on; how revocation will be handled, if
handled for that attribute; restrictions that will apply to that attribute
like target controls. Note that this operation is not necessary done
remotely using a protocol, so it is not mandatory to support a protocol for
it.

Most users will be unable to specify the details of an AC and this will
either be done locally at the level of the AA or remotely by using protocols
dedicated to managers only. The job of these managers is to make life easy
for certificate holders. They will define AC templates so that ACs can later
on be created upon request from the AC holders by using these templates.
Some grouping of attributes will need to be done to fulfill a job or to
perform a set of operations. The AC holder will thus only need to know the
references of these various templates that will be tailored to match their
jobs. In some cases, end-users will make the definition themselves and then
will use the reference of these definitions to get an AC.

This means that AC will be obtained by providing a reference whose details
are already known to the AA.

As a summary, the following three basic functions are identified:

   1) Attribute registration (no AC is produced). This can be invoked 
      several times. This function is optional since it can be done 
      locally.

   2) AC template definition (a reference for a template is produced, 
      but no AC is produced). This function can be done locally or 
      remotely.

   3) AC acquisition (an AC is produced based on a template reference).

Additional functions are needed since the second function may be performed
by managers while the third one will be performed by AC holders:

  - list the AC templates for a given entity (for an AC holder or 
    a manager),

  - list the AC templates for a set of entities (for a manager only).

Note: This assumes that the AA already "know" the attribute type. 
If not, a registration function to register new attributes would be needed. 

Once an AC has been obtained, it may be necessary to revoke it (if this is
allowed). However, the revocation requests is not for an AC, but either for
an attribute or an AC template. This means that all ACs containing this
attribute or produced using that template have to be revoked. This may be
for one entity or for all entities using that attribute or that AC template.
Since the requester (which may not be the AC holder) does not necessarily
know all the AC s that have been issued, it cannot indicated the serial
numbers of these ACs and thus let the AA find out how many and which ACs
need to be revoked. This is fairly different from the ways PKCs are
requested to be revoked.

This description provides an hint on how an attribute revocation request
should be handled. This is fairly different from the current proposal which
is only able to revoke an AC by providing an AA name and a serial number.
While useful in some cases, this is certainly insufficient.

Since an AC is created for an AC holder and upon request from an AC holder,
it is given back to the requester. In most protocols ACs are "pushed"
towards an application or are provided attached to some signed data.
Otherwise, the reference of the certificate is "pushed" by the AC holder and
the AA may then provide the AC upon request. When that function is useful,
it would be interesting to use an LDAP schema so that LDAP can be used for
ACs, rather than a new dedicated protocol.

Hereafter are a few comments on the two proposals.

ACRMF is an "Attribute Certificate Request Message Format". It combines two
functions mentioned earlier: the AC template definition function and the AC
acquisition function. However, as indicated above, these functions should be
separated. 

"Attribute Certificate Management Messages over CMS" - ACMC - fails to
clearly present the functions that are supported. It is necessary to
maintain open at the same time three other documents to be able to
understand that document: [CMCbis], [ACRMF] and [CRMF]. Before going into
the details, it would be most useful to express the functions that are
supported. 

In section 3.6, GetCert is mentioned to be sufficient for attribute
certificates while it only supports AC retrieval based upon the issuer name
and the AC serial number. This function is insufficient and should be
supported using LDAP.

In section 3.8. the revoke request control attribute allows to revoke an
attribute certificate, while it has been mentioned that this is
insufficient.

In section 4.1. attributes can be added but this is again insufficient:
attributes with restrictions may need to be added. As an example, extensions
like target Controls may be appropriate.

CONCLUSION

We first need to agree on a set of requirements before discussing the
details of any proposal. It might be appropriate to write an
Informational RFC to specify these requirements.

Denis

> 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           : Attribute Certificate Management Messages over CMS
>         Author(s)       : P. Yee
>         Filename        : draft-ietf-pkix-acmc-01.txt
>         Pages           : 10
>         Date            : 06-Mar-02
> 
> This document specifies modifications to the Certificate Management
> Messages over CMS specification ([CMCbis]) to permit the management
> of attribute certificates.  This document does not stand alone, but
> must be used in conjunction with [CMCbis].  It is expected that the
> modifications proposed here will also be used in conjunction with the
> Attribute Certificate Request Message Format specification ([ACRMF]).
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-acmc-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also 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-acmc-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 22 May 2002 15:05:30 -0400

Denis:

Steve Farrell posted a draft called "Limited AttributeCertificate 
Acquisition Protocol (LAAP)" in July 2000.  Several people thought that 
this approach was too light weight.  I believe the ACMC/ACRMF approach 
handles all of the cases that LAAP handled and many, many more.

As for complexity, the PKIX group split CRMF from the enrollment protocol. 
By extending the enrollment protocol and the request format are both being 
extended, no new complexity is being introduced.

I think that we should proceed with the ACMC/ACRMF approach, even if it 
does not meet every requirement.  In my opinion, Synergy with CMC is desirable.

If it turns out that an attribute-centric protocol (as you advocate) is 
needed for communications between the client and the ARA, then it still 
seem likely that ACMC/ACRMF is a good fit between the ARA and the AA.

Russ