IETF Meeting Report, San Diego, 11-15 December

By David Chadwick, University of Salford

LDAPEXT Meeting. 11 December 2000

Items nearly ready for last call.

Locate. Finding LDAP Servers with SRV records. It was agreed to leave out LDAPv2, UDP and CLDAP. A big discussion ensued about whether this document can be altered to cater for X.521 based naming, by using an alternative mapping to find DNS names from LDAP DNs. There was little enthusiasm for altering this ID, but people were not averse to another ID being written that describes an alternative DN to DNS name mapping.

LDAP Java API. Various changes from the v11 draft, including removing LDAPv2 and LDAPv3 calls, have been made in v12. Some more edits are still needed before it can go to last call.

Referrals and Knowledge maintenance. Proposal is now to have two IDs, one simply for subordinate references, the other for superior, cross and other reference types. The former will be issued very soon. The latter will be issued at the beginning of next year.

Duplicate Entries. This has gone through last call already (version 5). A few minor edits have been made, and v6 will go to last call again.

LDAP Access Controls. This ID has not been updated since version 6 from July. It is proposed to issue a new version in the New Year.

Connectionless LDAP. CLDAPv3 is substantially different to CLDAPv2. Latter only does searches, former does search and compare over UDP, but not updates at the moment.

Subentries. New type of subentry, called an Inheritance Subentry (subclass of LDAPSubEntry) has been added, with an Inheritable boolean attribute (MUST contain). BlockInheritance (MAY contain) may be added down in the tree to block the inheritance for that entry only. Quite a detailed discussion of inheritance followed which reached no agreement about the correct way to proceed here. It was decided to discuss this in more detail later on the list, and maybe remove the feature if no agreement can be reached. A new control has been created for accessing subentries, based on the X.500 semantics. One change from X.500 however is that a Search Base Object that targets a subentry will work and the control has no meaning.

Charter Review

Dates were set for items already in the charter as below:

Server discovery: 3/2001

Java API: 3/2001

C API: 6/2001

Referral: 3/2001 (for named subordinates); 6/2001 (for other referrals)

Access controls: 6/2001

CLDAP: 9/2001

Topics not yet in the charter

Subentry: needed by LDUP

Rescodes: should be moved to LDAPBIS mailing list

RFCs 2247/2255 may need updating when I18N is added to URLs and domains.

Value Controls. Duplicate Entries and Matched Values

Chaining and Proxying – 3 IDs

Request/response grouping – 2 IDs

Password Policy Management

The Area Directors have suggested that the following be added to the charter.

Subentries. Value Controls.Request/Response Grouping. Chaining and Proxying

The following should Not be added.

Password Management. Multiple Entry Updates e.g. tree delete

X.500 Alignment with LDAP

Peter Yee gave a short talk about X.500 suggested areas for alignment. These are: X.500 encapsulation of LDAP requests in DSP, Related Entries, Subentries, and Security. No decisions were taken about this at the meeting, so it is unclear how the LDAPEXT group will repond.

Evolving LDAP Scheme Entries

How to manage and update schema definitions. What should be the output of the group: a BCP for handling schema or schema operations for management. Should this become a new IETF working group or not?

Other Topics

Verisign who now run the domain registration service want to use LDAP to store domain registration information. They have deployed a registry server and a registrar server. The former allows people to search the 16+ million registrations and see details of the domain names. The latter holds details of the registrants of domain names (?).

After the meeting, the Mark Wahl had a word with the author to explain why Matched Values had not been issued for Last Call. There had been some confusion over what was the latest version. The author duly sent the latest version to last call again after the meeting closed.

DNS I18N Meeting, 11 December (IDNS)

John Klensin presented two radical solutions to the problem of internation domain names. The Charter proposed quick solutions. But the IETF has already lost as proprietary quick solutions are now operating in the market place, and there are problems with them. E.g. Verisign has published a solution that sends domain names in UTF8 on the wire, but this breaks some applications. Quick solutions often stay around a long time, well beyond their sell by date. He asked the question "if we were to start today what would we design for the long term?". The problem then is how to get there from what is deployed today. We must design for non-ASCII characters everywhere. The IETF has traditionally kept things simple, with the user interface close to the protocol. But this may not be feasible for I18N.

There are two conflicting viewpoints. ONE. Its not a DNS problem. Solve it at the U/I level. TWO. It is a DNS problem and the DNS should support any characters.

Looking first at solving it at the U/I level. The DNS has a very limited service provision. There should be a directory on top of the DNS. Users should call the directory, get a result and then present this to the DNS. However there are some disadvantages with using a directory. Foremost, the IETF has never had success at deploying a global directory service. Also during migration, legacy applications will continue to call the DNS with ASCII characters. I18N applications will call the directory, and eventually everything will move towards calling the directory first.

Now if DNS update is the correct solution, what would it look like. Mixing old and new protocols is often difficult. But there is a way. We can obsolete the Class=IN records, and create a new I18N class. Every label and string will be in ISO 10646. It will create a lot of political problems. Legacy applications will continue to use Class=IN. New applications will use the new class. All the existing domains are mapped into the new class, and all new I18N names only exist in the new class. Eventually the old class dies out as people use it less and less and less entries are in there.

Two new IDs have been published to describe both of the above: draft-klensin-dns-role-00.txt and draft-klensin-i18n-class-00.txt.

IDNA Solution by Patrick Faltstrom. This solution introduces an IDNA layer above the current DNS. The application user interface will input/output via IDNA to a communications layer. The communications layer then calls the DNS and the applications. Below the communications layer ASCII is still used, possibly with Q encodings. The IDNA layer (a presentation layer) converts it into the I18N characters for presentation to the user.

Virtual I18N Domain Names by a Korean Professor. Conversion between ASCII and I18N characters is done at the user interface level. Today transliteration already takes place between characters in local script and characters in ASCII script used in the DNS. Transliteration is the process of converting the characters of a local language into those in another language that sound the same (e.g. phonemes from local language are matched to nearest English phonemes). He gave an example for Hyundai and the equivalent characters in the Korean script (which cannot be reproduced here). Because the transliteration is not an exact match e.g. Hyundai, Hiundie and Hiundai all sound the same, the server needs a unique ID for the transliterations so that exact reverse matching can be obtained. These codes should be allocated by a standards body.

Internationalized PTR RR by Hongho Shi Jiang Mingliang. The current PTR RR cannot support IDNs as well as ASCII DNs. Suggest the use of a new IPTR RR that gives a LANGUAGE selection e.g. IPTR "LANGUAGE" "name in utf8". The IPTR must support Ipv6 as well.

Output of the design team.

The design team have done a comparison of the different protocol proposals plus they have issued a recommendation. There are three possible ways forward:

1. Do a long term clean fix
2. Change applications only and leave the DNS as is.
3. Change applications now for a short term gain but transition to the long term fix over time

No solutions are without their problems. A two phase solution might never have its long term solution adopted if the short term fix works OK. This rules out 3. Why cant we put binary characters into the current DNS. Ans. Because it will break many applications and some DNS servers. DNS Infrastructure solutions have many migration problems. So this rules out 1. ACE solutions are easier to implement and only affect applications. (ACE = ASCII Compatible Encodings.) So this is the recommendation. The negative aspect of ACEs is that not-updated applications will see the ACE encodings that make no sense to them or will appear to be illegal. The IETF needs to choose which ACE to adopt. Besides the ones that have already been presented, there are probably some others that they have not yet been considered. The design team therefore recommends that we go with application updates using an ACE.

LDUP Meeting. 12 December

Replication requirements document

2 new requirements have been added and eventual consistency becomes mandatory. Albert Langer proposed that Model 3 (limited effort consistency) should not be supported, but the group agreed to keep it, because if a directory is refreshed then it will become consistent again by external sources. Question about when the requirements should be published as an RFC, before Update Reconciliation Procedures (URP) is finished or when it is finished. The meeting agreed before.

Atomicity issues. If the same entry is updated by different applications, there was a proposal that either all one set of changes or all the other set of changes should be accepted, but not a mixture of both. It was agreed that if neither of the changes conflicted then both sets should take place on the same entry. However if a conflicting update takes place i.e. the same data item (attribute value) is changed by both applications, then what happens? Answer, the latest one wins, but the application that had a data item change undone, wont know about this, except that an administrative log is written that will allow human intervention to sort it out later. This is not an ideal solution, but is documented in the LDUP specifications that this can happen.

URP

Ready for last call and will go after Requirements are sent to RFC.

Replication Model

Three mechanisms defined for replicating policy information. i) Leave it up to each administrative group to say how their administrative information should be transferred. ii) Transfer administrative information manually via the administrators of the replicating servers iii) Automatically copy all administrative information between replicating servers.

Much discussion was had, and a small working party agree to meet at 5pm in the bar to discuss this in more details (see below).

Subentries

This work has just added new inheritance features which has slowed down its progression to last call.

Grouping and Framing

The previous meeting agreed to merge these documents but Kurt had difficulty in doing this. Framing comprises a start frame, a set of operations and then an end frame. Grouping however is tagging each operation as being part of a group of operations. Groups can be interleaved, frames cannot. Mark Wahl thought these were still one basic problem abstraction with a paramter for interleaving, not two different abstractions. It should be possible to write one ID for both.

LDAP Client Update Protocol

Stop Update Client request and response have been added.

There are still some outstanding issues. What to do about referrals and continuation references. ManageDSAIT solves the problem about updating references.

A Keep Connection control value has been added.

A question from the author about whether the existing update protocols will be phased out in favour of LCUP when it is a standard or not. Triggered search is being withdrawn from Innosoft, and Netscape will support LCUP. Microsoft were not available for comment, but are joint authors of the ID.

IDs missing in action

Mandatory Replication Requirements. Ed Reed too busy to do it. Jim Sommersheim (Novell) agreed to take over.

Master-Slave Multi Master Profile. Uppsilli too busy to do. No-one else voluteered.

LDUP Modelling (unofficial) Bar BOF. 12 December

A group of people met in the bar on Tuesday evening to continue the modelling work started in the LDUP meeting. David Chadwick described the X.500 model for replicating administrative information between servers, using DOP, and the group saw that a variant of this, using LDUP could be used by LDAP for replicating access controls and schema hierachically in the DIT. This work will continue on the list after San Diego.

PKIX Meeting (12 and 13 December)

The PKIX working group currently has 20 outstanding IDs, 2 in the RFC queue, 2 in the editing queue, 2 for Area Directory review, and 7 in Last Call.

The PKIX group met on two separate occasions during the week, and still did not have time to complete its agenda.

Qualified Certificates Profile - Stefan Santesson (Addtrust) This document has been approved as a Standards track RFC and is currently in the editing queue. ETSI are also working on qualified certificates, and have approved 3 qualified certificate statements to be included in a certificate (e.g. max value that can be signed for, and duration of archived data) but how these are to be displayed to the user is currently not decided. Another outstanding issue is how can brands be displayed to the user if these are in the certificate. PKIX could define an extension to include a hash and pointer to a logo, but this work has not started yet.

Attribute certificate profile - Steve Farrell (Baltimore). This document has been through working group Last Call and is currently under Area Director Review. As a consequence of Last Call a number of minor changes have to be made e.g. mandate using v2 Attribute Certificates.

Time Stamp Protocols (TSP) - Denis Pinkas (Bull). This document has been through working group Last Call and is currently under Area Director Review. As a consequence of Last Call changes were made to accommodate 24 comments. A new Appendix F, Access Descriptors for timeStamping, has been added. ETSI is likely to have a work item on security policies for Time Stamping Authorities. It or PKIX could define a set of standard policies e.g. policy for a time stamp valid for 5 years.

Permanent Identifier - Denis Pinkas (Bull). DNs are not permanent, but this ID allows a way of defining a permanent id as an optional extension in a certificate. This document is stable and ready for last call. Should it be Informational or Standard’s track? It will be taken to the list for a decision.

Technical Non-Repudiation - Tim Polk (NIST) for Tom Gindin (IBM). After minor changes are incorporated to address recent comments, Tim said this document will be ready to progress as an Informational track specification. However, Denny Pinkas disagreed with this. Denny gave several reasons where the document is inadequate. Firstly, you must prove the certificate is valid at the time of signature, by either time stamping or a secure audit trail. Also verification needs to be proved soon after signing and also a long time (e.g. 20 years) after signing. CEN/ISSS is writing a similar document, which will be finished next week, which is much more comprehensive. The meeting agreed that the ISSS document should be sent to the list as soon as it is published, and the current ID needs to be updated to cater for its deficiencies.

Delegated Path Discovery (DPD) and Delegated Path Validation (DPV). For DPD the client is certificate and CRL aware and can check them out, it is merely asking for a path to be discoverd for it. For DPV the client has offloaded the entire work to a server which will reply Yes or No to the certificate. Someone made the point that during DPD it is normal to validate the path as you go along, therefore the value of a DPD only service is questionable. DPV could be used in a corporate environment or on the Internet for public use. Steve Kent said that there are a number of complex issues in DPV that have yet to be solved. E.g. What information is needed back in DPV in addition to the Yes/No reply e.g. key usage flags, or the name in the certificate? What format should the reply be in, ASN.1 or XML? The working group has been presented with several alternative proposals. These are the Simple Certificate Validation Protocol (SCVP) and Delegated Path Validation in OCSPv2 drafts but neither solve all the problems outlined by Steve. The WG needs to select one I-D as the PKIX path validation protocol and create one standards track specification. This work will continue for some time yet.

CMP/CRMF Interoperability Testing Results - Bob Moskowitz (ICSA Labs). Bob has been organising interoperability testing for CRMF/CMP implementations. This testing will support the progression of CMP and CRMF to Draft standards. The main problem is that there are a lot of options and different implementations have chosen different ones. There are over 80 different testing options in total. The interoperability testing participants include all the major vendors (>10) plus one open source implementation from Peter Guttman. Limited CMP interoperability was achieved for the first time during the last set of tests (not CA to CA interoperability, but EE and RA to CA communications). There is still some testing left to do including: CMP transport polling and http testing, plus qualified certificate protection of transactions. More participants are wanted for the tests next quarter. The PKI Forum have stated that they are going to start OCSPv1 testing soon.

Certificate Management Protocol update (CMP) - Carlisle Adams (Entrust). This document incorporates clarifications to RFC 2510. These changes are proposed as a result of the interoperability testing. Many functions have been moved to optional from mandatory status because no vendors have implemented them (vendors did not think they were necessary for certain business models.) One example is cross certification. Another is General Message. Some new error codes have been added. This specification is nearly ready for Last Call and progression of CMP to Draft Standard.

Certificate and CRL Profile revisions - Russ Housley (SPYRUS). This document is the follow-up to RFC 2459. A new draft of this document has been published. A new algorithm specification has been pulled out and put in a separate ID, which is ready for last call now. Son of 2459 will be ready for Working Group Last Call in January. However, no algorithms are mandated for certificate and CRL signatures. Profile modifications have been made to align with QCs, support for inhibit any policy is now required, and subject directory attributes have been added as a May. It has also been aligned with the X.509(2001) processing algorithms. A RP can now apply constraints to path validation. If alternative names are used, the CA must be able to enforce this. However there is an apparent disagreement between the X.509 group and the PKIX group about the Permits name constraints. The X.509 group/standard says a permitted name must be in the subject field of every certificate, the PKIX group say "only if a subject name exists" (i.e. If subject name is empty, is the certificate permitted or not? The name might be in the alternative name field.). The PKIX group say that the standard is ambiguous in this area, and that they conform to it if the subject name is null. But Sharon said that the minutes of the X.500 meeting did not agree with the PKIX position, although the standard does not fully reflect the position of the X.500 group minutes. But how can non-meeting attendees be expected to know the real meaning of a feature other than what is written in the standard. Clearly the wording in the standard needs to be tightened. The PKIX group position appears to be that the alternative names field should be sufficient to satisfy the Permits name constraints (which I think is reasonable, and we could update X.509 to allow subject alternative names to satisfy the constraint). But it also appeared from the meeting that the PKIX stand is "For naming domains I don’t specify, all names are permitted. I don’t care about other name spaces that I have not put in permitted, they are all allowed. We cannot constrain names we don’t yet know about yet". (I hope I have recorded this correctly). I actually disagree with this stand, since under the principle of least privilege, if you are not specifically included (in the permits field) then you are excluded by default. If no agreement is reached by mid-February, there will be a divergence between PKIX and ISO standards in this area. PKIX will define a new OID with their own required semantics. The PXIX document will be a standards track and is expected to go to Proposed Standard.

OCSPv2 and Delegated Path Discovery and Validation - Michael Myers (VeriSign). These documents incorporate clarifications and enhancements to RFC 2560 and define a new OCSP extension for path discovery. The ID still needs a way of identifying a certificate, of delegating path validation logic plus editorial changes. DPV is indicated in OCSP by addition of new OIDs. DPD is done in the same way. Fields have been added to allow a certificate to be selected e.g. by issuer name and serial number. New reply codes have been added (valid, invalid, suspended, and expired. Original states were notRevoked, revoked and unknown). Denny Pinkas asks if we really need all these changes. Definitions of Good, Revoked, and Unknown definitely need updating. Do we really need to add more certificate selection mechanisms? He concluded that the original OCSP was not designed for extensibility, maybe we need a new protocol that will encapsulate OCSPv1. Another speaker who followed said that OCSP has been incredibly successful. But, it has a few problems e.g. the client needs to get the public key certificate first before it issues the OCSP query. Also, since the CA’s DN cannot be guaranteed to be unique, we should be sending a hash of the CA’s public key in the protocol. OCSPv2 has 5 ways of identifying the certificates: certID, hash of certificate, the certificate itself , issuer and serial number, and a URL to the certificate. This leads to complexity and interoperability problems. The new set of return codes are too ambiguous at present. His conclusion is leave OCSP alone, it may not be perfect but it works and is not broken. This debate will no doubt continue on the list.

PKIX Roadmap - Sean Turner (IECA). This document provides an overview or "roadmap" of the work done by the IETF PKIX working group. It defines the common terms, describes the basic theory behind PKI, and provides an overview of the PKIX documents and the relationships between them. No new work has been done on this in the last 6 months except for updating references. This document is now fairly stable, and could be considered for progression to last call ready for an informational RFC.

Operational Protocols, LDAPv3 - David Chadwick (Univ. of Salford). This document is the LDAPv3 analog of RFC 2559. This document describes the features of LDAPv3 that are essential, or not required, or are optional for servers to support a PKI based on X.509. It is now ready for last call to go to the LDAPEXT group and the PKIX group.

PKIX and XML – Philip Hallam Baker (Verisign). The relationship of PKI and XML-based clients has been the subject of great discussion on the list. XML certificates have disadvantages: they add confusion, complexity and cost. But XML is a successful standard in its own right, so certificates/PKIs have to talk to XML applications. Using a PKI has to be like using all the other XML protocols. But there are problems fitting a PKI into XML. Most people still use security solutions based on passwords, because PKIs are too complex. E.g. if you use dual certificates in Outlook it wont help you talk to Outlook Express. Maybe XML can satisfy unmet requirements in current PKIs. One of the hard problem of PKIs is the inter domain trust problem, plus there are religious wars of PGP vs. PKIX vs. SPKI. Could a solution be XKMS – XML key management services that provides a minimal footprint for the client. The XKMS Trust server takes in a certificate and returns a key in XML format. The trust server builds the trust service for the client, using delegated validation. It can use PGP certificates and/or X.509 certificates, as it is certificate format agnostic. Quite how this work will progress, whether in the IETF or W3C has yet to be determined.

Agenda items not discussed due to lack of time:

LDAP Schema for PKIs and PMIs (David Chadwick)

Attribute Certificate Acquisition Protocol (Steve Farrell)

Repository Locator Service (Phil Hallem-Baker)

CP/CPS Framework - Tim Polk (on behalf of Santosh Chokhani, Cygnacom) simply said that a new draft will be published soon.