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
>