13 delegates from 7 countries attended the meeting, although not all the delegates were there for the entire meeting.

The topics to be discussed were:

1. to resolve the ballot comments on the Final PDAM to X.509. This extension work covers attribute certificates and extensions to v3 certificates and v2CRLs,
2. to resolve the ballot comments on the Final PDAM to X.500 on Enhancements to Support F.510 (automated telephone directory enquiries),
3. to resolve the ballot comments on the Final PDAM to X.500 Mapping of Directory Protocols onto TCP/IP,
4. to resolve the ballot comments on the PDAM to X.500 on Related Entries, to Solve the Multiple Service Providers problem,

11 countries voted for the FPDAM, and 1 (Denmark) voted against. The UK abstained, and did not submit any ballot comments. The ballot comments were successfully resolved and the FPDAM will proceed to DAM after the editors finish the revisions to the text. This part of the meeting was attended by Anthony Hodson, and he may submit a fuller report in due course.

13 countries voted for the FPDAM and none against. This document will progress to DAM

9 countries voted for the PDAM and 2 against (US and Denmark). The ballot comments were successfully resolved and the output will be progressed as a FPAM.

13 countries voted for the FPDAM, although there were a substantial number of ballot comments (<120). The UK voted yes, but had one ballot comment requesting the addition of a Pseudonym attribute type to X.520, in order to support Qualified Certificates as specified in the EC Electronic Signature legislation.

The ballot comments were dealt with in two parts, those concerning attribute certificates and the supporting privilege management infrastructure (PMI), and those concerning public key certificates and its infrastructure (PKI).

It was clear that the terminology and descriptive material concerning PMIs in the FPDAM were not adequate for the first time reader, or were ambiguous or confusing, since France (which had previously not attended the meetings) had submitted 62 ballot comments. Many of these were editorial, or requests for clarifications, or were simply wrong due to a misunderstanding of the FPDAM text. Consequently a significant time was spent at the meeting trying to resolve these ambiguities and produce better terminology, acronyms and definitions. (Note that the final editorial crafting of some of these is still continuing after the meeting, so the list below may not be entirely correct.) Some of the changes that were agreed included:

• the "owner" of an attribute certificate is now termed the "holder", since this better reflects the semantics (the attribute authority is really the owner or originator of a privilege, whilst the subject of the certificate is the holder of the privilege until it is revoked by the authority).
• New acronyms for revocation lists was created, viz:

• Delegation and assignment were used synonymously in the text. It was agreed that assignment will now be the giving of privileges in a certificate to a holder by an authority, and that delegation will be the holder conveying some or all of these privileges to another entity.
• There is a need for a definition for privilege and delegation to be added (these are to be added by the editor after the meeting)
• There is confusion over the difference between roles and capabilities. E.g. a Watch Officer is a role and has duties, but the person may be different and the rank may be different in different branches of the forces i.e. capabilities of role holder are different. Consequently there are two definitions of role. First, a role is a job description independent of privileges, second a role implies privileges. Chief Financial Officer is a job title and a role under the first definition since no privileges can be implied from this. Capability on the other hand is an ability to perform an action on a resource, which equates with the concept of privilege in the FPDAM.
• There is a problem with SOA is that the resource is not specified. This was added to the definition, but it was agreed that how this is configured into the system that uses it (as a trust point) can not be specified in the FPDAM.
• The text seemed to imply that attribute certificates are normally only attached to claimants (holders). However, they can also be attached to target objects (resources). E.g. attach a sensitivity label to an object such as a file, as an attribute certificate, and link it to the object by its hash or its name. It was agreed that this is within the scope of the document.
• Possible new terminology concerning roles:

• It was agreed that the verifier needs to have a clear understanding of the privileges granted to a role, and that these privileges may be defined by private means (outside of the PMI) or via an attribute certificate (inside the PMI).
• We changed the definition or the role attribute that assigns a role to a holder, into a sequence of authority name and role name.
• We agreed to simplify the pointer AuthorityAttributeIdentifier to be simply a certificate serial number. OwnerAttributeIdentifier will be simplified to the name of the SOA, and a pointer to where it might be found.
• We agreed that key separation is a good thing, so existing text that suggests the use of one key for two purposes should be deleted.
• We simplified the attribute descriptor extension and changed the domination rule to a policy id.
• SOA identifier. This field may only be in PK certificates and not in ACs. Also we changed the syntax to null from boolean, and added text to say that this field is only required in environments where a CA controls who may be an SAO.

Finally, we added a new extension "No revocation", that means that no revocation information is available for an attribute certificate. This extension will always be non-critical.

Issue 1 concerned terminology for CRLs. The proposed terminology is listed above.

Basic constraints. If these are not present in a certificate then according to the 97 standard it can be a CA certificate if determined by out of band means. The DTC proposes changing this to be compatible with the Internet PKIX standard that mandates that this field must be present for CA certificates. Japan objects to this since it already has systems supporting the 97 standard, with CA certificates without the basic constraints. Agreed that this change will be made to the 2000 standard, but probably not made to the 97 standard (i.e. the DTC is expected to be rejected).

It was clarified how to find CRLs: i) in directory entry of CA, ii) pointed to by a CRL distribution point, iii) have a statusReferral extension in the (old) CRL entry pointing to new place where CRL will be found, iv) indirect CRLs where another CA publishes your CRLs, v) complete out of band mechanism.

Japan 14 wanted to have a revocation date in a CRL sometime in the future. This was rejected as it may break existing implementations. Suggested that this could be a future work item, and that CAs could do the administrative work and prepare the CRL information now but not issue the CRLs until the actual revocation date is reached.

Issue 3 of the FPDAM concerned name mapping for CAs that do not have registered names. We agreed that the problem is real, but name mapping as currently defined does not work. Therefore it will be deleted from the DAM and possibly a new work item raised.

Japan 20. Issuing of delta-CRLs. Japan misunderstood the mechanism. You can issue a delta for a base that was never issued, providing that a base after the one referenced in the deltaCRL has been issued. In this case, you can work out the set of revoked certificates by throwing away duplicates that are in both the delta and the base. Some clarifying text will be added to the DAM.

D W Chadwick

18 November, 1999