Subject: old MDC discussions

From: Adam Back <[email-masked]>
Date: Fri, 23 Apr 1999 01:49:10 +0100

The old discussions, should anyone wish to review them, can be found
by starting at the following links in sequence:

http://www.imc.org/ietf-open-pgp/mail-archive/msg01746.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01748.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01754.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01756.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01757.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01758.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01763.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01770.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01771.html

From msg01771.html particularly, we have a description of the same
proposal that was made recently, and Jon proposing _not_ reserving
explicit packet IDs for it as requested in a message a few previous.

Jon:
>   Adam Back:
>
>    I didn't suggest that MDCs go into 1.0 in the last round.  What I
>    suggested was that the following be verified:
>    
>         that when processing a message containing signatures a 1.0
>         implementation MUST continue to emit plaintext (ie fail
>         gracefully) in the presence of signature algorithms it does
>         not recognise.
>    
>    this readily allows adding MDCs or other signature algorithms in
>    version 1.1, and ensures backwards compatibility is possible.
>    
> Sure, but I don't think we need to add anything. If someone writes an
> implementation that (for instance) bus errors when it receives an algorithm
> encrypted with AES (which I pick because we all know it's going to go in,
> but it isn't there now), then the implementation is clearly broken. 
> 
> Signatures are different because there's a meaningful thing to do -- emit
> plaintext, and shrug over the sig -- which is a little different than the
> crypto, or compression, or whatever. But nonetheless, there are many
> failure and partial failure conditions, and an implementation that doesn't
> fail gracefully is broken.
> 
> This spec isn't a how-to-program manual, it's a format specification. By
> necessity it tells you a lot of what to do with the format, but there's a
> lot that this document can't tell an implementor.
> 
>         Jon

and some even older discussions:

http://www.imc.org/ietf-open-pgp/mail-archive/msg01112.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01113.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01115.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01117.html
http://www.imc.org/ietf-open-pgp/mail-archive/msg01114.html

Adam
-- 
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`