ietf-smime
[Top] [All Lists]

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

2008-12-31 13:34:45
How about adding an otherName to the SAN? You'd need an OID for random data though.

Or the CA could insert a method 4 UUID as a URI in the SAN. That's intentionally random. This might upset anyone wanting to use UUIDs as unique names, though (and these people do exist :).

Just thinking out loud.

-- Tim

Santosh Chokhani wrote:
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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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