Re: [Acme] dns-01 challenge limitations
On 9/13/2020 12:13 PM, Simon Ser wrote: Ultimately, ACME clients need a way to update DNS records to solve the dns-01 challenge. Ignoring and pushing the problem down to the DNS operators does not fix the root cause. I can't agree more, so what about going after dns-02 challenge instead of trying to fix this ? (And this is up for discussion and as food for thought.) Lets say dns-02 challenge will be little different where the DNS record will hold a public key for specific(or per) domain/subdomain and ACME client will pass the server challenge by using the correspondent private key for that public key to pass the challenge from the server, where server will verify against the DNS published public key, means no DNS access from client side at the time of the challenge itself. This might solve the need for DNS API or even accessing the DNS from the client altogether, this will solve and simplify the challenge while do not compromise the security of the challenge itself and will not compromise the DNS records for the DNS administrators piece in mind, on contrary it will give the ability to control DNS handling on the client side in more secure way, and yet if a client have the ability to change the public key then this will revert to something very similar to dns-01, so in that case ( when it can access and modify the DNS records) client can choose between dns-01 and dns-02, which i don't see need any discussing more that dns-01 itself. Is such challenge viable and secure ? did i missed something obvious with such suggestion ? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] A single failed challenge should not invalidate an entire order
On 8/18/2020 11:16 PM, Matt Holt wrote: I propose that RFC 8555 §7.5.1 be revised to say, "The server is said to "finalize" the authorization when it has successfully completed one of the challenges or failed all of them." I join my voice to Matt's, but I have slightly different proposal: There is Sender Policy Framework (SPF) which works just fine as it for emails, a similar mechanism is my proposal, where DNS TXT record will declare and establish an ACME policy, what acme challenges should be the minimum acceptable by the ACME service to authorize, also it will define the maximum needed to authorize. Like the ability to declare what challenges is supported by the client (as a list or an array), and what is the minimum challenges must be passed, here for this minimum passed a simple number may be like 2, means two of the three supported challenges must be passed, also it can have a challenge(s) as a must, server must be guided by this rule as long that policy exist at the time of validation, and in absence of such policy it will act as currently does. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Please consider adding server authentication
On 10/25/2018 12:49 AM, Eric Rescorla wrote: I would say three things about this: 1. This has nothing to do with ACME, which is entirely about the interaction between the cert-holder and the CA. Speaking as AD (the rest of this message is as an individual) I can tell you that anything having to do with populating the client key store would be out of scope for ACME. Sure it is out of scope but supplying the chain as CA and root certificate doesn't conflict and will only secure the protocol, it is as i said you know better but adding the ability to obtain such small store from acme server is not bad practice. 2. I actually don't agree that it would be better to have the client trust anchor store updated via DNS, at least for one of the large well-managed clients (e.g., Firefox, Chrome, etc.) Because of the nature of the WebPKI, the question of whether a trust anchor is one that the client should trust is to a great extent a policy question. and the clients (or the operating systems that they are hosted on) operate root programs which evaluate those policy issues (for instance, determining whether a given CA should be distrusted). So, the relevant question is how that information gets communicated to the user's machine. There's no particular reason why the DNS is a good choice for that. DNS is running on different servers and will add extra layer of security, even letsencrypt as fully trusted ACME service provider by every store, if wanted to impersonate example.com and act as acme server running on example.com will fail unless it can control DNS records of that domain. 3. In the particular case of enterprise trust anchors (as opposed to preconfigured ones) there are already mechanisms for remotely managing machines, and so again. DNS is not a particularly good mechanism for this. DNS can be used to deliver a pair of encoded data one url and a hash to a certificate to establish secure connection and obtain the chain of acme server, or the store from acme server contain all the root and CA certificates being used by that ACME server, on other hand if only one RFC or protocol has defined such request or protocol, then there will be a chance to configure Windows to use the store provided by Mozilla. Every email been sent trigger DNS lookup to check DKIM and SPF and DNS servers doing amazing and fast job. I think you got my suggestion and i don't think there will be such a chance to standardize such protocols/functionality in near future if ACME passed on it, i mean something the online certificate revocation process, it is ready to be used. And i am not saying it should be DNS, i think you can figure well suited approach to enhance this protocol. That is it and thank you for your time ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Please consider adding server authentication
On 10/24/2018 11:33 PM, Eric Rescorla wrote: 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). Client doesn't take its root certificates from ACME server that is true, but when a client utilize ACME protocol to get a certificate from ACME server, this implies that this server is already CA trusted in the eyes of the client, and in both cases if the CA cert used by acme server to issue the certificate leads or not to a trusted root certificate on client side, the client want that certificate and want the full chain and has the power trust it or not, This is pretty hard to follow but If I'm understanding you correctly, then I don't think this is correct. There's just no connection at all between the trust anchors in the ACME client and the trust anchor associated with the CA part of the ACME server. Consider the case where I am operating an Enterprise CA for my own servers. This CA has a self-signed certificate X that needs to be installed in every Web client in my network. The CA itself runs ACME and has a certificate that's signed by a WebPKI valid anchor T. The ACME client component of my Web server connects to my own ACME server and has trust anchor T installed, and is therefore able to validate the ACME server's identity at the TLS level. However, because it does not have trust anchor X installed, the ACME server cannot issue a certificate which would be acceptable to the ACME client [0]. Contrariwise, my Web clients have trust anchor X (and likely T) installed, and so will accept certificates from both the ordinary WebPKI and from my Enterprise CA. You seem to have some concern about this, but I can't really figure out what it is. Given that a number of people have engaged with you and seem to also be confused, I would suggest that the problem is that you aren't being clear. I would suggest you draw a diagram of the various states, including the initial state, the state you would consider secure, and the state you are concerned about. -Ekr [0] Note that the ACME client might have a copy of X in order to validate the cert chain provided by the ACME server as a means of sanity checking but this has nothing to do with the TLS portion. You said "trust anchors in the ACME client and the trust anchor associated with the CA part of the ACME server" and in your example "This CA has a self-signed certificate X that needs to be installed in every Web client in my network." there is connection and there will always connection between those, There is no need for example as your example will do : My point is about "installed" from your example as word and as process, ACME is Automatic Certificate Management Environment and thus if this "installed" can be automated then it better be, and it can be supplied online without preinstalled certificates, all your clients can only need the DNS root key and utilize DNSSEC to obtain your X, please correct me if i am wrong, on top of that there is RFC 5011 "Automated Updates of DNS Security (DNSSEC) Trust Anchors" can update that key in secure way, and you can revoke your CA certificate and issue another one to ACME server and all your client will be updated automatically, so in my opinion using DNSSEC is way more secure than depending on client store. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Please consider adding server authentication
On 10/24/2018 10:13 PM, Salz, Rich wrote: I do not think the WG is ignoring you. Members of the WG have made significant efforts to make sure we understand you. We just disagree with you -- that's different. By ignore i meant the points 2 and 3 not me. On 10/24/2018 10:14 PM, Ilari Liusvaara wrote: AFAIK, the impersonator can not tamper with the requests undetected due to the request nonces, request signatures and key authorization including the key fingerprint. Such impersonator could still try to cause denial of service (including via feeding bogus certificate to the client) or try to attack the client (including escape sequence attacks and protocol implementation bugs). A well-made client should resist such attacks (other than brute denial of service which one can not do anything with). If you look at Let's Encrypt, they use a CDN, which is definitely not a trusted component (nor it can be)... MitM can be full acme server and and doesn't need to tamper with the requests on contrary he will act accordingly to this draft, acme client beyond establishing TLS handshake successfully had no idea to whom he is talking to, all what MitM needs is to intercept one DNS lookup and change it to his address and the attack is successful, of course the MitM can use a certificate issued by the real acme server, there is no way to distinguish a MitM acting server has letencrypt issued certificate from letsencrypt.com itself if both certificates has the same trusted root certificate. On Wed, Oct 24, 2018 at 12:04 PM Kas <mailto:40lightc@dmarc.ietf.org>> wrote: 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. Acme protocol doesn't mention anything about verifying domain name, if you mean when on TLS connection layer then my replay to Ilari applies here. 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). Client doesn't take its root certificates from ACME server that is true, but when a client utilize ACME protocol to get a certificate from ACME server, this implies that this server is already CA trusted in the eyes of the client, and in both cases if the CA cert used by acme server to issue the certificate leads or not to a trusted root certificate on client side, the client want that certificate and want the full chain and has the power trust it or not, hence my suggestion to pin something in DNS TXT record may be the hash of of the server certificates used to accept client connections but it should not be the root( my replay to Ilari explain this) or public key will be used in ACME protocol to sign or verify all or some of the steps requesting certificate, after all server demand to authenticate the client by verifying ownership of the domain, so i am suggesting to do the same to make acme server to proof itself as the owner of the acme server domain to the client (not the same way by passing a challenge of course), but pinning something critical to this issued certificate, after following such secure mechanism client can download the root and trust it, and there is nothing mentioned in the draft preventing ACME server from being a WebPKI provider if it is not root trusted by the client. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Please consider adding server authentication
On 10/24/2018 8:44 PM, Albert ARIBAUD wrote: Hi, Le Wed, 24 Oct 2018 19:15:49 +0300 Kas 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 : 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, 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
Re: [Acme] Please consider adding server authentication
On 10/24/2018 4:39 PM, Alan Doherty wrote: At 11:02 24/10/2018 Wednesday, Kas wrote: Certificate is not just a public key, it has extensions well defined and standardized in RFC's, please educate your self with them, how and when they should handled and what actions they might trigger, and remember this: implementation of such handling is something can't be controlled and let me list few facts : the functional part of a cert is just the public key ( all the rest and the extentions are just wrapping to give details of who else is vouching for it and what identities it is associated with) 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 ? 1_ OpenSSL heartbleed went undetected for almost 2 years. this had nothing to do with certs, all to do with the underlying encription implementation Vulnerabilities are everywhere and they are in implementations 2_ Hackers managed to jailbreak Apple iPhone by simply opening a pdf file ( handcrafted file with bad intentions) , imagine yourself opening a pdf file and losing the warranty of your phone .( though many people used that pdf intentionally ) again nothing to do with certs Certs are ASN.1 a data structure language and can be utilized to compromise a remote device, please search the web for "asn.1 vulnerability" every system and many software got hacked by using handcrafted certificate, in my example how a pdf (Portable Document Format) file compromised a system 3_ Many client software's like browsers or email clients like Thunderbird will add every CA certificate automatically to their store none will the entire point of the trusted root store is its involitility a user can add roots manually but 0 software will update its root store except by normal (to it) software update I said CA certificate not root certificate there is difference, CA's in most cases will be added automatically to the store as long the root in the store, and some will add it as not trusted without root but in many cases will be added ! ( their own store or the system store ) , MitM can issue CA certificate to a client which is in this case SMTP server and this server will use that certificate and help distribute this "compromised without losing the privatekey" certificate to everyone comes in contacting with that SMTP server. thats patently impossible, otherwise new CAs could just use this method to gain trustinstead of the current hoop jumping amd auditing they have to go through to get included in software root stores (why letsencrypt for example is signed by their own and other(extant in older sofware) roots till their own is widespread as software updates the signatures from other older CAs are needed (to ensure at least one of the root signitures is in potential clients root store) There is CA certificates providers and they are sell it, an attacker can get one from on by stealing the private key of one, it is not something impossible or didn't happen 4_ Keeping private key secret is a MUST, but this doesn't means you should trust the certificate from unknown sources, as they might be targeting your clients not you.( handcrafted with bad intentions) again as long as it passes my validation (signed by 1 or more widely trused roots) it is doing its job (passing and verifying my public key) Read about the case of DigiNotar 5_ What if a company like Samsung wanted to issue certificates to its devices to make the connections between phones and TV secure, and it don't want to ask Apple and Microsoft to add Samsung root certificate to theirs system store, then Samsung can't use acme protocol or it can ? it wouldnt prevent them at all or adding their own CAs root to the trusted roots on all future devices Right, now how to update or revoke those certificate and keep the devices working wouldn't be easier and safe that you bought a TV and the paper guide instruct you to put X.com (it has by default) in settings and apply the key YYY if that didn't work then visit X.com and get the updated key after that it will be automated process, now to access that device form you PC instead of accepting the root and install it ( or adding it to exclusion) you do the same use X and YY and i am here not pointing the monopoly in such addition but we are in 2018 and that root store should be more secure and obtained online from the source in secure way, should you accept and install such root certificate manually from every device or simply go to Samsung site and import the their root and store and you are good to go with all their dev
Re: [Acme] Please consider adding server authentication
Certificate is not just a public key, it has extensions well defined and standardized in RFC's, please educate your self with them, how and when they should handled and what actions they might trigger, and remember this: implementation of such handling is something can't be controlled and let me list few facts : 1_ OpenSSL heartbleed went undetected for almost 2 years. 2_ Hackers managed to jailbreak Apple iPhone by simply opening a pdf file ( handcrafted file with bad intentions) , imagine yourself opening a pdf file and losing the warranty of your phone .( though many people used that pdf intentionally ) 3_ Many client software's like browsers or email clients like Thunderbird will add every CA certificate automatically to their store ( their own store or the system store ) , MitM can issue CA certificate to a client which is in this case SMTP server and this server will use that certificate and help distribute this "compromised without losing the privatekey" certificate to everyone comes in contacting with that SMTP server. 4_ Keeping private key secret is a MUST, but this doesn't means you should trust the certificate from unknown sources, as they might be targeting your clients not you.( handcrafted with bad intentions) 5_ What if a company like Samsung wanted to issue certificates to its devices to make the connections between phones and TV secure, and it don't want to ask Apple and Microsoft to add Samsung root certificate to theirs system store, then Samsung can't use acme protocol or it can ? and i am here not pointing the monopoly in such addition but we are in 2018 and that root store should be more secure and obtained online from the source in secure way, should you accept and install such root certificate manually from every device or simply go to Samsung site and import the their root and store and you are good to go with all their devices, is that doable ? is that practical and safer for the average user of the internet ? The question is so simple if A asked B for certificate how A can be sure there is no M in the middle issued the certificate ? if the answer by depending on TLS layer then that is not a solution, as all will come to validates a root self-signed certificate, so that question will become how A obtain the root certificate from B to validates the issued certificate ? This draft can ignore this issue, and that is OK, but it can do better and resolve what really needs resolving the root issue, and help internet become more safe and secure, not for this specific protocol but as a seed for other protocols to follow, how many RFC's been used by this draft and how many in the future will depends on this draft ( soon to be RFC). That been said ,and i really don't want to discuss attacks because it is useless and endless discussion, so please Alan first forgive my English (may be i wasn't clear) and pretty please don't steer the this thread/subject away from its topic. Best reagrds, K. Obaideen On 10/24/2018 2:13 AM, Alan Doherty wrote: At 18:14 23/10/2018 Tuesday, Kas wrote: Can MitM impersonate acme server and walk the client through the whole process and issue a certificate to the client ? yes it can. If your understanding to 'compromised' certificate is leaked private key, then this certificate is not 'compromised', only MitM issued it for his own intentions and the last thing he care about is making the client secure or any party will connect to that client. Right ? Client ask acme server for a certificate and get a certificate issued by MitM not the real and right acme server, do you consider such certificate 'compromised' or not ? (while private key is still secret) if the cert is usable then it is no more/less secure than the one from the CA direct (the cert being a signature from a widely trusted CA verifying the public key the client provided, is authentically from the client) if the cert is unuasable (untrusted) the client/user/etc can detect this What if this MitM issued certificate and supplied a chain to self-signed certificate to the false ( compromised without leaking private key but issued for bad intentions ) certificate , then client should validate the chain, that is easy and understandable, when reaching to that self-signed certificate how to trust it ? ?? i think you again miss what a cert is and how x509 works issued for bad intentions? the acme-client is the only one who can use the cert (as the only one with the private key) the CA has no input or control over the use of the cert (so their intent affects nothing) by design only public information is transmitted between the acme-client and acme-server How to authenticate acme-server ? no need and how to authenticate such server in cloud based service lets say acme server is using service like CloudFlare ? again no need an acme client gives not one jot of care about if they are talking to their CA or ano
Re: [Acme] Please consider adding server authentication
Can MitM impersonate acme server and walk the client through the whole process and issue a certificate to the client ? yes it can. If your understanding to 'compromised' certificate is leaked private key, then this certificate is not 'compromised', only MitM issued it for his own intentions and the last thing he care about is making the client secure or any party will connect to that client. Right ? Client ask acme server for a certificate and get a certificate issued by MitM not the real and right acme server, do you consider such certificate 'compromised' or not ? (while private key is still secret) What if this MitM issued certificate and supplied a chain to self-signed certificate to the false ( compromised without leaking private key but issued for bad intentions ) certificate , then client should validate the chain, that is easy and understandable, when reaching to that self-signed certificate how to trust it ? >by design only public information is transmitted between the acme-client and acme-server How to authenticate acme-server ? and how to authenticate such server in cloud based service lets say acme server is using service like CloudFlare ? On 10/23/2018 7:45 PM, Alan Doherty wrote: no certificate can be 'compromised' all certificates are public information by nature (everyone attempting to connect to a https site sees the public-cert thus mitm seeing it moments before it becomes public is pointless and moot) only private keys (known only to the client and never transmitted) can be 'compromised' by design only public information is transmitted between the acme-client and acme-server At 15:56 23/10/2018 Tuesday, Kas wrote: On 10/23/2018 4:52 PM, Alan Doherty wrote: again your talking about stuff unrelated to acme (and unlikely to potentially effect acme) It is related to ACME. your talking about inherent problems with https (or all public key cryptography) (thus only addressable/fixable by https related ietf groups) https uses TLS which utilize certificates issued by acme to be validated against root certificates , so acme is involved or can be, and what RFC (draft or protocol ) control that root certificates store ? How did you get it ? why not included the last process involving the store and the certificates issued by ACME in this protocol instead waiting for another draft ? acme cannot (and should not) expect its users to develop/run/use software with an otherwise completely non-standard https implementation (and thus missing any improvements/bug-fixes etc within wider https protocol/libraries) it uses https because its an existing/maintained/developed widely available protocol (and will improve with any underlying improvements to the base protocol) but acme is designed to use https not for security, just for transport its security is designed to be in the data sent/received so eavesdropping (mitm) cannot be advantageous to 3rd parties and yes many improvements could be added to https but as all automatable ones can be as effectively be intercepted by a suitably technically proficient mitm (if you check dns, mitm dns) if you check 3rd party (mitm 3rd pary) etc etc if its visual check key on a webpage (regexp replace good/bad key on all traffic to victim mitm his whole internet) only 100% secure method is out of band (phone sms etc. even these can be mitm if your a state level actor) thats why the improvements to https are made elsewhere and rigorously tested adopted/abandoned by that community thats why we rely on browsers/https libraries to secure themselves usually based on arrives with trusted keys, trusts updates to this list that are signed with an already trusted one imperfect but perfection is impossible (all we can add is hoops to jump, restrictions etc) but all automated public-key checks can obviously themselves be compromised if you have access to the client or wire How is https relevant here ? even TLS is irrelevant as it all will go to root store and its source, MitM can issue attacks against the parties that will use the compromised certificate to establish trusted secure connection. You are missing the point, this protocol has the chance to standardize this root store and its source, and it is shame to pass it, at least to acme issued certificates and this will not contradict any existing protocol and doesn't require any change anywhere, so in theory you can build a secure bullet proof network where all the parties start with trusting one acme provider with no root store provided by any third party, and this can be the seed or motivation for other older CA's to follow, even OS's can follow and use the same protocol not to issue a certificate but to supply their root store in secure way , imagine your ability to configure a browser lets say Chrome running on Windows OS to use the root store provided by Mozilla, now Chrome is using the Windows certstore which is easy to be tampered with and its cont
Re: [Acme] Please consider adding server authentication
On 10/23/2018 4:52 PM, Alan Doherty wrote: again your talking about stuff unrelated to acme (and unlikely to potentially effect acme) It is related to ACME. your talking about inherent problems with https (or all public key cryptography) (thus only addressable/fixable by https related ietf groups) https uses TLS which utilize certificates issued by acme to be validated against root certificates , so acme is involved or can be, and what RFC (draft or protocol ) control that root certificates store ? How did you get it ? why not included the last process involving the store and the certificates issued by ACME in this protocol instead waiting for another draft ? acme cannot (and should not) expect its users to develop/run/use software with an otherwise completely non-standard https implementation (and thus missing any improvements/bug-fixes etc within wider https protocol/libraries) it uses https because its an existing/maintained/developed widely available protocol (and will improve with any underlying improvements to the base protocol) but acme is designed to use https not for security, just for transport its security is designed to be in the data sent/received so eavesdropping (mitm) cannot be advantageous to 3rd parties and yes many improvements could be added to https but as all automatable ones can be as effectively be intercepted by a suitably technically proficient mitm (if you check dns, mitm dns) if you check 3rd party (mitm 3rd pary) etc etc if its visual check key on a webpage (regexp replace good/bad key on all traffic to victim mitm his whole internet) only 100% secure method is out of band (phone sms etc. even these can be mitm if your a state level actor) thats why the improvements to https are made elsewhere and rigorously tested adopted/abandoned by that community thats why we rely on browsers/https libraries to secure themselves usually based on arrives with trusted keys, trusts updates to this list that are signed with an already trusted one imperfect but perfection is impossible (all we can add is hoops to jump, restrictions etc) but all automated public-key checks can obviously themselves be compromised if you have access to the client or wire How is https relevant here ? even TLS is irrelevant as it all will go to root store and its source, MitM can issue attacks against the parties that will use the compromised certificate to establish trusted secure connection. You are missing the point, this protocol has the chance to standardize this root store and its source, and it is shame to pass it, at least to acme issued certificates and this will not contradict any existing protocol and doesn't require any change anywhere, so in theory you can build a secure bullet proof network where all the parties start with trusting one acme provider with no root store provided by any third party, and this can be the seed or motivation for other older CA's to follow, even OS's can follow and use the same protocol not to issue a certificate but to supply their root store in secure way , imagine your ability to configure a browser lets say Chrome running on Windows OS to use the root store provided by Mozilla, now Chrome is using the Windows certstore which is easy to be tampered with and its content can't be 100% updated. >thats why we rely on browsers/https libraries to secure themselves Exactly , non-standardized process which allow a browser extension to inject root certificate in those libraries, and by non-standardized i mean there is no unified and securely designed process to update and ensure the root updated and secure, each browser and each system has its own method, and most of them require full update for the software before updating that root store, and acme has good chance to fix that, or at least do its part. At 13:52 23/10/2018 Tuesday, Kas wrote: On 10/23/2018 2:47 PM, Salz, Rich wrote: I don't know, there is many ways, but most likely someone will design an attack out of this and use it. If so (and I doubt it), such an attack would work on any web server/client combination, and is not specific to ACME. I don't have the mind set to think like an attacker, in internet security you can be astonished how attackers think, but let say you can only manage to know when a server (lets say university campus server) will request a certificate then all what you need is to make sure dns pointed to your laptop, and continue with the issuance the certificate, now you can utilize the CRL url in your certificate to make the victim clients makes call to an illicit url, monitored by the authority and that url let them download 50mb (crl request doesn't have size limit), how the victims can explain their phones and laptops downloaded such things, and here is the kick, the security software installed on the PC might make that request, those requests are not monitored by the system and most likely will bypass any firew
Re: [Acme] Please consider adding server authentication
On 10/23/2018 2:47 PM, Salz, Rich wrote: I don't know, there is many ways, but most likely someone will design an attack out of this and use it. If so (and I doubt it), such an attack would work on any web server/client combination, and is not specific to ACME. I don't have the mind set to think like an attacker, in internet security you can be astonished how attackers think, but let say you can only manage to know when a server (lets say university campus server) will request a certificate then all what you need is to make sure dns pointed to your laptop, and continue with the issuance the certificate, now you can utilize the CRL url in your certificate to make the victim clients makes call to an illicit url, monitored by the authority and that url let them download 50mb (crl request doesn't have size limit), how the victims can explain their phones and laptops downloaded such things, and here is the kick, the security software installed on the PC might make that request, those requests are not monitored by the system and most likely will bypass any firewall. I completely agree many of those attacks not specific to ACME, but with ACME it's concerning the parties in contact with the victim, and ACME has the ability to prevent and enhance the internet in overall. The core of the problem is with root store and who to trust, 15-20 years ago downloading a root store and verify it was something alien and unaccepted, now downloading 5mb can take few seconds and verifying it take way less, acme server can issue certificates using more than one CA certificate even it might have more than one root certificate, so why not to supply mini store so the clients of acme server can communicate in secure manner without trusting the system or any pre-supplied data, they just download the root store from example.com and you are good to go, all what is needed is acme URL or DNS with a key for DNSSEC or a key supplied by the ACME server itself. The current internet has well defined security protocols but in many cases depends on weak points, while creating new draft for such lets say root store will not go further than a draft or may be a RFC without adoption, and that why acme protocol and this draft has the power to change all of that, i am not calling for reinventing the wheel but to put a seed for better and secure internet, this seed might replace the crippled wheel, this draft will be mass adopted and i know this out of scope of this protocol intended usage, but still it has the power and the opportunity to do so, and on top of that you all who can make that happen, just think out of the box, and discuss this in depth, will this be best practice or bad practice? will such expansion to this protocol make the internet more secure or useless waste of time ? does such extra measures to secure the certificate issuance contradict with other RFC or enhance them? Please don't only think about this as how to prevent an attack (one or many) because what can go wrong will do, and this draft does have way more power and ability to move things very far in security, and i trust you can do good by at least discussing the big picture and how things will be in few years from now, as whole current system is wired with human factor administrating few key points, and all those secure castles are waiting for one CA server to fail and this will disturb the whole internet to its core. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Please consider adding server authentication
Revoke it and make all clients of the client mark the victim untrusted at a moment fits the attacker scheme, or make clients of the victim request CRL url to disturb a network, or get list of a client endpoints, cause trouble for a monitored network when the clients looks like accessing some specific IP or site. I don't know, there is many ways, but most likely someone will design an attack out of this and use it. On 10/23/2018 12:01 PM, Alan Doherty wrote: Acme server is CA server and shouldn't need a root store to be validated or trusted, that root store can be easily manipulated even by a software, even without locally manipulation the MitM can issue a certificate to the client by simply hijacking the connection and having certificate issued by trusted CA, and the client will validate and trust that certificate. how would this scenario be an attack??? if the mitm gives over a valid cert to the 'victim'-client what have they achieved? they have viewed otherwise public information that is useless to them, and 'victim' operations are uninterrupted (as obviously an acme client (as with all CA operations) never reveals the private key to a CA or any other parties, as only the public ones transit the wire) and gained 0 information/resources of use (and expended a lot of effort to mitm successfully, by somehow obtaining a trusted cert for the CA endpoint their impersonating) ___ 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
Re: [Acme] Please consider adding server authentication
On 10/22/2018 8:24 PM, Salz, Rich wrote: * My suggestion with something similar to DANE and DKIM (in utilizing DNS and DNSSEC), DNS TXT record is already been used by acme protocol to pass a challenge, so why not use similar implementation to authenticate the server itself for the client, so the client can verify the certificate and the chain, without a third-party. No third-party is needed. The client has to trust **something** out of band. In a browser, this is typically the root store, and any CA trust chain should end up being signed by something in that store. Other clients have different methods, but they are ultimately a set of trusted “root anchors.” If you put data in DNS, then the client has to trust DNS and the chain that signed that data. I think we’re struggling to understand the issue you are trying to raise. I am not trying to raise an issue, client can only trust acme server simply by providing a key (public key) along with the ACME URL, you trust example.com then put in your library this url and this key supplied by example.com service, thus the client doesn't need to trust anything else, by such key any MitM can be detected by both client and server or just one, that depends on how you tweak this protocol, that key can be supplied to the library by implementer, user or DNSSEC (in this case you need a key) . Acme server is CA server and shouldn't need a root store to be validated or trusted, that root store can be easily manipulated even by a software, even without locally manipulation the MitM can issue a certificate to the client by simply hijacking the connection and having certificate issued by trusted CA, and the client will validate and trust that certificate. Again i am sorry that you feel i am raising an issue, i am not, only suggesting a concerning matter to discuss. Best regards and sorry for wasting your time, K. Obaideen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Please consider adding server authentication
On 10/22/2018 7:14 PM, Salz, Rich wrote: * Are you worried about a MitM causing the real CA to issue a certificate to the MitM? That risk is already addressed in ACME, but using *client* authentication, not server authentication -- what matters is the client from which the server accepts domain proof and a CSR, not what server the client thinks it's talking to. * I am concerned about MitM issuing the certificate to the client. I am confused. You are worried about an attacker “intercepting” the ACME connection and issuing a certificate to the client? It is not necessary to add more “protection” at the TLS layer to protect against this. The client can verify the signed certificate, and CA chain, that comes back. DANE is not widely used, and it seems like a mistake to require it for ACME. Hi Richard, My suggestion with something similar to DANE and DKIM (in utilizing DNS and DNSSEC), DNS TXT record is already been used by acme protocol to pass a challenge, so why not use similar implementation to authenticate the server itself for the client, so the client can verify the certificate and the chain, without a third-party. You are the expert editors and contributors here, it is your job will decide to do this on ACME protocol layer or TLS layer, in both case it should use DNS TXT record and stay away from waiting for DANE or depending on external resources. Best regards, K. Obaideen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Please consider adding server authentication
On 10/22/2018 6:10 PM, Richard Barnes wrote: On Mon, Oct 22, 2018 at 10:57 AM Kas <mailto:k...@lightc.com>> wrote: On 10/22/2018 5:40 PM, Richard Barnes wrote: On Mon, Oct 22, 2018 at 10:13 AM Kas mailto:40lightc@dmarc.ietf.org>> wrote: Hi Richard, The weak point here is the TLS connection so the question is : How to prevent man in the middle from issuing a compromised certificate to automated client ? I don't understand what you're proposing here. There's nothing we can do in a protocol to stop a CA from issuing any certificate it wants to. (That's why we have Baseline Requirements, audits, etc.) Are you worried about a MitM causing the real CA to issue a certificate to the MitM? That risk is already addressed in ACME, but using *client* authentication, not server authentication -- what matters is the client from which the server accepts domain proof and a CSR, not what server the client thinks it's talking to. I am concerned about MitM issuing the certificate to the client. Why does the MitM even need ACME for this? Can't it just issue the certificate? Maybe your concern is that the MitM could convince the client to install and serve TLS using a certificate of the MitM's choosing. I can see how that could be harmful, e.g., if the certificate had improper SANs in it. This is addressed to a degree in the Operational Considerations [1], but could probably be improved. In any case, the right mitigation for this risk is for the client to verify that the certificate chain looks sane before installing it, since even the correct server could provide a malicious cert chain. [1] https://tools.ietf.org/html/draft-ietf-acme-acme-16#section-11.4 Exactly, MitM can issue a certificate with his own SAN, so how to validate a chain properly without third party ? what if the MitM has issued to the client a certificate with known trusted CA by the system, against what should the client validate and verify such certificate and its chain ? I don't see a way to verify a chain without third party ( trusted or known) as all root certificate are self-signed, how much time do you think is needed before changing this protocol to enforce DANE, DANE should be enforced long time ago but it will not happen any soon, and on other hand why repeat the process DKIM went through, till now it is not enforced but don't expect your email to reach its destination without proper DKIM. My point is don't waste this opportunity to implement the protocol the right way, all what you need is something like those examples i wrote, and here another one : in many server client application i wrote i used PSK ( pre-shared key) , server has a RSA public key in DNS TXT record and the client use it to encode his random generated pre-shared key and send it as hint to the server. My intention is not wasting anyone time, just explaining a point that can be problem in the future, and i am sure all of you can reach the perfect solution. Best regards K. Obaideen or How to make sure TLS connection is not compromised ? TLS require self signed root certificates and CA certificate and this compromise the client implementation and put weak points allowing attacks or failure due to expired certificates ( compromised system ...) , all of this can be prevented without waiting for/(or forcing) DANE by implementing similar approach. By adding such mechanism client can work securely forever, no certificate to expire or revoke, such feature will eliminate the depending on system provided CA certificates or any third-party source. This sentence should cause you concern. Nothing is forever in security. Using forever was wrong, i shouldn't say that. As I noted above, there is already no need for third-party resources.. --Richard Best regards, K. Obaideen On 10/22/2018 3:48 PM, Richard Barnes wrote: Hi Kas, Before launching into mechanism, maybe you could clarify what authentication property you think is lacking here? Note that ACME already has server authentication, via TLS server authentication. All the normal PKI mitigations apply there: CT, HPKP, etc. It is also already the case that the CA can issue certificates for its ACME server; no third party is needed. Thanks, --Richard On Mon, Oct 22, 2018 at 7:06 AM Kas mailto:40lightc@dmarc.ietf.org>> wrote: It will be regrettable and unfortunate moment to pass on such opportunity to make the internet more secure, and please let me start with listing the facts: 1_ ACME Server is CA server, if you consider it a CA server then
Re: [Acme] Please consider adding server authentication
Hi Richard, The weak point here is the TLS connection so the question is : How to prevent man in the middle from issuing a compromised certificate to automated client ? or How to make sure TLS connection is not compromised ? TLS require self signed root certificates and CA certificate and this compromise the client implementation and put weak points allowing attacks or failure due to expired certificates ( compromised system ...) , all of this can be prevented without waiting for/(or forcing) DANE by implementing similar approach. By adding such mechanism client can work securely forever, no certificate to expire or revoke, such feature will eliminate the depending on system provided CA certificates or any third-party source. Best regards, K. Obaideen On 10/22/2018 3:48 PM, Richard Barnes wrote: Hi Kas, Before launching into mechanism, maybe you could clarify what authentication property you think is lacking here? Note that ACME already has server authentication, via TLS server authentication. All the normal PKI mitigations apply there: CT, HPKP, etc. It is also already the case that the CA can issue certificates for its ACME server; no third party is needed. Thanks, --Richard On Mon, Oct 22, 2018 at 7:06 AM Kas <mailto:40lightc@dmarc.ietf.org>> wrote: It will be regrettable and unfortunate moment to pass on such opportunity to make the internet more secure, and please let me start with listing the facts: 1_ ACME Server is CA server, if you consider it a CA server then you don't need a third party to validate and secure the connection with such server. 2_ DANE is great but will not be adopted and needs years or a catastrophic failure by some CA to go mainstream, simply too many parties has it in conflict with their business model. 3_ SPF and DKIM are used in plain TXT DNS records and they already securing the internet the world. 4_ ACME protocol is utilizing DNS TXT record to authenticate the client so both server and client has DNS handling procedure. 5_ There is huge security hole in providing the root certificates to secure the internet, and in most cases it depends on the system store, many antivirus software installs with default settings to intercept HTTPS connection by injecting their own root certificate in system, many things can go wrong with system store, even extensions in a browser can do that. So why not authenticate ACME server in different way than DANE TLSA record and utilize TXT record similar to DKIM and make it a obligatory, this will allow two parties to securely communicate with only one requirement to trust one ACME server they already asking it for certificates, those parties can build secure internet environment based on one ACME server, even this protocol can evolve in future to issue certificates with only IP and no domain name, is that something wrong ? (listing few ideas, examples) "acme.TLSA" TXT here you can copy the whole content of TLSA record in JSON format encoded in base64url ( may be too much ) "acme.certs" TXT list the hash of the acme server certificates for secure connection ( shouldn't be the root or CA certificate ) "acme.ckeys" TXT list the the certificates public keys in JWK format with base64url encoding ( shouldn't be the root or CA certificate ) "acme.aKey" TXT contain one or more public keys (RSA or ECC) in JWK (base64url) format this key can be used to authenticate responses from acme server or only one critical response "acme.dir" TXT the directory url encoded with base64url ( in this case the client only need the server domain name like example.com <http://example.com> or staging.acme.example.com <http://staging.acme.example.com> to get the acme directory ) "acme.chain" TXT url to download acme server certificate chain in secure manner "acme.store" TXT url to download the mini store for that acme server certificate trust in secure manner ( if this adopted then there will be many store provider like mozilla.com <http://mozilla.com> or android.com <http://android.com> the client application can get his own store form his own sources, client trust Microsoft and its store but he can't be sure the store copy in his Windows is not tainted ) Please consider discussion this. Best regards K. Obaideen ___ Acme mailing list Acme@ietf.org <mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Please consider adding server authentication
It will be regrettable and unfortunate moment to pass on such opportunity to make the internet more secure, and please let me start with listing the facts: 1_ ACME Server is CA server, if you consider it a CA server then you don't need a third party to validate and secure the connection with such server. 2_ DANE is great but will not be adopted and needs years or a catastrophic failure by some CA to go mainstream, simply too many parties has it in conflict with their business model. 3_ SPF and DKIM are used in plain TXT DNS records and they already securing the internet the world. 4_ ACME protocol is utilizing DNS TXT record to authenticate the client so both server and client has DNS handling procedure. 5_ There is huge security hole in providing the root certificates to secure the internet, and in most cases it depends on the system store, many antivirus software installs with default settings to intercept HTTPS connection by injecting their own root certificate in system, many things can go wrong with system store, even extensions in a browser can do that. So why not authenticate ACME server in different way than DANE TLSA record and utilize TXT record similar to DKIM and make it a obligatory, this will allow two parties to securely communicate with only one requirement to trust one ACME server they already asking it for certificates, those parties can build secure internet environment based on one ACME server, even this protocol can evolve in future to issue certificates with only IP and no domain name, is that something wrong ? (listing few ideas, examples) "acme.TLSA" TXT here you can copy the whole content of TLSA record in JSON format encoded in base64url ( may be too much ) "acme.certs" TXT list the hash of the acme server certificates for secure connection ( shouldn't be the root or CA certificate ) "acme.ckeys" TXT list the the certificates public keys in JWK format with base64url encoding ( shouldn't be the root or CA certificate ) "acme.aKey" TXT contain one or more public keys (RSA or ECC) in JWK (base64url) format this key can be used to authenticate responses from acme server or only one critical response "acme.dir" TXT the directory url encoded with base64url ( in this case the client only need the server domain name like example.com or staging.acme.example.com to get the acme directory ) "acme.chain" TXT url to download acme server certificate chain in secure manner "acme.store" TXT url to download the mini store for that acme server certificate trust in secure manner ( if this adopted then there will be many store provider like mozilla.com or android.com the client application can get his own store form his own sources, client trust Microsoft and its store but he can't be sure the store copy in his Windows is not tainted ) Please consider discussion this. Best regards K. Obaideen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Suggestion for optional side channel information
I want at first to say sorry that my last email wasn't sent to new thread.
Now for the suggestions, i will start with the reason behind them it
might be easier to convoy the idea, i believe that this draft is one of
the most important protocol drafts in this year, with all those consumer
routers coming out of the box with support for dynamic domains and lot
of them comes with configured subdomains and they are all have HTTP
servers, so in not far future they will use this protocol to switch to
HTTPS, there is also countless server apps for mobile devices (and even
smart TV's) that utilize HTTP to share media over the internet and they
will use this protocol, in short i see this protocol to be very widely
used and specially in devices that is hard to reprogram or change
behavior, those devices will utilize some specific implementation (open
or closed source library), on other hand most libraries and
implementations will follow best practice to let the user to accept
terms of service, while most the developed software based on those
libraries will ignore that completely and accept blindly.
Now my suggestion is to add side info channel for both server and
client, it is optional but if this draft suggest that this info is
optional and it should be parsed and logged if there is log system, then
every software will follow that and log that text which can save time
and lead to better usage for both server and client."meta" object is
described in 9.7.6 and it is only for directory, i suggest to make this
meta object possible (optional) for every response with dedicated field
lets say "message" (or "critical" or... doesn't really matter ) , and
client is encouraged parse this "message" and keep (log it), it might
contain important information about the service itself ,examples for
such message:
"message" : "we updating infrastructure, we have scheduled maintenance
between 2018-10-08 3:00 and 2018-10-08 50:00 ; 2018-11-01 8:00 and
2018-11-01 11:00 (UTC timing) ; service be might appear offline in those
periods"
"message" : "this is beta service and will be discontinued on 1st of
December 2019, please consider switching to x "
"critical" : "RSA keys with 2048bits will not be allowed after june 2020"
"advice" : "(somelib here form user-agent) is known for security issues
or wrong handling the certificate chain please consider use our
(someotherlibrary) "
"server" : "our servers is under DDoS attack and we limiting
certificates issuance to 1 certificate per account per hour until Monday"
"serverMessage" : "our Terms of Service will be updated on 18th October
2019, to read more about the new termsOfService and its changes please
visit (url) "
Most usage of this protocol will have success and failure report/log,
but will not record or parse such info that service deemed important and
might enhance the quality of the service for both parties, BUT if it
mentioned with such examples in this draft it will go mainstream, in
case of failure there is big chance you already know the reason in the
current log or past log, and end user might be able to fix the failure
on his own based on that message (like changing keys, replacing
directory URL, or just wait few hours ) without even contacting the
service provider or consulting with the wise Google.
Now for client side i suggest new optional URL in the directory (like
"feedBack") where client can send some info message or petition or just
(thank you!) to server, it is optional for the server to parse and log
this or ignore it while i think the URL itself if you deemed useful
should not be, the service might be asking for feedback for statistical
data or just the sake of receiving thank you, and it could be something
like the following example ( here the request is already signed but it
might be not, it is optional ) :
POST /acme/feedBack HTTP/1.1
Host: example.com
Content-Type: application/jose+json
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1;,
"nonce": "ntuJWWSic4WVNSqeUmshgg",
"url": "https://example.com/acme/feedBack;
}),
"payload": base64url({
"message": "Please consider supporting ES512, and thank you !"
}),
"signature": "earzVLd3m5M4xJzR...bVTqn7R08AKOVf3Y"
}
About naming it can be one identifier in meta or a new message object or
two identifier in some object, i trust there is more qualified persons
here to decide how and what it should be, and you know what is better .
Best regards,
K. Obaideen
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] Sections 9.7.1 and 7.3.2 are unclear
From Section 9.7.1 : "This registry lists field names that are defined for use in ACME account objects. Fields marked as “configurable” may be included in a new-account request." "Client configurable:" "Initial contents: The fields and descriptions defined in Section 7.1.2" 1_ The section is unclear, if it is only for account objects listed in Section 7.1.2 then "externalAccountBinding" should not be listed or section 7.1.2 is missing "externalAccountBinding",which is defined as optional in Section 7.3 , along with "onlyReturnExisting" ,so should Section 9.7.1 contain other mentioned fields in other account sections like "oldKey" in (Section 7.3.5 Account Key Roll-over) ? !!?? 2_ "status" is listed as not configurable while it is configurable in (Section 7.3.6. Account Deactivation) . From (7.3.2. Account Update) : "If the client wishes to update this information in the future, it sends a POST request with updated information to the account URL. The server MUST ignore any updates to the “orders” field, “termsOfServiceAgreed” field (see Section 7.3.3), the “status” field (except as allowed by Section 7.3.6), or any other fields it does not recognize. " So basically server should check at first for "contact" field changes for every POST request and skip anything else, if that is the case then this logic should be mentioned in clear way in earlier sections, on other hand some changes to this sections might be enough to fix this and remove any confusion, so i suggest changing that paragraph to the following : "If the client wishes to update this information in the future, it sends a POST request with updated information to the account URL. The request MUST NOT contain "orders" field, “termsOfServiceAgreed” field, “status” field or "externalAccountBinding" field, and should contain "contact" field with the updated account information. If the server accepts the update, it MUST return a response with a 200 (OK) status code and the resulting account object." There is no need to mention (Section 7.3.6) as it is very clear, all responses from POST or POST-as-GET to a deactivated account MUST be unauthorized error response. Last thing : (Sections 9.7 New Registries) has sections 9.7.1 , 9.7.2 and 9.7.3 describing Account Objects, Order Objects and Authorization Objects and that i think cover all, except for 7.6. Certificate Revocation identifiers which left out , "certificate" and "reason" fields are new and deserve to be registered. Kind regards, K. Obaideen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] example.com is used all over the draft
From section 2 : "The CA verifies that the client controls the requested domain name(s) by having the ACME client perform some action(s) that can only be done with control of the domain name(s). For example, the CA might require a client requesting example.com to provision DNS record under example.com or an HTTP resource under http://example.com.; I suggest to use "example.com" only for the client mentioned in section 2, while adding another identifier like "acmeserver.com" or "caserver.com" will enhance the readability of all these examples. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Why revocation a certificate can't be done without authorization ?
Hello everyone, Shouldn't the revocation process more relaxed ? Section.7.6 require account authorization to revoke a certificate, and i can't see the good of this requirement and making it the only way, it is logical that the account owner can revoke a certificate, what i suggest is : Anyone should be able to revoke a certificate if he can prove that he has the private key of the certificate AND can pair it with the certificate itself ( Serial Number, Public Key ), for me this makes more sense, in case a server had been compromised then no need to wait for the account owner, so directory should have permanent URL for revocation that will take the Private Key of a certificate (or its hash) along the Serial number of the certificate, and would love to hear explanation of why this might be bad practice. Best regards K. Obaideen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
