Michael Sierchio wrote:
>
> There are considerable advantages in doing away with the subgroup
> nonsense if you're not doing DSS -- it can strengthen the key agreement
> against several forms of attack.
>
> For the hand-waving approach, the only difference in syntax is
> in subjectPublicKeyInfo --
>
> SubjectPublicKeyInfo ::= SEQUENCE {
> algorithm AlgorithmIdentifier,
> subjectPublicKey BIT STRING }
>
> AlgorithmIdentifier ::= SEQUENCE {
> algorithm OBJECT IDENTIFIER,
> parameters ANY DEFINED BY algorithm OPTIONAL }
>
> with the subjectPublicKey defined as the DER-encoding of the DH Public Key
> encoded as an INTEGER
>
> DHPublicKey ::= INTEGER
>
> and with
>
> AlgorithmIdentifier ::= SEQUENCE {
> algorithm OBJECT IDENTIFIER,
> SEQUENCE {
> prime INTEGER, -- p
> base INTEGER, -- g
> privateValueLength INTEGER OPTIONAL } }
>
> with the OBJECT IDENTIFIER value being dhKeyAgreement (1.2.840.113549.1.3.1)
OK that looks like standard PKCS#3 stuff which can be handled fairly
easily for just certificate support. Is a private key format defined as
well or is that up to the application? If the latter I'd follow the
PKCS#8 + PKCS#11 standard for DH.
>
> We could use DSA-type certs for DH if we remove the restriction
> that q be 160 bits. A larger q would be better for a number
> of reasons, and next-gen DSA certs should probably use SHA-256
> or SHA-512 anyway. The only challenge then would be to provide
> for DH-POP in Certificate Signing Requests. Sound reasonable?
> I think maybe I could bite off a chunk of this...
>
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).
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.
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]
