> On Mar 29, 2017, at 2:54 PM, Ilari Liusvaara <[email protected]> wrote:
>
> On Wed, Mar 29, 2017 at 02:32:17PM -0500, Sean Leonard wrote:
>> Hello,
>>
>> Second of all, I see negative value in transmitting certificates in
>> the proposed “PEM Certificate Chain” format (Section 7.4.2., Section
>> 9.1). Again, I understand that some popular tools (i.e., OpenSSL)
>> dump out this format by default, but one command-line switch or
>> pipe can change it to a much better format. Don’t be lazy.
>
> AFAIK, the PEM format is intended for transporting the End-Entity
> and intermediate certificates at once, as incomplete chains are
> extremely common.
>
[…]
>
> TLS 1.2 has a MUST for ordering certificates.
Yes, TLS expects ordering. But this statement is inconsistent with the
statement above: “transporting the End-Entity and intermediate certificates at
once, as incomplete chains are extremely common.”
My point is that if you have a valid chain of 5 certificates:
SUBJECT
-> intermediate A
-> intermediate B
-> intermediate C
-> ROOT CA
The first statement, “incomplete chains are extremely common”, means that you
are expecting a transmission that is missing, e.g., intermediate B, therefore:
SUBJECT
intermediate A
intermediate C
ROOT CA
This example is not “ordered” according to TLS 1.2, because RFC 5246 says:
“Each following certificate MUST directly certify the one preceding it.”
My point is that even though {SUBJECT, A, C, ROOT} is in an order, it is not
TLS 1.2-ordered, therefore it is “unordered”. So, a receiver needs to deal with
this unordered situation under the current draft.
Unless ACME expects all senders to transmit TLS 1.2-ordered certificates in
this part of the protocol? If so, the text needs to say that, as in “MUST”, not
“SHOULD”.
>
> And nothing that doesn't build paths itself (and thus can fetch
> certiifcates itself) handles CMS/PKCS#7. This is way too much logic
> to expect from ACME client.
Too many double-negatives for me to parse. Please clarify, thanks.
>
>
> And handling unordered certificates is quite a bit of extra attack
> surface. I took not just one but two vulns on that (one being auth
> bypass, which barring type safety bugs are just about the worst that
> can happen).
If you are saying that the receiver is only expected to handle TLS 1.2-ordered
certificates: “Each following certificate MUST directly certify the one
preceding it” (MUST, not SHOULD) then we have a different situation and PKCS
#7/CMS certs-only may not be appropriate. But the text does not currently say
that, so I need clarification before suggesting a better data format for the
certificate chain.
Regards,
Sean
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme