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

From: Russ Housley <[email-masked]>
Date: Wed, 27 Sep 2006 14:44:25 -0400

This message was posted in the PKIX WG mail list, but it is even more
important here ...

From: "Anders
Rundgren" <[email-masked]>

To: <[email-masked]>

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 28 Sep 2006 09:41:38 -0700

The x- issue has actually been fixed. There is no longer a need to use x- headers or mime types.
 
There is still a problem with the process though. One part of the process is designed around the proposition that standards describe working implementations, the other is predicated on the standards process being a gating function for deployment.
 
I would like to get an OID for prototyping a certificate extension. It would be better to get an IETF OID which would be vendor neutral but it looks like I will have to use one cut on the VeriSign arc.

The O'Riely nutshell series has effectively become the authoritative source for many IETF standards.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
	Sent: Wednesday, September 27, 2006 2:44 PM
	To: [email-masked]
	Subject: Fwd: The state of PKI-related MIME-type standards

	This message was posted in the PKIX WG mail list, but it is even more important here ...

		From: "Anders Rundgren" <[email-masked]>
		To: <[email-masked]>
		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.

		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

		 

		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.

		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