Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

[Yoav Nir <[e-mail]>]

> On May 12, 2015, at 11:51 PM, Martin Rex <[e-mail]> wrote:
> 
> Yoav Nir wrote:
> [ Charset UTF-8 unsupported, converting... ]
>> 
>>> 
>>> But a machine/automata/algorithm that will automatically download objects
>>> from URLs from still-untrusted data provided by the peer is definitely
>>> insecure and irresponsible.
>> 
>> In that sense, how is AIA different from revocation checking?
>> Whether you use CRLs or OCSP, you?re following a URL in the
>> (still untrusted or at least possibly revoked) certificate
>> to retrieve an object.
> 
> Possibly revoked?  yes.
> 
> Untrusted? *NO*.  Look at the algorithm in rfc5280 again.

In case a CA mis-issues a certificate, such as when giving someone who is decidedly not Microsoft a certificate for www.microsoft.com, what it should do is to revoke that certificate. That’s the only way to un-emit the certificate other than patch all relying parties. So as long as you haven’t checked revocation, the certificate is not only potentially revoked (someone stole my private key), it’s also potentially mis-issued. 

I think the section you quote below says that. You haven’t done path validation until you’ve checked revocation for every certificate.

> https://tools.ietf.org/html/rfc5280#section-6.1.3
> 
>   6.1.3. Basic Certificate Processing
> 
> 
>   The basic path processing actions to be performed for certificate i
>   (for all i in [1..n]) are listed below.
> 
>      (a)  Verify the basic certificate information.  The certificate
>           MUST satisfy each of the following:
> 
>         (1)  The signature on the certificate can be verified using
>              working_public_key_algorithm, the working_public_key, and
>              the working_public_key_parameters.
> 
>         (2)  The certificate validity period includes the current time.
> 
>         (3)  At the current time, the certificate is not revoked.  This
>              may be determined by obtaining the appropriate CRL
>              (Section 6.3), by status information, or by out-of-band
>              mechanisms.
> 
>         (4)  The certificate issuer name is the working_issuer_name.
> 
> 
> 
> -Martin