Re: [TLS] Certificate validation can of worms

[Santosh Chokhani <[e-mail]>]

Martin,

You are misreading this.  This is talking about things such as must be critical.  For example, 5280 requires some extensions to be critical.  Some of the path validation software was checking if the extension was marked critical or not and then was throwing an error if not marked critical.  There is no need for that.  CA has already produced an object.  The consumer understands the extension and should go ahead and process it.  CA having not set it critical does not and should not make a difference.

-----Original Message-----
From: Martin Rex [mailto:[e-mail]] 
Sent: Tuesday, April 08, 2014 4:42 PM
To: Santosh Chokhani
Cc: [e-mail]; Watson Ladd; [e-mail]
Subject: Re: [TLS] Certificate validation can of worms

Santosh Chokhani wrote:
> 
> The EKU is generally only applies to the leaf certificate (per X.509 
> and RFC 5280) and is not involved in path processing.
> I would think that if EKU is present at least a browser application 
> will ensure that the certificate has server auth OID.

There is one central statement in rfc5280/PKIX that you seem to be unaware of:

https://tools.ietf.org/html/rfc5280#section-6.1

   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.


Whit this  "this profile RECOMMENDS against including such checks"
says explicitly to an TLS implementor: you SHOULD NOT implement any conformance checks to stuff that is described in section 4 & 5 of this document.  (so you do not have to read, let alone understand what all the stuff in that part of the document means).



-Martin