[PATCH] MD2 for libgcrypt

[Stephan Mueller]

Am Montag 19 Juli 2010, um 19:38:30 schrieb Daniel Kahn Gillmor:
> On 07/16/2010 03:29 PM, Stephan Mueller wrote:
> > as the issue with the Verisign CA certificates would be solved with this
> > patch and considering that the Verisign CAs are used pervasively, may I
> > ask whether it is possible to add the Verisign CAs to com-certs.pem?
> 
> are you talking about certificates for the verisign root(s)?  or are you
> talking about intermediate verisign CA certificate?
> 
> If it's the former, the digest used shouldn't matter -- what matters is
> the public key material and any internal constraints set (e.g.
> expiration dates).  Validating a self-signature (esp. one with a
> known-weak digest) for a trusted root CA certificate is a basically
> meaningless operation.

Both, there is the root cert (and I concur with your assessment), but there 
are also intermediate certs with MD2 too.

The problem with any of these MD2 certs is that you cannot do a gpgsm --import 
because gpgsm simply rejects them due to the MD2 hash. And during the import, 
the hash is also validated. So, unless you want to break gpgsm (a bad thing to 
do), you have no choice but to implement MD2 to allow these certs to be 
imported.
> 
> > However, I have one question: as far as I understand, the list in
> > com-certs.pem are used as trusted certificates, not needing to reference
> > them in trustlist.txt. However, the Verisign CA certs all need the
> > "relax" flag as otherwise the CA cert is not accepted by gpgsm.
> 
> If there are specific warnings that come up in this use case with
> Verisign CA certs, we should address those warnings as specific bugs
> themselves unrelated to the MD2 implementation (or lack thereof).

The issue is that the CA certs and intermediate certs are simply broken, look 
for yourself:

$ gpgsm --dump-keys 77AF556F
/home/sm/.gnupg/pubring.kbx
---------------------------
           ID: 0x77AF556F
          S/N: 00CDBA7F56F0DFE4BC54FE22ACB372AA55
       Issuer: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, 
Inc.,C=US
      Subject: OU=Class 1 Public Primary Certification Authority,O=VeriSign\, 
Inc.,C=US
     sha1_fpr: 90:AE:A2:69:85:FF:14:80:4C:43:49:52:EC:E9:60:84:77:AF:55:6F
      md5_fpr: 97:60:E8:57:5F:D3:50:47:E5:43:0C:94:36:8A:B0:62
       certid: 
3D1AC4939E5BD1DA69D13DE8F33E9E28F9989FD6.00CDBA7F56F0DFE4BC54FE22ACB372AA55
      keygrip: 5728C8A3DE5C45305F78A6B108CBCDEB6A3D2B29
    notBefore: 1996-01-29 00:00:00
     notAfter: 2028-08-01 23:59:59
     hashAlgo: 1.2.840.113549.1.1.2 (md2WithRSAEncryption)
      keyType: 1024 bit RSA
    subjKeyId: [none]
    authKeyId: [none]
     keyUsage: [none]
  extKeyUsage: [none]
     policies: [none]
  chainLength: [none]
        crlDP: [none]
     authInfo: [none]
     subjInfo: [none]


You see, there is no key usage or such.
> 
> I'm not arguing for discarding the offered MD2 patch (this functionality
> would be good to have available), but i don't think it's relevant in the
> scenario you're describing (at least as i understand it).

Well, Werner already told me that he is not integrating the patches. However, 
as the patches only enable the signature verification of an already existing 
signature, I cannot fully understand the decision.
> 
> Are there specific bugs related to the use of verisign root CA certs?

Not in gpgsm, only with the certs themselves.

Ciao
Stephan
> 
> Regards,
> 
> 	--dkg