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

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

smime.p7s
Description: S/MIME Cryptographic Signature