Michael Sierchio wrote:
>
> Dr S N Henson wrote:
>
> > Then we'd obviously need an alternative parameter generation algorithm.
> > The X9.42 version (also in RFC2631) would be usable (though better ones
> > exist) except no test vectors exist which aren't obviously broken. I've
> > never found anyone else who's implemented the X9.42 parameter algorithm
> > other than the restricted case which is FIPS 186-1 compatible (i.e.
> > q=160 bits).
>
> I haven't implemented it, but this is also covered in RFC 2875
>
Well if someone ever does implement it and it agrees with my test
version then I'll be able to include it in OpenSSL. If that doesn't
happen there's are various other techniques which could be used or the
X9.42 seed data could be omitted since it isn't considered reliable.
> > DH-POP is indeed a problem. There's a standard again but its a bit messy
> > to implement in that it forces handling of DH certificate requests as a
> > special case.
>
> Right, because the CA will need a cert dedicated to the key agreement.
> Certs should be signed with RSA, it just makes verification a lot
> easier.
>
Yes thats one problem: you need to have a command line option to create
the CA cert without signing a corresponding request. Also the algorithms
for DH POP depend on various request fields in the request and need
additional DH specific steps.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
