On Wed, Oct 24, 2018 at 12:04 PM Kas <kas=40lightc....@dmarc.ietf.org> wrote:
> > > On 10/24/2018 8:44 PM, Albert ARIBAUD wrote: > > Hi, > > > > Le Wed, 24 Oct 2018 19:15:49 +0300 > > Kas <kas=40lightc....@dmarc.ietf.org> a écrit: > > > >> Wrong and you should not look at a certificate as a public key, > >> please educate yourself with deeper understanding what do extensions > >> serve and what critical extension means, i have a Code Signing > >> certificate can i use it for IIS ? it has a public key ! and it been > >> vouched by Comodo , do you understand what is CRL Distribution > >> Points(2.5.29.31) and how that certificate should be checked before > >> considered trusted ? > > As an observer to this discussion, I would like to point out that > > asking your interlocutor(s) what they know or do not know is rarely > > productive, as people are usually poor judges on how well they know > > some topic. Plus, even if the answer is accurate enough, it does not > > help the discussion progress to a fruitful conclusion -- all the more > > when the questions are asked in bursts. > > > > I would kindly advise you to just assume that others in the discussion > > know enough of the topic to understand a detailed technical argument, > > and to just lay out in such detail the concrete attack scenario(s) which > > you are envisioning and concrete proposal(s) for mitigation or > > protection. > > > > People on this list who do know the topic well enough will ask > > meaningful questions, which will help the discussion progress. People > > on this list who do not know the topic well enough may indeed ask > > questions which are irrelevant or suggest solutions which are > > inefficient, in which case you will be able to point out the concrete > > reason for the irrelevance or inefficiency, and again, discussion will > > progress toward a useful conclusion. > > > > Amicalement, > Hi Albert, > Thank you for clearing that for me, you are right and i was wrong with > such questions, in fact that paragraph was quoted with text from Alan > and i should knew better. > > > On 10/24/2018 8:30 PM, Eric Rescorla wrote: > > Kas, > > > > I've read through this entire thread, and TBH, I really don't > > understand what threat you are concerned with. > > > > Can you please describe the specific attack you have in mind? > > > > -Ekr > > > > Hi Eric, > > I am not talking about a threat or kind of attack per se, please let me > put the points i trying to convoy in short : > 1_ MitM is a threat, as there is no way for acme client to make sure he > is talking to the intended acme server not to an impersonator, according > to current draft of acme protocol you should : > I don't think I agree with this claim. The client's expectations about the intended server are set by its domain name and it verifies that it is talking to the server in question via the WebPKI. 2_ Depend on TLS layer to establish this trust and this will take us to > root certificates supplied to the client, here i am suggesting should be > avoided by implementing different approach as acme sever is de facto a > trusted CA server and should be handled as such, > I don't understand what this means. The client doesn't take its root certificates from the ACME server. In fact, in the most common use cases for ACME, issuance of WebPKI server certs, the server doesn't need to know anything about trust anchors at all (the ACME *client* does, but those are preinstalled and don't need to interact with the ACME server other than doing ordinary WebPKI validation). -Ekr 3_ Or consider adding to acme protocol a process to authenticate the > server to the client, this will prevent any threats, but will raise > different problem, the client should have the full chain to that > certificate in secure way and can validate and match the resource > directory url of acme server with specific root certificate to trust, > hence my suggestion to utilize dns to publish a key ( may the root > public key,CA's public key, a key intended to sign server response ... > something to authenticate the certificate and its acme server) > 4_ Acme has online and automated certificate revocation protocol which > is new, so any CA can already start to implement it even for different > type of certificates ( eg. Code Signing ), that is great but why stop > here and not add a process to supply the root and CA certificates > instead on depending what client has. > 5_ Acme editors know that along with most of you but choose to ignore > that and that is fine as those points can be interpreted as irrelevant > to this protocol but at the same time any expansion will not conflict > with any other protocol, hence the title "Please consider" take this as > petition to expand Acme for better internet. > > and thank you > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
