The author was only present for 3 days (Wed – Fri) and this report covers the PKIX, LDAPExt, LDUP and LSD2 BoF meetings.

The proposed standard cannot proceed to draft standard until 6 months after its publication (which has now passed) and 2 independent implementations of each required and recommended feature are found. It does not have to be the same 2 implementations for each feature, rather that every feature has been implemented by two different implementations and they interwork. A feature survey is about to be undertaken to ascertain what has and has not been implemented.

A bug has been found in the X.509 algorithm for certification path validation in the presence of policy mappings. A defect report has been raised to the X.500 group. A group of implementers will work on a fix for submission to ISO during September. Hopefully the proposed fix will not break any of the existing implementations. Finally a list of typos and minor editorials have been identified in the proposed standard and these have been circulated to the mailing list.

It is anticipated that a revised version of the proposed standard will be issued in November. If the defect resolution text will work with the existing implementations then it could be issued as a draft standard.

There was a discussion about the new X.509 text for issuing delta CRLs on any base CRL, rather than on just the latest base CRL. A straw pole showed that the group favoured including this feature in the revised text by a 2:1 majority.

The existing text has been found to be deficient in a number of areas, particularly in the legal areas, general provisions and certificate life cycles. There is also insufficient differentiation between certification policies and practice statements. A group led by IBM has met with the American Bar Association, the Open Group and at the RSA Conference to work on the enhancements. A new mailing list to discuss the changes has been set up at:

The final version of this draft should be available in a few weeks for last call.

A new ID has just been issued containing updated text on Qualified Certificates, name constraints and name encoding. New sections on Attribute Certificates and DH PoP have been added. More work is still to be done.

The current version only supports timestamping to an accuracy of 1 second. Many people see a requirement for adding greater precision to the timestamps and a data structure for this has been proposed. However the ID is currently deficient in specifying which time is inserted in the timestamp – should it be the time of receipt of the request, or the time of generating the timestamp (which will be later).

There was a discussion about the Temporal Data Authority field. This is an optional field in the timestamp token that adds supplementary evidence about time. It is meant to show that the data existed before an unpredictable event, and is supposed to add more trust to the time in the timestamp. The group was not convinced of its value. A subsequent speaker tried to persuade the PKIX group to keep the TDA field in the timestamping service, but whether he will be successful or not remains to be seen.

Finally Denny Pinkas spoke about the Patents issue. The Timestamping ID currently references 8 US patents filed between 1989 and 1997. The most restricting one patents the idea of signing a hash of some data with a timestamp to prove its existence before some point in time. However, Denny pointed out that in 1989 AFNOR originally published this idea in a paper submitted to the ISO meeting in London with a revised version to the ISO meeting in Seoul in 1990. This covered all the concepts included in the current ID and therefore shows prior art. Since the AFNOR papers were circulated to ANSI and the US companies in the patents are members of ANSI, a legal case can be made for prior art.

This ID, which has now expired, describes multiple PKI based services including SCVP, OCSP, TSP and Notarisation. There was some discussion about the future of this draft but nothing conclusively was determined.

This draft proposes to solve the certification path validation for clients with limited processing power by delegating the task to a remote server. This can also be of benefit if the CA is concerned about its policy being adhered to by all relying parties, since the policy only needs to be sent to the single server rather than to each client.

The current ID has now expired. A new one will be issued a few weeks after this meeting containing the resolution of issues so far raised. Concerning legal issues: the EC regulations require the ability to use pseudonyms (this has been solved by putting a pseudonym attribute in the subjectAltName field) and to state in the certificate that it is a qualified certificate (this has been solved by a new extension rather than a qualifier in the policy field). SubjectAltName extension is used to hold the legal name, whereas subjectName holds an X.500/LDAP distinguished name. If the latter is unambiguous (unique and equivalent to a legal name) then you don’t need the subjectAltName to be present.

The new QCStatements extension holds legal statements, with the legal entity identified by an object identifier.

The new BiometricInfo Extension is used to hold biometric identifying information. Its actually a hash of the biometric signed in the certificate.

The name of the ID will be kept as Qualified Certificates since it has been shown that EC qualified certificates can be represented by this X.509 certificate structure.

The ID will hold an example of a qualified certificate before it goes to final call.

The author gave a short presentation about the new ID that he has published. The rationale for the profile was explained. No one objected to this. A couple of sets of comments have been received on the mailing list and these need to be addressed.

The ID could go to final call as early as August, depending upon the number of comments received and the amount of feedback that is necessary.

This covers a profile of the AC, validation of ACs, and revocation of ACs. One outstanding issue is the level of binding between the subject of the AC and the subject of the IC (identity certificate). Should it be based on subject name, hash of public key, hash of certificate etc. If latter the IC cannot be replaced without requiring the AC to be replaced as well. This is really only an issue for relatively long lived ACs compared to the life of ICs.

Should LDAP be used to retrieve ACs and ACCRLs or not? The current ID suggests a new protocol LAAP that can run over HTTP, that is lighter than LDAP. This will be moved out into a new ID.

What should be in the profile, e.g. encrypted attributes, any attributes etc. It was decided to have two profiles, a basic profile and an extended profile within the one ID. What should be in the basic profile? Suggestions made at the meeting include: no critical extensions and no delegation of authority. Encrypted attributes should not be in the base profile. Proxying (delegation) should not be there. Targeting, where the name is present in the AC, could be in the basic profile.

Another issue raised was "Is the AC issuer trusted to issue ACs containing this attribute?" Steven’s proposal is to define an IC extension called AAControls in the SAO’s IC, that lists the permitted and excluded attributes that the SOA is allowed to place in ACs. This caused significant discussion in the meeting as it ties the issuing of ICs into the AC. The CA is effectively becoming an AA since it authorises the AA. This is against the original model of having the AAs completely separate from the CAs. I don’t think many people were in favour of this.

Compact time stamp token for system events, database transactions etc. It contains no embedded proofing mechanisms except the applied signature and pointers to the actual data and a hash of the data. Uses UTC96 time which is Y2K compliant and has sub-second accuracy. Also have a leap second count and GPS position. Total size of BERT token is approx. 500 bytes (but currently not ASN.1 encoded). No patents pending that the presenter knows off. Proposal got a cool response, since only one vendor has hardware that currently supports BERT, seems to be a local system function rather than a network based service.

Optional field in timestamp token that adds supplementary evidence about time. TDT is supposed to add more trust to the time in the timestamp. Speaker wants the PKIX group to keep the TDA field in the timestamping service.

Two workshops held in May and June with 5 vendors, including IBM, Baltimore, and Entrust. Tested initial registration, self revocation, plus 2 additional tests. Workshop used file transfer cos no MUSTs in the RFC. HMAC-SHA1 was implemented differently by vendors. Found 22 items that need to be reviewed plus 18 recommended solutions. Size of salt and shared secret needs to be agreed upon. Next workshop will be in September. Results can be found in

<draft-moskowitz-cmpinterop-00.txt>

Signed operations – are in RFC editor's queue

Recommended authentication methods, Start TLS and DIGEST-MD5 – are with Area Directors

Access Control Requirements – are with Area Directors as well

LDAP APIs (Java and C) – under last call

X.509 SASL mechanism – experimental RFC

Location cal/sch server attributes – last call

InetOrgPerson – last call

Representing Java objects in LDAP directory – last call

Representing Corba objects in LDAP directory – last call

Dynamic attributes and dynamic non-leaf entries – no interest is being shown in these now and so they will probably be dropped.

Original draft was solving two problems (navigation within same name space and organisation, and navigation between different organisations/name spaces) and was not liked because of this. At the last IETF meeting it was decided to separate them into two documents and the first part has been issued as NamedRefs.

I did not know about this decision, having not attended the last meeting, and so my draft <referrals>, issued immediately after Oslo, still contained solutions to both problems.

Is still plodding on.

To find the LDAP server for cn=jim, dc=microsoft, dc=com.

Look up microsoft.com in DNS and get the SRV record that holds the weighting and priorities for the LDAP servers that hold the replicas of the naming context. If no SRV record is found it probably means there is only one server, so get the A record for it.

Support for this has been built into Microsoft Windows 2000.

Presentation by Netscape on counting the number of subordinates beneath a node. It is useful for situations were there are a large number of subordinates beneath a node, so that the client knows not to try to list them. Netscape defined the operational attribute numSubordinates, that gives the count of all immediately subordinate entries including DSEs. X.500 hasSubordinates (boolean) proved unsatisfactory because it does not count the entries, and it has to be created and deleted as subordinates are all deleted or created. Unfortunately Innosoft has the same attribute in its implementation that does a different thing – it counts all the subordinates, not just the immediate subordinates. Also if the entry has a referral, it does not count the referred to entries. The meeting agreed that a new draft would be issued to try and resolve all the issues and then the group will decide whether it should be standard’s track or not.

Created by UK, Canada, New Zealand, Australia and USA. Also used by NATO. Contains the schema being used plus guidelines for using LDAP to access an X.500 directory. Each nation has a separate military directory and they allow part of it to be shared with their allies via a Border DSA. Uses DAP primarily but have now added the capability of using LDAP. They have a number of suggested additions to the proposed LDAPv3 standards, which will be fed into the revisions that will be published as draft standards.

The problem is how can a remote client present data from an LDIF file to a server. Most servers only allow LDIF files to be read in from a local server. Remote update presents some tricky issues, such as adding group membership when the members are to be created later in the bulk update. There is a need to keep transaction and referential integrity. The suggested mode is that the client initiates a bulk transfer, asks for periodic replies of progress and indicates which types of error are fatal. Updates may be applied synchronously or asynchronously. Another idea is to have a control for ordering asynchronous LDAP requests. It was decided that this work should be part of the LDUP group.

The author made a presentation about the second version of the Internet Draft. It was well received by the group (there were no dissensions) and Tim Howes asked how many people intended to implement this. A number of hands were raised including that of the co-chair Mark Wahl. However when the author stated that he would like the draft to become an Internet Standard within the LDAPExt group, Tim Howes replied that it did not have to be in the LDAPExt group to become an Internet Standard, and could progress as a personal document. After the presentation, a number of attendees approached the author and made some specific comments about the ID, namely,

• that it should specifically be stated that Deletes are atomic, and that all deletes should work or none should work, and
• the defaults should be that the whole family is treated as one compound entry, rather than as separate ones.

On this last point, significant Email discussions have been had on the LDAPExt list after the meeting.

Will be turned into a combined draft for the next meeting.

The last call on the Replication Requirements document will be issued as soon as possible after the close of the meeting. It needs an addition to the security part to specify that if a combined delete removes the entry and its associated ACI, that this should not be reversed in a replica i.e. ACI deleted first, allowing temporary access to the entry.

Replication Architecture document. Sparse replicas i.e. not every entry is copied, are being deferred as they are too complex to define in a multi-master environment. No-one has implemented this in any product to date. The meeting agreed that they might still include sparse replicas in a single master environment, as X.500 supports this feature. There was a discussion about consistency, and it was re-affirmed that only weak consistency is supported, and clients need to be aware of this.

There was a discussion of constraints violations that can occur with multi-master replication, that the client is not made aware of (unlike with single master replication where the client gets an immediate reply if a constraint is violated). Examples include:

This part of the document cannot be considered consistent nor stable at the moment.

Replication Model. The model of subentries will be sent to the LDAPExt group as it is a generally useful construct. Some other bits are being deleted or simplified so the document should be shorter next time around.

Reconciliation Procedures. Glue entries have been added to solve some of the constraint violations. Alison Payne has a diagram that shows the procedures, but this cannot be put in the draft as it is not in .txt format.

Replication Protocol. An ID is to be published in a few weeks time. It will use Extended Operations in LDAPv3 to initiate and transfer updates.

The purpose of this meeting was to see if there was any IETF standardisation activity that could be useful to help solve the problem of accessing multiple directories from different organisations. LDAPExt primary concentrates on accessing a single corporate directory server. There were 3 presentations of current R&D projects.

Roland Hedberg talked about the TISDAG project, that has built an index server accessible via a number of protocols: LDAP, Whois++ and HTTP. The indexes are CIP tagged index objects (TIOs). The index server also accesses directory servers using a number of different protocols and passes referrals back to the user. Practical experiences gained from running this pilot service showed that suppliers were only implementing part of the IETF protocols e.g. LDAP and thus the service being provided was less than optimal i.e. it did not work properly or as expected.

Peter Geitz talked about the EC Desire project, which has built an LDAP index server, again using TIOs. The difference between this project and TISDAG is that in TISDAG the server produces the TIOs and sends it to the index server, whereas in DESIRE a web crawler trawls the LDAP servers and builds its own indexes.

Harald Averstrand talked about the Norwegian Directory of Directories that is building a referral server for to hold information about every organisation in Norway (approx 1000) plus referrals to those that have their own directory service. They have a requirement for X.500 NSSRs or something similar. Harald mentioned designing a business model for such a service but several people in the audience objected strongly to any mention of business models in IETF meetings. It was agreed that one can talk about service models, but that is reaching the limit for IETF meetings. The service is not yet operational, but should be shortly.

D W Chadwick

19 July 1999