RSS
|
|||||||||||||||||||||||||||||
  Prologue to a Protocol? June 14, 1999
CA vendors have tried to protect the application vendors from doing their own certificate management by developing browser plug-ins that perform all CA interactions. This way, the application need only perform the certificate validation. But success with these plug-ins has been mixed. They tend to tie the application to the browser's certificate storage, which might not handle an application's needs well. Now it has fallen to the IETF to develop a CMP (Certificate Management Protocol) that all applications can use. An initial proposal, by Carlisle Adams of Entrust Technologies, was a full bootstrap protocol that starts with the retrieval of a trustable root certificate by accepting the client certificate. Some in the security community found this too complex because the protocol did not use PKCS 10 and 7 (the de facto data formats), and the new data format, CRMF (Certificate Request Message Format) needed further development. Others felt that because root certificates are typically on the workstation, courtesy of the browser, a full bootstrap would be overkill. A group led by Verisign and Microsoft developed a simpler protocol, CMC (Certificate Managment Messages over CMS), based on the assumption of both root certificate ownership at the client workstation and the use of PKCS 10 and 7. So, in typical standards fashion, two protocols were developed and it would be left to the market to pick the winner. Now we have RFC 2510 (CMP) with RFP 2511 (CRMF) as the full-blown protocol, and Internet Drafts draft-ietf-smime-cms-13.txt (CMS or Cryptographic Message Syntax) and draft-ietf-pkix-cmc-03.txt as the simpler protocol. CMP assumes nothing and builds trust; CMC assumes a base of trust from a previously acquired root certificate. The assumption of trust and the number of data packets transmitted--CMP requires a minimum of three, while CMC requires only two--define the market niche for both protocols and ensure both will be viable. CMP mandates the use of CRMF but supports PKCS 10/7; CMS is the other way around. This places the initial focus on protocol migration, leaving data format changes for later, after a dominant protocol has emerged. CMP's niche is in new e-commerce applications on high-assurance systems that don't trust information preloaded on a system. A cell phone and PDA with a root certificate for the cell operator and network latency concerns is a perfect candidate for CMC. Browsers for the home market, where the public CAs will include their root certificates in the distribution files, are also possibilities for CMC. Support for CMP and CMC will pop up in CAs later this year. Certificate-enabled applications will be working on their beta applications with beta toolkits, possibly leading to standards early in 2000. While an end to CA fiefdoms may be in sight, PKI pilots may be as far as we get this year. Robert Moscowitz is a senior technical director at ICSA. Send your comments on this column to him at rgm@htt-consult.com. |
|||||||||||||||||||||||||||||
Here
Here
our customizable newsletter, sends you security alerts, product updates and software patches on the products you use. Sign up now at 
When vendors enable applications for digital certificates, managing the certificates is more complex than using and validating these certificates. Managing certificates presents many new programming challenges for the application vendors. These challenges (new data formats, new protocols and new failure states) can be met by building or buying the technology, and usually results in the decision to buy. No long-standing certificate-management standard exists, so management toolkits produced by CA and LRA vendors typically work only with that vendor's CA.
