Re: [pkix] Signature Verification and DER requirements

[Jeffrey Walton <[e-mail]>]

Hi Erik,

> Jeff write that you could reject a cert because it is non-DER encoded. How
> do detect that without analysing the cert in details. If you do minimum
> processing, you will just discover the signature validation failed.

If I was implementing this, here's how I would approach it:

  (1) verify the signature on the certificate without "deeply" parsing
the certificate.
  (2) accept BER/CER/DER because they are just presentation formats

I can get away with (1) because I already know the signer and the
signer's key. I don't use the browser/internet security model, and I
don't need to go rummaging around for signers and keys.

Many others can get away without rummaging for signers and keys, too.
A well configured server sends the certificates required for a chain
in a particular order. They do that to avoid the "which directory"
problem. So the answers are often at your fingertips without the need
to go hunting for signers and keys.

For (2), BER/CER/DER is just a presentation format. It adds nothing to
the security goals, and it takes nothing away from the security goals.
The best I can tell, its useless criteria because it has 0 impact on
security.

For what its worth, I would reject an end-entity certificate if a
server did *not* send the proper chain. We often need the chain to
avoid the "which directory" and the "deep parsing" problems. To me,
that's a valid reason to reject because it affects our ability to
verify a signature, which is completely security related.

Jeff

On Sat, May 16, 2015 at 3:15 AM, Erik Andersen <[e-mail]> wrote:
> It appears for me that the Japanese comment should be rejected. I will bring
> that up on our own list, as that is the decision making list for X.509.
>
> The Japanese comment implies (as I read it), as you do not whether a
> received cert is DER or non-DER encoded, you need to decode it and encode it
> in DER before checking the signature. In a constrained environment this
> seems an unnecessary burden to put on an RP.
>
> Jeff write that you could reject a cert because it is non-DER encoded. How
> do detect that without analysing the cert in details. If you do minimum
> processing, you will just discover the signature validation failed.
>
> I brought the issue up on this list due to the level of expertise on this
> list and because a thread was going on this issue.
>
> Kind regards,
>
> Erik
>
> -----Oprindelig meddelelse-----
> Fra: Santosh Chokhani [mailto:[e-mail]]
> Sendt: 15 May 2015 22:45
> Til: [e-mail]; Erik Andersen
> Cc: IETF PKIX
> Emne: RE: [pkix] Signature Verification and DER requirements
>
> +1
>
> -----Original Message-----
> From: pkix [mailto:[e-mail]] On Behalf Of Jeffrey Walton
> Sent: Friday, May 15, 2015 3:40 PM
> To: Erik Andersen
> Cc: IETF PKIX
> Subject: Re: [pkix] Signature Verification and DER requirements
>
> On Fri, May 15, 2015 at 10:12 AM, Erik Andersen <[e-mail]> wrote:
>> As Peter states. It is confusing, and I am not sure how to get it right.
>>
>> ...
>> I am interested in comments.
>>
> Maybe the easiest course is to side-step the issue altogether. The issue
> here is verification, so focus on it.
>
> Leave things the way they are related to encoding the certificate and
> signing the certificate (or more correctly, tbsCertificate).
>
> Then be explicit about how to verify it. That is, explicitly state bits
> should be verified as they are received; and they should not be rearranged
> to comply with anything because that will usually (always?) invalidate the
> signature.
>
> Allowing the bits to be rearranged during verification just seems wrong. It
> effectively creates a potential for a DoS when there's no need for one to
> exist. The security goals were met earlier, when the identity was bound to
> the public key.
>
> I also think you should give an implementation a choice during
> verification: they can choose to reject a non-DER encoded certificate
> because that's how things are written. But they should reject for the proper
> reason: reject because its no-DER encoded; and not becuase they re-arranged
> bits that caused a signature failure.
>
> Allowing a receiver to rearrange bits and then claim the signature
> verification failed is just plain wrong. They may as well have performed
> 'certificate[0] XOR 0x01' and claimed the certificate was tampered. There's
> no difference.