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

["Yee, Peter" <pyee@xxxxxxxxxxxxxxx>]

Denis,

I've just gotten around to writing up my responses to your input
on ACRMF and ACMC.  Thank you for taking the time to read both
documents. Your input is valued.

 >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.

I'll grant you that they are very technical and perhaps hard to read.
I'll see what I can do to include more explanatory text in the next draft.
As for the number of comments that have come up regards ACMC, I fail to
see a direct correlation.  And in truth, I have received supportive
correspondence on ACMC from several parties who simply didn't post to
the list.

 >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.

I respectfully disagree.  While the combination of ACMC/ACRMF may not be
sufficient for all management aspects of ACs, I think that they and the
paradigm they espouse have their places.

I think that there will be situations where PKCs and ACs are issued together
as part of an overall enrollment process.  I think that there are other
situations where the PKCs and the ACs will be managed independently by
different authorities.  The architecture needs the flexibility to support
both situations.

 >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.

Sometimes you think the requirements are clear -- as you did with the
attribute
certificate policy work.  It's also true that when extending an existing 
framework, one assumes that the underlying requirements that built the
framework still hold true.

 >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.

In your discussion, I don't see a mechanism for revoking an attribute.  Are
you proposing another form of revocation list or status protocol that is
related to single attributes?  I would rather avoid such creating of a new
mechanism, as I see no indication that the current ones are inadequate.

Both linkages are supported in ACRMF -- either the IssuerSerial pair is
used or a DN (GeneralNames, really) is given.

 >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.

I do not think that the means by which the AA determines the appropriate
values for each of the attributes should not be part of this protocol.  In
my
view this would be analogous to bundling PKC enrollment with identity
vetting.  We recognize that identity vetting has many components,
potentially including face-to-face interaction with an RA.  The AA (or the
RA working with the AA) faces a similar situation.  Some attribute values
may be readily at hand (perhaps in a local account management database).
Some attribute values may involve coordination or information gathering
(perhaps a credit check).  Other attribute values may require time
(perhaps waiting for a check to clear).  The latency between the AC
request and the AC issuance will depend on these factors (and other
ones too).  Breaking the process into separate attribute registration steps
followed by a AC issuance step does not seem to be a general model.

 >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.

ACMC and ACRMF work fine for either managers, knowledgeable users (often
called ARAs), or certain 3rd parties that are requesting ACs.

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

We support this -- the ACMC Attribute Modification Handling Control
Attribute
allows attribute certificates to be issued against a specified policy or
profile.  Conceptually, this usage can be mapped to your templates.

 >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).

ACMC and ACRMF are designed to handle #3.  #1 and #2 are outside of the
scope of what I'm trying to do.  Others are welcome to "fill in the blanks" 
for those situations where they are needed.  I argue that there are
situations where ACMC/ACRMF is sufficient.

 >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),

Again, this isn't the realm of ACMC and ACRMF.  Another protocol is
welcome to step up to the plate on this.  In any case, I'm not sure how AC
templates are bound against a given entity.  If you're referring to
attribute
certificates already issued, then some sort of directory search may suffice
(depends on the latitude of use of these templates, joined directories,
etc.).
If you mean prior to AC issuance (which is what I suspect), well, that's 
definitely beyond the scope of what I'm looking to do.  As noted, these may
be handled as a local function.

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

Again, out of scope for ACMC/ACRMF.

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

Sure.  And that's another local or remote function.

 >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.

I have to disagree with you on this one.  Let's take an example.  I have an
AC that permits me to make purchases on behalf of the company up to the
$10,000 level.  Now, because of a change in responsibilities, my level is
being reduced to $5,000.  At that point, the AC I have allowing me to
make $10,000 purchases is going to revoked.  Period.  I have no idea why
the AC template would be revoked -- what does my loss of authority have
to do with anyone else using a similar type of AC?  And since I'm not
really concerned about attribute registration, the revocation
(deregistration?)
of attributes is outside of the scope of ACMC/ACRMF.

Re-reading your paragraph above, I think we're looking at attributes in a
fundamentally different way.  You seem to think that an attribute is
registered, and then can be issued in attribute certificates to multiple
users.  And that an attribute may need to be revoked, causing the
revocation of all certificates incorporating that attribute.  That's not at
all
what I was thinking.  There may be many attribute certificates with a
specific attribute type, but the need to revoke is tied to a specific
attribute
certificate and its attributes, not to the set of all attributes
certificates
containing a specific attribute (either type or type/value/conditions).

Finally, I'll note that even if you do use an attribute revocation scheme
instead of an attribute certificate revocation scheme, you still have to
revoke an affected AC and (potentially) issue a new one minus the
stricken attribute.  ACMC/ACRMF can be used to do this.

 >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.

The mechanism you offered can be used with in conjunction with other
mechanisms to work on pretty much any need for revocation.  I think that I
see
where you're going, but I believe that in only providing AA name/serial 
number, I haven't changed the problem; I've only changed where the list of 
certificates to be revoked is assembled.  You seem to propose that the AA
could do this. I've pushed list assembly to an entity that could be
logically
outside of the AA (the ARA or some other management entity).

 >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.

I'm not a believer in the AC template school.  If you wish to argue that
ACRMF
contains a template, I'll agree that it contains one, generic template that
can
be used to generate any attribute certificate (given a set of attributes, 
etc.). I view ACRMF as part of the AC acquisition function.  Period.  If you
insist on an AC template function, I think that it belongs in a separate 
protocol.  Again, many situations are handled by ACMC/ACRMF.

 >"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.

Fair enough.  I will endeavor to make it clear functions ACMC supports.

 >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.

I did not say that Get Cert was sufficient.  I said that the issuer name
and serial number combination was sufficient to retrieve an attribute
certificate.  I didn't say that it was the only way or what everyone might
desire.  The second paragraph suggests that there are other needs.  I'm
simply saying that if you do have the issuer name/AC serial number, the
existing Get Cert is available.  I don't want to replicate LDAP within
ACMC.

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

I suppose we just disagree on this point.

 >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.

I'm not sure I follow you -- are you saying we need extensions (using the AC
extension mechanism) that control attributes?  Or that the attributes need
to specify controls (generically? or attribute-specifically?)  If the former
case, I think you've got a mess brewing if you want to try to tie extensions
to specific attributes.  If the latter case, and attribute-specifically, I
would say that's a question of attribute definition.  If generically, then
you're talking about something that needs to be handled at the
X.509 AC syntax and semantics; these would then percolate into
ACMC/ACRMF.

 >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.

I see no need to write a requirements document at this point.  The PKIX
chairs
will let us all know if they think otherwise.

The mechanisms provided by ACMC/ACRMF are needed, but I will try to add
more explanation about the scope.  I will try to make it clear what is
covered
and what is not covered.  This should leave plenty of room for a companion
document addressing some of your concerns.  The need for that companion
document is breaking much more new ground.  Maybe a requirements
document is appropriate for that effort. Again, the PKIX chairs will let us
know....

 >Denis

						-Peter