Subject: LAST CALL: draft-ietf-pkix-cmc-05.txt

From: Warwick Ford <[email-masked]>
Date: Tue, 27 Jul 1999 13:12:45 -0700

This document is hereby issued for 14-day WG last call.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 19, 1999 4:34 AM
To: IETF-Announce; @imc.org
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-cmc-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working
Group of the IETF.

	Title		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, X. Liu,  J. Schaad, J. Weinstein	
        Filename	: draft-ietf-pkix-cmc-05.txt
	Pages		: 39
	Date		: 16-Jul-99
	
This document defines a Certificate Management protocol using CMS (CMC).
This protocol addresses two immediate needs within the Internet PKI
community:
 
1. The need for an interface to public key certification products and
   services based on [CMS] and [PKCS10], and
2. The need in [SMIMEV3] for a certificate enrollment protocol for DSA-
   signed certificates with Diffie-Hellman public keys.
 
A small number of additional services are defined to supplement the core
certificate request service.
 
Throughout this specification the term CMS is used to refer to both [CMS]
and [PKCS7].  For signedData the two specifications are equivalent.  For
envelopedData CMS is a superset of the PKCS7. In general, the use of
PKCS7 in this document is aligned to the Cryptographic Message Syntax
[CMS] that provides a superset of the PKCS7 syntax. The term CMC refers
to this specification.
 
The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in
this document are to be interpreted as described in [RFC 2119].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Warwick Ford <[email-masked]>
Date: Tue, 27 Jul 1999 14:37:27 -0700

Paul:

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time...

I think any I-D implementation requirement would be highly dubious.  I can
imagine that many implementors are awaiting stabilization of the spec.
(i.e., progression to Proposed Standard status) before even starting to
implement.  Given the lengthy review this document has received (over at
least 2 years), I see no good reason for changing the usual procedures. 

Warwick

> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Tuesday, July 27, 1999 2:00 PM
> To: [email-masked]
> Subject: Re: LAST CALL: draft-ietf-pkix-cmc-05.txt
> 
> 
> At 01:12 PM 7/27/1999 -0700, Warwick Ford wrote:
> OK, here's a tricky question: has anyone actually implemented 
> the current 
> draft? If not, should we try to move it forwards?
> 
> I ask this because of the dismal track record of CMP. Many 
> months after it 
> was put on standards track, interoperability testing began, 
> and it was 
> found to be a nightmare that will almost assuredly cause the 
> spec to be 
> rewritten for clarification, and possibly to change bits on 
> the wire. (See 
> draft-moskowitz-cmpinterop for more information on the testing.)
> 
> If no one has what they think of as a full implementation of 
> CMC, I propose 
> that we wait until at least one person does. If we have only one 
> implementation of CMC, I suggest that we ask for it to be made an 
> Experimental Standard instead of a Proposed Standard. If we have two 
> implementations that can at least talk to each other a little 
> bit, let's 
> try to get it to become a Proposed Standard.
> 
> I realize that these are *not* the rules as defined in RFC 
> 2026, but due to 
> our lack of attention on CMP, I think we have to be more 
> careful with CMC.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 27 Jul 1999 17:28:46 -0700

>      months and may be updated, replaced, or obsoleted by other

This doesn't prevent someone from doing an implementation; it prevents them 
(or should prevent them) from shipping it as a product. There is a huge 
difference. The reasons for CMC existing at all are needs that are stated 
in the document. If these are real needs, there are probably developers who 
would like to meet those needs.

>I think any I-D implementation requirement would be highly dubious.

We disagree here. I think I-D implementations help decide whether complex 
protocols like CMC and CMP will possibly work.

>   I can
>implement.

That may be true, and in general that's OK. However, CMC and CMP attack the 
same problem and use many of the same technologies. Because we now know 
that there are probable flaws in CMP, it might be wise to make sure that 
similar problems are fixed in CMC before putting it on standards track. The 
way the flaws were found was with interoperability testing, not by reading 
the spec, as many of us did with CMP.

If you are correct in saying that developers aren't going to start 
implementing until they see an RFC, then we should definitely put it out. 
On the other hand, if there is already one or two developers with at least 
partial implementations, testing could help avoid problems that have been 
found with CMP.

>   Given the lengthy review this document has received (over at

The "usual procedures" for complex protocols for which there are no known 
implementations are often Experimental RFCs.

If you feel that CMC has absolutely none of the flaws found in the CMP 
interoperability testing, that's fine, but I would want to know why you 
feel that way. None of us thought that CMP would test as badly as it did, 
given all the review that was done on it.

--Paul Hoffman, Director

---

From: Ron Chittaro <[email-masked]>
Date: Wed, 28 Jul 1999 10:30:35 -0400

I agree. We are not that far off from a working interop and it is not as bad
as the document seems to suggest. Significant progress has been made in only
2 sessions and as Keith mentions better results are expected in the near
future. 

Ron

__________________
Ron Chittaro,                                        Phone - (613) 247-2683
Entrust Technologies Ltd.
750 Heron Rd, Suite E080
Ottawa, Ontario, K1V 1A7  Canada

> ----------
> From: 	Keith Brady[SMTP:[email-masked]]
> Sent: 	Wednesday, July 28, 1999 8:47 AM
> To: 	[email-masked]
>  "Flanigan," == Flanigan, Bill <[email-masked]> writes:
> 
> Flanigan,> Slapping an RFC number on half-baked protocols is indeed
> Flanigan,> experimental. So why not make it so (pro-actively for CMC and
> Flanigan,> retro-actively for CMP)? And what's wrong with progressing from
> 
> I'm not sure we're actually that far from having working interop. Not all
> of Bob's report is doom and gloom and we expect better results at the next
> one. Granted, we maybe should have started an interop before it hit RFC
> (though Entrust and ourselves did do a CCR/CCP) but sometimes we want to
> avoid the dev effort in interop'ing standards that are going to change
> incompatibly anyway (remember the message body renumbering?)
> 
> my 2p's worth,
> 
> Keith
> --
> Keith Brady,                                    Phone: +353-(1)-6054399 
> Baltimore Technologies,                           Fax: +353-(1)-6054388
> IFSC House, Custom House Quay,                <http://www.baltimore.ie>
> Dublin 1, Ireland
>

---

From: "Barb Fox (Exchange)" <[email-masked]>
Date: Wed, 28 Jul 1999 10:03:11 -0700

Paul: 

We worked on CMC as an author group which represented four companies (MS,
Netscape, Verisign, and Cisco) who each intend to implement it. Here, we
vetted it with developers on the client and server sides and I'm pretty sure
that the others did as well BEFORE we published each version of the draft.
Therefore, I do not share your concern that CMC won't be implementable or
interoperable.

--Barbara Fox
Microsoft

---

From: Carlisle Adams <[email-masked]>
Date: Wed, 28 Jul 1999 14:41:52 -0400

Hi Paul,

> ----------
> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
> Sent: 	Wednesday, July 28, 1999 12:54 PM
> To: 	[email-masked]
> At 01:47 PM 7/28/1999 +0100, Keith Brady wrote:
> >one.
> This is good to hear. However, I understand that the issues are not bad 
> implementations, but lack of clarity in the RFC. The reason I brought this
> 
> up with respect to CMC is that we now have a track record of lack of 
> clarity getting in the way of interoperability. We should take the 
> opportunity to fix it (if it exists in CMC) before it goes on standards 
> track. We as a Working Group owe that to the developer and user
> communities.
> 
> Having run many interop events, I can assure you that if you didn't
> achieve 
> interoperability after two concerted efforts, the spec has problems.
> That's 
> why I queried about current implementors of CMC. If there are any, they
> can 
> attest to whether or not the spec is implementable from. If there are more
> 
> than one, and even informal testing has happened, they can attest to 
> whether or not the spec is clear.
 
The following is my understanding of what happened at the CMP interop trials
(from discussion with someone who was there).  In a number of cases (not
all, by any means, but quite a few), Party1 and Party2 would be trying to
interoperate and the conversation would go something like this:

   Party1:  Here's the problem.  You're doing it like this and we're doing
it like that.  Why in the world are you doing it this way?

   Party2:  Because the spec says to do it this way.  Look here on page xxx.

   Party1:  Oh.  I guess I hadn't seen that part.  O.K., we'll fix it.

Many times, when people actually looked at what the spec mandated
(especially in Appendix B), problems were resolved.  I think Bob's document
did not reflect much of this and the result was that others (who weren't at
the trials) ended up with the impression that the specification was the
source of all the problems.

Reading the spec can actually go a long way toward getting an implementation
right.  :-)  At the first interop trial a number of people had not read all
of it, or had not read it carefully enough, or whatever.  By the second
interop trial the situation had improved and much progress was made.  So,
while I would be the first to admit that the specification is not perfect
(it's hard to find one that is!), I think we need to be a little bit careful
with off-the-cuff statements like "lack of clarity" and "the spec has
problems".

In any case, all of this points out the importance of interoperability
testing and I'm glad that Bob has made the effort to organize these events.
He has suggested doing the same with other PKIX protocols, which is a great
idea.  Does this have to happen before an I-D can go to Proposed Standard?
It would definitely be nice, but I don't think it's a requirement.

Carlisle.

---

From: "Flanigan, Bill" <[email-masked]>
Date: Wed, 28 Jul 1999 16:17:46 -0400

Well said, Dave, as usual.  The underlying problem (as I think we would
likely agree) is the dynamic (and the monetary/political fall out when
things don't work well or at all) of the PKI *business.*  (Yeah, I know, we
all over hyped it to get things moving!)  Vendors now implement the I-D (or
the pre I-D--see other emails) or the Proposed RFC (but only if they have
been away on Mars!).  Never mind the Draft RFC, and who the heck even
bothers to download the Standard RFC--the world has moved gigacycles by
then--since it is likely to be de facto depreciated to Historical status.
Furthermore, who reads 2026 (much less dares to tell management what it
actually says).  But if we toss the words *experimental* or *pilot* or *use
at management's risk* or *use at the risk of your NASDAQ price dropping by
half* into the RFC title (or better yet, proactively resist the temptation
and pressure to move on to the standards track until two implementers
swear--and digitally sign it--they have achieved interop), now we have a
counter to that magic anagram *RFC*.  I would venture to guess that 95
percent of the folks who sign the checks in early-adopter organizations (and
to whom you have to answer to when things fall apart) believe that once an
RFC number has been issued, it's now an IETF STANDARD SO WHY SHOULD THERE BE
A PROBLEM?!  This is why I like the sound of *Experimental RFC* or
*Pilot-Only RFC*, etc.

Bill
> ----------
> From: 	David P. Kemp[SMTP:[email-masked]]
> Reply To: 	David P. Kemp
> Sent: 	Wednesday, July 28, 1999 2:05 PM
> To: 	[email-masked]
> Subject: 	RE: LAST CALL: draft-ietf-pkix-cmc-05.txt
> 
[snip]

> Early adopters should probably refer to RFC2026:
> 
>    "Implementors should treat Proposed Standards as immature
>    specifications.  It is desirable to implement them in order to gain
>    experience and to validate, test, and clarify the specification.
>                                          ^^^^^^^
>    However, since the content of Proposed Standards may be changed if
>    problems are found or better solutions are identified, deploying
>    implementations of such standards into a disruption-sensitive
>    environment is not recommended."
> 
> One can only strive to be standards-compliant when there is a Standard
> (not a Proposed or Draft Standard) to comply with.  How would
> designating CMC or CMP as Experimental or I-D assist early adopters in
> not feeling like guinea pigs?  If your boss tells you to implement a
> prototype (as a vendor) or pilot (as a user), your choice is to ignore
> him and do nothing until there is a Standard, or implement the
> specifications that are available.  If you are an early adopter, you
> are a guinea pig, whether you adopt an Experimental RFC or a Proposed
> Standard RFC.
> 
> We in the DMS and now DoD PKI arena are very much guinea pigs, and
> there is nothing constructive we can do about it except continue to
> design, implement and test.  Other PKIX constituents are in the same
> boat.  There's nothing wrong with that; it's part of being in an Open
> process (or a democracy, or a free-market economy, or whatever).
>

---

From: Keith Brady <[email-masked]>
Date: Wed, 28 Jul 1999 19:34:08 +0100

David> "Half-baked protocols" is pretty strong language. The CMP

Indeed, this is certainly not the case with CMP as the interop has shown.

David> 1) errors in the protocol, which would prevent a single compliant
    implementation from functioning correctly,

The only one we have come across is the one John Wray identified and I
posted to the list about the CMP over TCP protocol. This is a trivial
change and an implementation may not even notice a problem. In any case
the other transports are fine (we think).

David> 2) ambiguities in the protocol, in which two compliant
    implementations would not necessarily interoperate, and

There are certainly some ambiguities but I'm not even sure we need to rev
the RFC for these (I may be wrong). A BCP might be in order, I'm not sure.

David> 3) errors or omissions in the implementations which cause
    them to be non-compliant with the protocol specifications as written.

There were, of course, a few of these. IMPLICIT/EXPLICIT, so it goes.

David> Identifying and correcting instances of 2) is clearly one of the
David> functions of the IETF standards track.

I believe we are taking the approach in the interops that corrections go
into 2510 (there aren't many) and clarifications go into an informational
or BCP RFC which will be the final version of Bob's ID.

David> adopters in not feeling like guinea pigs? If your boss tells you to
David> implement a prototype (as a vendor) or pilot (as a user), your
David> choice is to ignore him and do nothing until there is a Standard,
David> or implement the specifications that are available. If you are an
David> early adopter, you are a guinea pig, whether you adopt an
David> Experimental RFC or a Proposed Standard RFC.

I strongly agree with this. This is reinforced by the fact that it is
harder (though not impossible) to rev a PS than an ID. It means that
implementors can be reasonably sure of keeping most of their code base and
still have something ready then full standard status is reached.

cheers,

Keith

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 30 Jul 1999 10:15:55 -0400

At 04:17 PM 7/28/99 -0400, Flanigan, Bill wrote:

>(or better yet, proactively resist the temptation
>swear--and digitally sign it--they have achieved interop)

Now figure out what that means for 2549, Bill.  Steve, rightly pointed out
that the IETF/IESG have historically NOT defined what interop means; they
leave it to the vendors.

Now no cheating here.  We can't have everyone use the same ANS.1 parser
library.  Got to have 2 independent implementations of those (remember what
happened with AH and ESP with the RSA and Cylink libraries; actually it was
SHA1 and D-H).  We also cannot have everyone use same RSA algorithm library.  

Now put on a co-chair and/or AD hat.  How do you tell when a handful of
vendors come to you and say "we interop", that they did.  Or does any of
this really matter?

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

---

From: [email-masked]
Date: Fri, 30 Jul 1999 14:39:58 -0400

As someone who was at both of the workshops I can honestly say that
nightmare and dismal  do not accuratly describe the
results we have been seeing.  By the end of the second workshop most of the
participants were exchanging cert requests
and responses with most of the other participants. This was accomplished
with out having to make any changes from what is
in the current RFC.

Unfortunatly a poor choice of words has caused this discussion to turn from
a suggestion of a possible better way to
do things to a perceived roasting of CMP.

                              Mike

---

From: "Flanigan, Bill" <[email-masked]>
Date: Fri, 30 Jul 1999 15:03:16 -0400

Robert,

	Wow!  You have surfaced something I have long worried about, and I
bet a lot of other folks have also.  
	Are we sliding down the slippery ISO slope or are we already at the
bottom with em?!  *Interoperability* aggressively not defined; I-Ds
progressed to Proposed RFC with the hope that they might turn out to work in
an *interoperable environment*; implementers that say *trust us, it's
interoperable* so progress to Draft RFC, then to Standard; no formal peer
review of interoperability claims prior to standards-track advancement; no
formal, independent, third-party evaluation of interoperability claims prior
to standards-track advancement ... .  
	And, like you ask, does any of this matter?  But, Bob, it simply
MUST matter to someone.  Hmm, let me think now, there must be someone it
matters to, er...oh yes, I've got it:  it's the customer!

Bill

> ----------
> From: 	Robert Moskowitz[SMTP:[email-masked]]
> Sent: 	Friday, July 30, 1999 10:15 AM
> To: 	Flanigan, Bill; [email-masked]
[snip]

Steve, rightly pointed out
that the IETF/IESG have historically NOT defined what interop means; they
leave it to the vendors.

[snip]

> Now no cheating here.  
[snip]