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

[[e-mail] (Martin Rex)]

Yoav Nir wrote:
> 
>> Martin Rex <[e-mail]> wrote:
>> 
>> Yoav Nir wrote:
>>> 
>>>> 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.

Yes.  So what?  When you use the AIA OCSP or CRLDP information
from a certificate during certificate path validation, you do this only
after you have verified the CA signature on the certificate, which confirms
that the CA placed this information in the certificate.

Whether the entity who controls the private key is really the one who
the CA thought he was or whom the Subject/SAN identifies, is not yet
relevant.


>
> 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. 

Correct.  but the issues that you listed do not make the OCSP responder
location and CRLDP info within that certificate untrustworthy.


In case that you wonder what happens if a CA is more throughly compromised,
i.e. that someone manages not only to get certs mis-issued under a false
identity, but also with arbitrary attributes in them -- well, this is
something that the folks who invented X.509 claimed that it can not
possibly happen, because they did not design their approach to distribute
the CRL&OCSP distribution info to account for this (or they would have had
to distribute this information through the CA certificate rather than
through the end-entity certificate.

If you have or suspect that kind of CA breach (e.g. DigiNotar), then your
only course of action is to immediately and completely nuke the entire PKI
(i.e. revoke the CA certificate, respond to all issuer&serial requests
for that issuer to your OCSP responder with "revoked".


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

I believe the enumeration to be an _ordered_ list, because it uses
numbers rather than bullets.  I realize that there are folks who have
issues with doing stuff properly "in order".


Now there is one obvious defect in that list/order.
item number (4) should really be number (1).  This is not
a security issue to do (4) last rather than first, but it is
an obvious usability issue to anyone with experience in customer
support.

In the wild, you will often find cause that are non-malicious
why an out-of-order certificate chain finds its way into the
Basic Path Validation function.  I assume that the weird TLS servers
that Ryan is setting up send their bogus heaps of certs with non-malicious
intent.

If that happens for the below ordering of operations

 - you needlessly waste lots of CPU cycles in a asymmetric crypto operation
   that will predictably fail

 - you will typically get an error that says "digital signature verification
   failure", because a digital signature verification fails here.

 - this failure will typically preempt all further checking, and the
   fact that working_issuer_name differs from the issuer of the current cert
   may get totally lost.

When doing customer support, it is vital to know that a certificate path
validation failure happend because the peer sent junk instead of a well-formed
certification path in the TLS Certificate handshake message, and that
the digital signature verification failure is not a data corruption or
attack.

> 
>> 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