Re: [ietf-dkim] SSP - Sender Signing [Policy | Practice | Profile] or DSP - Domain Signature Profile

Hector Santos wrote: - Original Message - From: "Jim Fenton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Hector wrote: If there is going to be a SSP renaming consideration, may I suggest "Profile" instead of Practice?

Re: [ietf-dkim] 1193 considered harmful

Barry Leiba wrote: How does this address my concern? This looks like my current receiver would fail with the new signature format. That's not backward compatable. All verifiers already have to change, to support SHA-256. But that still doesn't address my concern. It's not backward compatib

Re: [ietf-dkim] 1193 considered harmful

How does this address my concern? This looks like my current receiver would fail with the new signature format. That's not backward compatable. All verifiers already have to change, to support SHA-256. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.researc

Re: [ietf-dkim] Splitting the DKIM base doc

Stephen Farrell wrote: Barry Leiba wrote: Dave brought up, at the Monday DKIM IETF session, the idea of splitting out the key-discovery parts from the base document. I've recently come up with a need to have the canonicalization be separately referenced. I'm throwing this out to the mailing

Re: [ietf-dkim] 1193 considered harmful

Barry Leiba wrote: I have a suggestion that I think might (ha!) satisfy everyone. That is, I THINK it will satisfy those who want the separate body hash, it will address Mike's compatibility concern, and it will not give Mark hives because of overloaded tags and burgeoning combinatorics. Su

Re: [ietf-dkim] 1193 considered harmful

Ooops, sorry about that last send. Barry Leiba wrote: I have a suggestion that I think might (ha!) satisfy everyone. That is, I THINK it will satisfy those who want the separate body hash, it will address Mike's compatibility concern, and it will not give Mark hives because of overloaded tag

Re: [ietf-dkim] Splitting the DKIM base doc

Barry Leiba wrote: I think the work of splitting it will be small, and won't affect the schedule, Given what Eric said he planned to do, with respect to the base document's discussion and reference to the key service, I agree. If I understood correctly the change he is planning will a) co

[ietf-dkim] New issue: optional exponent needed or not?

Folks, I believe that our current key selector only allows/defines how to include an RSA modulus since everyone basically uses 65537 as the public exponent. I guess there's a very, very sight possibility that sometime in the future a fixed public exponent could become a problem that could be fi

Re: [ietf-dkim] Splitting the DKIM base doc

The next milestone should be WG last call on base in May, so if your suggestion is likely to cause that date to slip, I guess it'd be good to include a justification for that. Good point, of course. Dave and I babbled briefly at each other about this recently, and I think a split makes sense -

Re: [ietf-dkim] 1193 considered harmful

At 6:54 PM -0500 3/24/06, Barry Leiba wrote: Section x.y: Backward compatibility with the pre-standard version Earlier, pre-standard implementations of DKIM used a different hash mechanism. Owing to significant deployment of that mechanism for early adoption and experimentation/refinement lea

[ietf-dkim] Going to a single hash algorithm

At 6:54 PM -0500 3/24/06, Barry Leiba wrote: Suppose the base doc said this sort of thing: - ... signers MUST use a=rsa-sha256 ... . . . This is a *very* bad idea. SHA-256 has been around for a relatively short period of time. It has dif

Re: [ietf-dkim] Splitting the DKIM base doc

Barry Leiba wrote: Dave brought up, at the Monday DKIM IETF session, the idea of splitting out the key-discovery parts from the base document. I've recently come up with a need to have the canonicalization be separately referenced. I'm throwing this out to the mailing list for discussion: Go

Re: [ietf-dkim] Splitting the DKIM base doc

Should we split the DKIM base doc into independent modules? I believe Dave has a specific idea that he might share with us... Dave? I'm working on a proposal. Couple of items ahead, in my queue. Soon. d/ -- Dave Crocker Brandenburg InternetWorking ___

Re: [ietf-dkim] SSP - Sender Signing [Policy | Practice | Profile] or DSP - Domain Signature Profile

- Original Message - From: "Jim Fenton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> >>> Hector wrote: >>> If there is going to be a SSP renaming consideration, may >>> I suggest "Profile" instead of Practice? >> Arvel wrote: >> Another possibility is "Preferences" maybe? > I'd prefer a

Re: [ietf-dkim] 1193 considered harmful

Barry, At first I thought your backward compatibility (BC) proposal would be a compromise but I changed my mind based on proven history where BC considerations caused more harm and got us to the point we are today. If DKIM was a standard today and widely adopted, I can understand the BC concern.