[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-pkix-acmc-01.txt
Peter,
WARNING: This is a very loooong e-mail in response to Peter.
Since you are coming to Yokohama, I believe that a face to face
meeting would help. Nevertheless, in the mean time, you will find
my comments below.
===========================================================
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.
[DP] Discussions are supposed to be taken on the list. Off-list
discussions are usually used to solve issues that would take too long on
the list. Maybe we should now go off 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.
[DP] Without explanations, this is still a free assertion. This is not as
simple since you only have *one* version for a PKC and *many* possible
versions for an AC that can include many or few attributes, associated
with different validity periods, target constraints and so on.
I think that there will be situations where PKCs and ACs are issued
together as part of an overall enrollment process.
[DP] This is one possibility. Do you mean that the document only covers
that possibility ? If this is the case, then it should be made clear. In
such a case do we really need a protocol to retrieve ACs ? I do not think
so, since LDPA would do it. We would only need a protocol to revoke
attributes in ACs (I did NOT said "we would only need a protocol to
revoke ACs".
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.
[DP] Which both situations ? The document only covers X.509 attribute
certificates from Attribute Authorities.
>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
>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.
[DP] The major problem is that the existing framework does not fit.
>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.
[DP]. Before raising the problem of revoking an AC, the first goal is to
get the AC ! Revocation is not a mandatory requirement, since some ACs
are never revoked because their validity period is small (e.g. one day).
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.
[DP] Revocation status information may be obtained using CRLs. In the
future, maybe using the equivalent of an OCSP server.
Both linkages are supported in ACRMF -- either the IssuerSerial pair
is used or a DN (GeneralNames, really) is given.
[DP] This information may be ambiguous and is not usable in large PKIs.
>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.
[DP] This is a core difference between the two approaches. The process
has to be broken between attribute registration and AC issuance. Suppose
that an entity has ten attributes registered by an Attribute Authority.
That entity will not necessarily wish to disclose and/or exercise all the
ten attributes that it has. There is a principle of "least privileges"
that is always applicable. Even with the same subset, some target
controls or different validity periods may need to be applied. The AA is
simply unaware of the users needs.
>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.
[DP] Since the policy or the profile has no name nor reference, this
feature is not supported. The text also says: Currently, getCert only
supports retrieval based upon the issuerName and serialNumber
combination. Quite hard to understand how all this will work together.
Once again the document is very difficult to read, since it is not a
standalone document. An introduction and preliminary information would be
most useful instead of diving directly in the ASN.1 details.
>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.
[DP] No. In ACMC and ACRMF, an AC is produced based on a template, not
based on a template reference. I wonder whether we have all the
flexibility, in particular, how can the AC validity period be selected ?
A good exercise would be to use RFC 3281 and to explain in an annex how
each of the fields of the AC can be selected to fit the requester's
needs.
#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.
[DP] It would be possible to return a template reference instead of an
AC. Then #2 would be supported and would allow thin clients to use this
protocol which is far too complicated for thin clients. #3 using a
reference would be used by "thin" clients, while #2 would be used by
managers or "fat" clients.
>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.
[DP] Template registration can be a local function but requesting an
attribute certificate based on an already registered template cannot be
done with the current proposal.
> - 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
>indicate 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.
[DP] I fear you failed to catch the point. In your case, the capability
to purchases up to the $10,000 level will be revoked, All certificates
that contain that capability must be revoked (if revocation is handled
for them). This is the revocation issue. Now in addition, this means that
if you then request that capability (e.g. using an AC template), no AC
with that capability in it will be granted. If you had a template
reference that included that capability, either then no AC would be
granted based on that template or you would get everything else except
that capability.
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.
[DP] This is not what I said.
And that an attribute may need to be revoked, causing the revocation
of all certificates incorporating that attribute.
[DP] Certainly, I first mean all certificates that contains that
attribute for a given user: a user may be given many attribute
certificates that include that attribute. In addition suppose that you
want to stop at once all the "project team 23" members to access a
server. You can simply revoke the attribute "Project team 23". All
certificates already issued and still valid, that contain that attribute
type and value will be revoked.
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).
[DP] See again the example above.
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.
[DP] Re-issuing a new attribute certificate minus the stricken attribute
finally allows me to understand which model you have in mind.
The model you seem to be advocating is indeed pretty different from the
one I have in mind. Maybe it is so self-evident to you that you have not
mentioned it.
Model 1: Attributes certificates are issued automatically by the AA and
placed in a repository. The grouping of attributes, the validity period
of the AC is fully left at the entire discretion of the AA.
Model 2: Attributes certificates are issued upon request from requestors.
They are not necessarily placed in a repository, but *may* be placed in
it, upon request from the requestor. The grouping of attributes, the
validity period of the AC, the publication is fully at the discretion of
the requestor, provided that it does not violate the policy under which
the AC is being requested to be issued.
Would you confirm if this is one of the main difference ?
>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).
[DP] In only providing AA name/serial number, you have not solved the
problem which is different from the PKC case.
>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.
[DP] The problem has to do with thin clients that will be unable to ask
for "complicated" AC contents.
>"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.
[DP] Since then David has issue a new draft: LDAP schema and syntaxes for
PMIs. It would now be certainly interesting to compare what can be done
with each of the two drafts, i.e. what is common and what is specific.
>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.
[DP] The restrictions apply to the whole set of attributes contained in
the AC.
>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,
(DP] But the main question is are there sufficient or insufficient. This
cannot be debated in a vacuum but only wen compared with requirements.
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.
[DP] This will certainly help, but will not close the debate.
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