I now call this the "Munich doctrine". It joins the "Danvers doctrine",
was the decision to refuse to cater to export requirements in regards to
security issues in IETF protocols. Neither of these are written down in an
as far as I know, but both are very real nevertheless.
OK. A slight point of clarification: encumbered algorithms as a MUST
should not be permitted if there are alternatives, presumably. MAY or
SHOULD is ok?
I don't think there's any problem with SHOULD and I cannot see how there would
be any problem with MAY.
The DNSsec people have taken this to heart, that's for sure. They have made
arrangements with RSADSI for royalty free use of RSA in the DNS.
I doubt this is a possibility with RSA.)
Ah. I don't understand your last "possibility with RSA" unless you mean
"possibility with Open PGP."
My mistake. I meant to say "Open PGP", just as you interpreted it.
Yes, RSADSI are most unlikely to give this forum that license, given the
opposing standard. I wonder if IETF would take that to heart and insist
that if RSADSI were to give royalty-free license to S/MIME, they should
also give it to competitors? Probably, if the algorithm is to be useful
in an unencumbered way, then this must be the case!
Actually what seems to be happening is that S/MIME will be changed to use
unemcumbered algorithms and only those algorithms will be MUSTs in the
standard. (If I were in RSADSI's shoes I wouldn't do this, but then again your
point about there being an issue if they did a special deal for S/MIME and not
for PGP is well taken.)
This then means that there will be no less than four S/MIMEs:
(1) The original RSADSI S/MIME.
(2) The one that's coming out as a set of informational RFCs.
(3) The one the WG will standardize.
(4) The one that will result from the PKCS rewrite that RSADSI is supposedly
Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of
compatibility between all of them -- I wouldn't know about that. But let's hope
that we don't have quite so many PGPs...
But, yes, I see this as unlikely.
Mind you, I'm not especially happy about any of this. I'm describing the
situation as I see it, not endorsing it. I understand the reasons the IESG and
the IETF have taken this course of action, but I sure wish it could have been
In case anyone cares, I trace all this back to the last iteration of the POISED
process (this is where the IETF develops its procedural and process
requirements). The IETF used to have a rule that basically said you had to make
a good case for using encumbered technologies, especially if unencumbered
alternatives were available. However, this rule caused some trouble in cases
where there encumbered technology existed that was believed by some to be
clearly superior to unemcumbered alternatives. The long and short of it is that
the rule was changed so that use of encumbered technology couldn't be an issue.
(I objected at the time but was overruled.) But this, if anything, proved to be
a worse situation, and now the pendulum has swung to the opposite extreme.
I think it would be better all around to avoid these extremes, even if that
meant not reaching closure on some of the things that caused the initial
swing, but that's just my personal opinion on the matter.
I now take it as a given that requiring encumbered technologies when
alternatives exist is a nonstarter in the IETF.
That leaves me with the sad feeling that the Open PGP standard will
suffer from slow takeup outside the US. I guess that's the lookout that
this forum has accepted from the start.
Pretty much. I think the problem exists in part because of the encumbered
technology situation and in part because of the export restriction situation,
but picking apart the causal relationships doesn't change the situation
( It would appear that the IESG assumes that encumbered within the US is
equivalent to encumbered within the IESG, whereas encumbered within
France is not. I also agree with these Internet politics :-)
I think the view is that given that the situation in France (and elsewhere)
won't admit any reasonable solution, it might as well be ignored.
On a related issue, that of an unencumbered reference implementation. I
have heard it said that this was required. Is this the case, as it
would seem to be in your careful use of the word "technologies" above?
There is no such requirement as far as I know. However, as a practical matter
protocols for which unencumbered implementations are available tend to do
better in the long run.
Back in the days when MIME was developed we took steps to make very sure that
two unemcumbered implementations were available almost immediately. I think
this helped immensely in winning acceptance for MIME. By contrast, unemcumbered
implementations of PEM and MOSS weren't possible, and speaking as someone who
would have cheerfully shipped product including such things if they were
available (and for that matter would have been willing to accept reasonable
licensing terms), I think this contributed significantly to the failure of
And if so, was pgp5.0 proposed and accepted as the reference
implementation at the Munich BOF?
Not that I'm aware of. In fact I know of no formal process for designating a
"reference implementation", other than possibly citing the existance of such a
thing in an RFC.
Again, on the practical front I'm a strong supporter of unencumbered reference
implementations regardless of what the process says (or doesn't say) about
them. In fact in the SASL API work that Innosoft is contributing to we've gone
so far as to include unencumbered source code for a reference implementation in
the specification itself. (Of course this isn't practical for Open PGP given
its size and complexity.)