Re: Re: CRL verification problem

I'd agree, it's a problem, the CRL has an invalid signature. To quote
section 5.1.1.3 of RFC 5280

"The signatureValue field contains a digital signature computed upon the
ASN.1 DER encoded tbsCertList."

This means that if the field value is the default value it is left out
of the encoding used to calculate the signature, so any extension with a
value of FALSE should not have that value encoded in it when the
signature is calculated.

Please ask whoever is generating these CRLs to do it properly. There are
real security implications if this is not done correctly.

Thanks,

David

On 6/12/19 1:29 am, luizurias wrote:
> Hi!
>
> In RFC 5280, the syntax of Extension is defined as: 
> Extension  ::=  SEQUENCE  {
>      extnID      OBJECT IDENTIFIER,
>      critical    BOOLEAN DEFAULT FALSE,
>      extnValue   OCTET STRING
>                  -- contains the DER encoding of an ASN.1 value
>                  -- corresponding to the extension type identified
>                  -- by extnID
>      }
>
> That is, the boolean value encoded in SUN provider is the critical value. It
> seems that BouncyCastle is ignoring this attribute of Extension (probably
> because the value is the default value). But, doing that, the signature
> verification fails cause the hash calculated does not inclued theses
> booleans.
>
> I think it is a critical problem, any CRL that contains the critical value
> encoded in Extension will fail the cryptographic verification.
>
>
>
>
> --
> Sent from: http://bouncy-castle.1462172.n4.nabble.com/Bouncy-Castle-Dev-f1462173.html
>
>