This message was posted in the PKIX WG mail list, but it is even more
important here ...
From: "Anders
Rundgren" <anders(_dot_)rundgren(_at_)telia(_dot_)com>
To: <ietf-pkix(_at_)imc(_dot_)org>
Subject: The state of PKI-related MIME-type standards
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:
- Follow the standard as written
- Follow the established practice
- 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