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

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Jul 2002 11:53:30 +0200

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