Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates

From: [email-masked] (Martin Rex)
Date: Tue, 14 May 2013 07:03:12 +0200 (CEST)

When I wrote my message below, I wasn't aware how exactly
the PKCS#v2.1 (rfc3447) RSASSA_PSS signature was defined,
instead I was vaguely remembering code fragments of what turned out
to be an early, unfinished PKCS#1 v2.1 draft 1 (1999) implementation.

I noticed the difference when I recently implemented rfc3447
(rfc3447 section 9.1 is the easy, rfc4055 section 3.1 is the hard part).

The optional "salt" OctetString from the PKCS#1v2.1draft1 version
of the RSASSA_PSS AlgId Parameters, are not present in the final
v2.1 RSASSA_PSS AlgId, that only contains a saltLength integer,
so there are just a few bits to play with.   On the one hand,
the salt being protected under the RSA encryption looks safer,
but on the other, a possibility for a CA to insert strong random
noise near the beginning of TBSCertificate would have been nice...

I'm sorry for the confusion.

-Martin

Martin Rex wrote on 17-Dec-2012:
> Santosh Chokhani wrote:
> >
> > Yes, except "active" is a red herring again.
> > If you are throwing in random meaningless extensions, RP is not going to
> > check them and hence active and passive is not a meaningless distinction.
> > 
> > The basic thing to understand is that the subject DN is the first input
> > from the user and it has potential for sufficient fidelity that unless
> > you put randomness before the subject DN, you are inviting trouble.
> 
> IMHO the thing to understand is that the composition, field ordering
> and fairly unlimited extensibility of X.509v3 is what enables
> a mere collision attack (with two distinct internal states) to
> achieve what would normally require a 2nd preimage attack.
> 
> Looking at TBSCertificate:
> 
> TBSCertificate  ::=  SEQUENCE  {
>      version         [0]  Version DEFAULT v1,
>      serialNumber         CertificateSerialNumber,
>      signature            AlgorithmIdentifier,
>      issuer               Name,
>      validity             Validity,
>      subject              Name,
>      subjectPublicKeyInfo SubjectPublicKeyInfo,
>      issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
>                           -- If present, version MUST be v2 or v3
>      subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
>                           -- If present, version MUST be v2 or v3
>      extensions      [3]  Extensions OPTIONAL
>                           -- If present, version MUST be v3 --  }
> 
> 
> maybe the AlgorithmIdententifier is finally not as useless as I
> thought.  If there was more support for RSA-PSS (aka PKCS#1 v2.1)
> signatures in the installed base, the CA would be able to sign
> the EE-Cert with a RSA-PSS AlgId that has a random, hash-sized salt
> in the signature AlgorithmIdentifier parameters field...
> 
> -Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 14 May 2013 13:28:26 +0000

You can always put randomness in serial number or in validity period.

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, May 14, 2013 1:03 AM
To: [email-masked]
Cc: Santosh Chokhani; Erwann Abalea; [email-masked]
Subject: Re: [pkix] Questioning the benefit of random serials over sequential ones in x.509 certificates

When I wrote my message below, I wasn't aware how exactly the PKCS#v2.1 (rfc3447) RSASSA_PSS signature was defined, instead I was vaguely remembering code fragments of what turned out to be an early, unfinished PKCS#1 v2.1 draft 1 (1999) implementation.

The optional "salt" OctetString from the PKCS#1v2.1draft1 version of the RSASSA_PSS AlgId Parameters, are not present in the final
v2.1 RSASSA_PSS AlgId, that only contains a saltLength integer,
so there are just a few bits to play with.   On the one hand,
the salt being protected under the RSA encryption looks safer, but on the other, a possibility for a CA to insert strong random noise near the beginning of TBSCertificate would have been nice...

-Martin

Martin Rex wrote on 17-Dec-2012:
> > If you are throwing in random meaningless extensions, RP is not 
> > going to check them and hence active and passive is not a meaningless distinction.
> > 
> > The basic thing to understand is that the subject DN is the first 
> > input from the user and it has potential for sufficient fidelity 
> > that unless you put randomness before the subject DN, you are inviting trouble.
> 
> and fairly unlimited extensibility of X.509v3 is what enables a mere 
> collision attack (with two distinct internal states) to achieve what 
> would normally require a 2nd preimage attack.
> 
> signatures in the installed base, the CA would be able to sign the 
> EE-Cert with a RSA-PSS AlgId that has a random, hash-sized salt in the 
> signature AlgorithmIdentifier parameters field...
> 
> -Martin