Subject: The state of PKI-related MIME-type standards

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 27 Sep 2006 00:18:26 +0200

Since I (who probably spends a magnitude or two more time on RFCs than most engineers do), had never heard about PKI-specific MIME-type RFCs like 2585 and 2797, I decided taking a peek at reality again.

That was yet another not a partiularly nice experience.  Apparently the IETF has an RFC marketing issue.  Or as I would put it: 
The current RFC system does not help implementers to find out what is standard and what is not.
A consequence of this dated and unwieldy system is that making add-on RFCs, often becomes a waste of time, which the following illustrates.

User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0

Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080207080308000503090606"
--------------ms080207080308000503090606
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII2jCC
BGkwggNRoAMCAQICAh3jMA0GCSqGSIb3DQEBBAUAMHcxEzARBgoJkiaJk/IsZAEZFgNlZHUx

X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Content-Type: application/x-pkcs7-signature;
 name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKLTCCA1Aw
ggI4oAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwOjELMAkGA1UEBhMCVVMxFDASBgNVBAoTC2V4YW1w

Not mentioning the "x-" MIME-extensions in 3280bis and other PKI standards under revision, would IMO be a mistake since these [unfortunately or not] represent the market's perception of the actual standards based on the simple logic: "if the big guys do like this then it must be right".  Looking for RFCs saying that they are wrong seems like a unusual value proposition. One ,might deprecate certain variances but I would not recommend this unless there is a real problem in the making.

Anyway, as an implementer you have three choices:
  1.. Follow the standard as written 
  2.. Follow the established practice 
  3.. Support the two variants forever
Only a very inexperienced person would settle for alternative #1.  Due to the Darwinian effect, the "wrong" scheme will probably not die until the whole application is gone.  There is nothing we can do about that when there is no difference in functionality between the wrong and right schemes. 

Regarding "right" schemes, it appears that the IANA process is incompatible with the development situation since you cannot get a name without having an RFC and then your development gets stuck in a process you have no control over.  Due to this you must "begin" with an x- extension that (if your stuff is successful), will be impossible to replace since you have no control of the other implementations.  And there you is ;-|

Anders

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Sep 2006 10:00:30 -0400

At 12:18 AM +0200 9/27/06, Anders Rundgren wrote:
>Since I (who probably spends a magnitude or two more time on RFCs 
>than most engineers do), had never heard about 
>PKI-specific MIME-type RFCs like 2585 and 2797, I decided taking a 
>peek at reality again.
>
>That was yet another not a partiularly nice experience.  Apparently 
>the IETF has an RFC marketing issue.  Or as I would put it:

Your wording here belies a fundamental misunderstanding of what the 
IETF does. We are not in the business of discovering what a vendor 
has done and publishing that as an Internet standard, although we do 
allow a vendor to publish an Informational RFC describing what it has 
done, IF the vendor has not done something that conflicts with an 
extant IETF standard.  The IETF is a forum for vendors and others to 
come together to develop standards, which vendors may then choose to 
follow, or not.

>Not mentioning the "x-" MIME-extensions in 3280bis and other PKI 
>standards under revision, would IMO be a mistake since these 
>[unfortunately or not] represent the market's perception of the 
>actual standards based on the simple logic: "if the big guys do like 
>this then it must be right". 

More properly, if the "big guys do this then I need to do this to 
interoperate with them." Right and wrong never enters into the 
discussion :-) but it does enter into our decisions on what to 
incorporate in IETF standards.

>Looking for RFCs saying that they are wrong seems like a unusual 
>value proposition. One ,might deprecate certain variances but I 
>would not recommend this unless there is a real problem in the 
>making.
>
>1.	Follow the standard as written
>2.	Follow the established practice
>3.	Support the two variants forever
>
>Only a very inexperienced person would settle for alternative #1. 
>Due to the Darwinian effect, the "wrong" scheme will probably not 
>die until the whole application is gone.  There is nothing we can do 
>about that when there is no difference in functionality between the 
>wrong and right schemes.
>
>Regarding "right" schemes, it appears that the IANA process is 
>incompatible with the development situation since you cannot get a 
>name without having an RFC and then your development gets stuck in a 
>process you have no control over.  Due to this you must "begin" with 
>an x- extension that (if your stuff is successful), will be 
>impossible to replace since you have no control of the other 
>implementations.  And there you is ;-|

I suggest you take this up on the IETF mailing list, since your 
complaint is about IETF processes as a whole and the RFC process in 
general, even though you have chosen to use PKI-specific examples.

Steve