Russ,
No harm done. At the same time, I apologize if you or anyone else might
have taken my comments personally. I know that trying to align the work of
different standards groups is like trying to herd cats. Especially in the
case of ANSI and IETF. (In fact, my doctor said that I am only allowed to
resume standards work if I boost my medication. ;-)
Moving forward, I think we still need to revisit the RFC 2631 / X9.42
alignment issue. If a implementor claims to support "X9.42 Diffie-Hellman",
but has based their implementation on RFC 2631, no one is particularly well
served.
1) If X9.42 is not stable, then it is not a good foundation for derivative
IETF standards like it is now.
2) If X9.42 *is* stable (which I doubt purely based on experience), then RFC
2631 should probably look more like draft-ietf-smime-ecc-00.txt on. I.e., a
profile that does not duplicate or approximate the mathematical details of
the referenced draft standard. This is expecially true if it gives
attribution to X9.42. If close is good enough, then perhaps we just profile
IEEE P1363 and reference it as the base standard instead. P1363 can supply
all the bells and whistles in X9.42 except for the ASN.1 and test vectors.
This might also help avoid copyright infringement issues that might
reasonably argued with regards to RFC 2631 and X9.42.
3) I would like to continue this discussion but without continuing to copy
so many people and lists. I have already pruned out IPSEC. Please advise
whether this should just continue only within the S/Mime list or if it
affects all of the security groups as I believe it might.
Regards,
-John Kennedy
-----Original Message-----
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: Tuesday, November 23, 1999 6:18 AM
To: John C. Kennedy
Cc: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz;
ietf-pkix(_at_)imc(_dot_)org; ietf-smime(_at_)imc(_dot_)org;
ipsec(_at_)lists(_dot_)tislabs(_dot_)com; ekr(_at_)rtfm(_dot_)com;
robert(_dot_)zuccherato(_at_)entrust(_dot_)com;
djohnson(_at_)certicom(_dot_)com; wpolk(_at_)nist(_dot_)gov;
jis(_at_)mit(_dot_)edu;
mleech(_at_)nortelnetworks(_dot_)com; Elaine Barker; Sharon Keller; Simon
Blake-Wilson; Phil Griffin
Subject: RE: FIPS 186 and X9.42: One of these things is not like the
other
John:
At 12:57 PM 11/22/99 -0800, John C. Kennedy wrote:
1. With all due respect, saying that I have been "out of the loop" is not
quite correct. I have continued to track the output of both
X9F1 and IETF
with regards to X9.42 and DH for the last couple of years. I have copies
of X9.42 drafts up through February 1999. One does not have to
be "in the
loop" to see the inconsistencies I have pointed out.
2. The PKIX "son-of-2459" work, of which mostly only the ASN.1 portion of
X9.42 is relevant, is probably correct. What is a bigger problem is that
RFC 2631 (Diffie-Hellman Key Agreement Method) by Eric Rescorla
references
a 1998 draft. The related drafts,
<draft-ietf-smime-small-subgroup-02.txt>
and <draft-ietf-pkix-dhpop-02.txt>, reference RFC 2631. Is there proper
alignment in these works with the current state of X9.42? I don't think
so. How would the larger IETF community know if they were? Is ANSI
keeping all these authors "in the loop"?
3. FIPS 186-1 on DSA and rDSA is a good example. If the X9.42
specification had been kept as simple as FIPS 186 we wouldn't be where we
are now. It is unfortunate that crypto-politics and other machinations
did not allow NIST to handle this work independent of ANSI from the
beginning.
1. I apologize. You certainly have not taken an active role in the IETF
or X9F1 for the last few years. I am glad to hear that you have kept
current. I would encourage you to become actively involved again.
2. Once the IETF adopted X9.42, I worked diligently with X9F1 to ensure
that none of the aspects of X9.42 that were adopted by the IETF were
changed. We made a final comparison of the X9.42 draft and RFC 2631 just
prior to publication of the RFC. I have commitment that the
parts of X9.42
that are included in RFC 2631 will not be changed unless a
security problem
is discovered. If a security problem is discovered, then the IETF will
want to update RFC 2631 anyway, so this is not a concern.
3. Agree.
Russ