ietf-smime
[Top] [All Lists]

RE: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate

2008-12-31 13:12:39

Private EKU could cause problems if EKU is not otherwise present in the
certificate.

The certificate may not be usable for intended purpose.  Not all clients
may recognize "any key purpose" as intended by 5280.

-----Original Message-----
From: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org]
On Behalf Of Mike
Sent: Wednesday, December 31, 2008 12:50 PM
To: ietf-pkix(_at_)imc(_dot_)org
Cc: ietf-smime(_at_)imc(_dot_)org; cfrg(_at_)irtf(_dot_)org; 
saag(_at_)ietf(_dot_)org
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate


I sent my last message a bit too hastily.  Other ideas that I was
contemplating should have been mentioned including:

   - remove any unrecognized extensions
   - remove tumors

Those could potentially cause problems if for some reason they were
actually needed.  This one, though, shouldn't cause trouble:

   - add a private EKU with a random number (or two) in the OID

That would not mess up the serial number scheme in use or modify the
subject name as has been suggested.

Mike


I wrote:
There is a simple fix -- a CA can just reorder the extensions prior
to issuing a certificate.

Mike

<Prev in Thread] Current Thread [Next in Thread>