Re: [Acme] dns-01 challenge limitations

[Philipp Junghannß]

Simon Ser said:

> > Are there specific reasons why dns-01 requires updating a DNS
> record?
> >
> > Yes, because it proves you control the zone.
> Right, but there could be other ways to prove this as well.


care to share? what other methods are there to prove that you have access
to the DNS zone RIGHT NOW.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] dns-01 challenge limitations

[Philipp Junghannß]

 maybe one could make it so an email specific to the domain that is
verified could be used instead to just screw the entire DNS thing? I mean
CAs have used e-Mail based issuance over the address in the whois (no
longer  practical due to increase of whois privacy by default) or the
standardized hostmaster etc addresses. that way any given acme client would
only need access to the inbox of that specific mail which probably is a
whole lot easier than DNS stuff.

Am So., 13. Sept. 2020 um 11:13 Uhr schrieb Simon Ser :

> > On Friday, September 11, 2020 4:26 PM, Ryan Sleevi 
> wrote:
> >
> > > On Fri, Sep 11, 2020 at 9:28 AM Philipp Junghannß <
> teamhydro55...@gmail.com> wrote:
> > >
> > > > problem is obviously also the CA/Browser Forum has certain
> requirements,
> > > > and I guess having access to some kind of direct verification at the
> time
> > > > of issue might be probably one of these.
> > >
> > > This is the correct answer.
> > >
> > > While the IETF can certainly explore developing voluntary standards for
> > > other methods, the ability for CAs to adopt these methods is limited
> by CAs
> > > customers: the browsers and operating systems that include and use CAs
> to
> > > validate domain names on their behalf.
> > >
> > > The explicit goal by several browser/OS vendors is to obtain a fresh
> proof
> > > of control over a domain, and reduce/eliminate any caching or reuse.
> > > Delegation (by keys or persistent records) is definitely an area of
> > > expressed concern.
>
> My take is that in theory it's an understandable goal, but that in
> practice,
> this detoriorates security.
>
> In practice, ACME clients:
>
> 1. Have a static, long-term token stored in their configuration file
> 2. The token is powerful and can update any DNS record in the zone
>
> How come browser/OS vendors are fine with this, but not with a different
> approach involving an ACME-specific key?
>
> Sure, since this happens behind the ACME/DNS protocols and is an
> implementation
> detail, this isn't ACME's responsibility anymore. However, because
> browsers/OS
> vendors have this requirement of not allowing delegated proofs, we end up
> with
> a worse situation than necessary.
>
> 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.
>
> If an ACME client needs to prove that they have authority over a DNS zone,
> they
> will need some kind of authorization/key/token or similar, be it
> vendor-specific or not. Why not acknowlege this fact and come up with a
> reasonable standard?
>
> > > I think the suggest of more uniform APIs for managing DNS is very much
> in
> > > line with those goals, and would help far more than ACME.
>
> Yes, no matter what ACME requires, a standardized API to update DNS records
> would be nice. Michael Richardson suggested that such an API (or a subset
> of)
> already exists (via secure DDNS), but isn't supported by most DNS operators
> (even if supported by some DNS daemons).
>
> Establishing a new standard involves talking to existing DNS operators,
> and ask
> them to implement the new standard. For them, the new standard wouldn't
> have a
> high enough return on investment: ACME clients already volunteer to
> implement
> each and every proprietary API. Even if a good standard ticking the
> checkboxes
> of RFC 5218 existed, I don't think it would be successful (no "Positive Net
> Value" for DNS operators).
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] dns-01 challenge limitations

[Philipp Junghannß]

well Certificate transparency is one something should maybe keep
notifications for.

Also I can understand the problem, but I have not decided the outcome, I
merely stated what I got as an answer back then.

problem is obviously also the CA/Browser Forum has certain requirements,
and I guess having access to some kind of direct verification at the time
of issue might be probably one of these.

Am Fr., 11. Sept. 2020 um 15:21 Uhr schrieb Simon Ser :

> Hi,
>
> On Friday, September 11, 2020 3:13 PM, Philipp Junghannß <
> teamhydro55...@gmail.com> wrote:
>
> > I have asked that question in the LE forum iirc the problem is that
> > someone could place that record once and as long as someone doesnt
> > look at it all the time one can easily miss the fact that someone can
> > create wildcards and stuff for that domain, so the point is to prove
> > that dns access is given at the time of issuance.
>
> If someone has once write access to the DNS, they can set an
> acme-challenge record, redirect all requests, and issue wildcard certs.
> That would be easy to miss, too.
>
> > you could maybe use a different DNS Server which has a better API,
> > and potentially even can be used by ACME.
>
> The issue at hand isn't that a particular DNS registry operator isn't
> supported by a particular ACME client. What I want to fix is the need
> for all ACME clients to support all DNS registry operators.
>
> Thanks,
>
> Simon
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] dns-01 challenge limitations

[Philipp Junghannß]

I have asked that question in the LE forum iirc the problem is that someone
could place that record once and as long as someone doesnt look at it all
the time one can easily miss the fact that someone can create wildcards and
stuff for that domain, so the point is to prove that dns access is given at
the time of issuance.
you could maybe use a different DNS Server which has a better API, and
potentially even can be used by ACME.

Regards

Am Fr., 11. Sept. 2020 um 15:09 Uhr schrieb Simon Ser :

> Hi all,
>
> I've been working on an ACME client acting as a TLS termination proxy. In
> order
> to retrieve wildcard certificates from the Let's Encrypt ACME servers,
> support
> for the dns-01 challenge is required.
>
> dns-01 requires the ACME client to complete the challenge by updating a DNS
> record. This is bothersome because this often requires interacting with the
> DNS registry operator. This is typically done via vendor-specific APIs,
> with
> access control handled via vendor-specific means (tokens, public keys,
> etc).
>
> I understand that it's difficult for ACME clients to prove that they are
> authorized to obtain wildcard certificates. However, have other
> alternatives
> been considered?
>
> For instance, it would be possible to require users to add a short public
> key
> in a DNS TXT record, then ask the ACME client to sign challenges with that
> key.
> Something like this would significantly ease the development of ACME
> clients.
>
> Are there specific reasons why dns-01 requires updating a DNS record?
>
> Thanks,
>
> Simon Ser
>
> (CC mholt, I figured you might be interested in this for Caddy too)
>
> ___
> 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] { "cassandrahernandez...@gmail.com" }

[Philipp Junghannß]

how about you first explain what you are eventalking about, instead of just
coming around with a list and saying that they are all bad people?

also in what way is this related to the ACME mailing list?

Regards

Am Sa., 7. März 2020 um 22:39 Uhr schrieb mar isa her <
cassandrahernandez...@gmail.com>:

> These are all bad people.
> ___
> 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] Certificate chains including roots

[Philipp Junghannß]

But isn't the point of this proposal that the client CANNOT be expected
knowing the root like with DANE/TLSA'd servers with a custom root or
whatever?

Am 12.03.2018 15:57 schrieb "Jörn Heissler" :

> On Mon, Mar 12, 2018 at 12:25:14 +, Hugo Landau wrote:
> >   1. Clarify the specification to state that the root certificate must
> >  always appear in the chain at the end. Clients should be advised to
> >  pop the root certificate if they are procuring certificate chains
> >  for non-DANE applications only. Failure to do so will result in
> >  unnecessary but harmless transmission of the root certificate
> >  during TLS handshakes.
> >
> >   2. Don't include the root certificate but provide a way to retrieve it,
> >  e.g. via a Link header.
> >
> >   3. Clarify the specification to state that the root certificate must
> >  not appear in the chain, and that roots must be retrieved using the
> >  AIA URL inside the final certificate in the chain if it is needed.
> >  This minimises the chance of clients for non-DANE applications
> >  messing up and provides a viable method for discovery of the root
> >  CA for applications which need it.
> >
> > I'd support option 1 or option 3 equally. Either way, I think this
> > should be clarified.
> >
> > Thoughts?
>
> There's one more option which I'd actually prefer.
>
>   4. Root certificate does not appear in the chain but it's expected
>  that clients already know it. E.g. look in /etc/ssl/certs/.
>
> Rationale is that the client shouldn't blindly trust that the chain
> received by the acme server is valid.
>
> ___
> 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] Idea about automated OV validation

[Philipp Junghannß]

well true passports/ID cards are intresting although there's alayes the
problem about the access structure and so on. German ID cards for example
can only be read with a certificate from a "permission certificate
authority", which are most probably selected by the gov and I wouldnt
expect those permission certs to come cheap, they also require
documentation about how the company handles privacy and so on and so on,
add some more countries with their own respective systems into the mix and
we have pure chaos. I doubt a non-profit CA like LE could do that well.

2017-12-01 15:21 GMT+01:00 Sebastian Nielsen <sebast...@sebbe.eu>:

> Also could be done by having a interface where you scan your passport with
> a NFC compatible reader (both mobile phone and desktop NFC reader could be
> supported) and the government-signed data is uploaded.
>
>
>
> So automated validation for private IV certs could be done too (IV =
> Individual certs). So free code signing and IV validated certs.
>
>
>
> https://community.letsencrypt.org/t/iv-certificates-both-
> server-and-code-via-automated-nfc-passport-id-validation/44838
>
>
>
> *Från:* Acme [mailto:acme-boun...@ietf.org] *För *Philipp Junghannß
> *Skickat:* den 1 december 2017 14:57
> *Till:* Matthias Merkel <morit...@moritz30.de>
> *Kopia:* IETF ACME <acme@ietf.org>
> *Ämne:* Re: [Acme] Idea about automated OV validation
>
>
>
> if that's what other CAs do that's not a bad Idea although there's of
> course the question whether there are some other manual checks needed.
>
>
>
> but cheap to almost free OVs/code signing certs would be great although
> that sadly doesnt make it easier for normal people without a company to get
> IVs or code signing certs, but the Idea is certainly not bad.
>
>
>
> 2017-12-01 14:53 GMT+01:00 Matthias Merkel <morit...@moritz30.de>:
>
> I had the following idea about automating verification and issuance of OV
> SSL certificates: Couldn't a CA in theory use the D API to check the
> company name, address and phone number and then place an automatic call?
> That's basically what most CAs do anyways so is there any reason why they
> couldn't do it? That would also be a way for Let's Encrypt to issue OV
> certificates and code signing certificates.
>
>
>
>
>
>
> ___
> 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
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Looking for comments on https://github.com/ietf-wg-acme/acme/issues/215

[Philipp Junghannß]

well I think it's a bad idea. as I commented in the issue directly
TLS-SNI-01 fell straight on the face because of the way servers may handle
hosts without a setting.

2016-12-03 13:35 GMT+01:00 Patrick Figel :

> I wrote together some thoughts on this proposal here[1]. In short, I think
> it's
> vulnerable to the default vhost attack that caused simpleHTTP to be
> dropped, and
> it's not compatible with the "Agreed-Upon Change to Website" method
> described
> in the BRs, which would prevent adoption by any publicly-trusted CA.
>
> The proposed workaround for this issue[2] would make this a variant of
> tls-sni,
> AIUI, which already has these pseudo-hostnames, so I think we're down to
> "allow
> other ports" here, and I believe there's consensus against this.
>
> Patrick
>
> [1]: https://mailarchive.ietf.org/arch/msg/acme/
> QiXu84RJtURfGVVEYfSpRdtcU5o
> [2]: https://mailarchive.ietf.org/arch/msg/acme/
> NFKJ5sqBePGlJglKRwodc5m4ZEo
>
> On Sat, Dec 3, 2016 at 3:18 AM, Salz, Rich  wrote:
> > With the couple of recent pull requests, the document editors are about
> to
> > close all but on issue, #215.
> >
> >
> >
> > Does the WG have any feelings on this?  Is it something we need to
> address
> > NOW, or can we add a new type of challenge later on if there’s interest?
> >
> >
> >
> > Please reply on-list by earl next week.
> >
> >
> >
> > --
> >
> > Senior Architect, Akamai Technologies
> >
> > Member, OpenSSL Dev Team
> >
> > IM: richs...@jabber.at Twitter: RichSalz
> >
> >
> >
> >
> > ___
> > 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
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Nonces and replay attacks

[Philipp Junghannß]

well wouldnt make much sense to use a nonce in the first place, if it isnt
in the signature.

but a nonce is a number which should only be used once, and since it's
generated at random, there is no reason why the server shoudnt throw a
proper nonce e.g. if the randomizer of Alice's system is crap or whatever.

2016-11-25 17:36 GMT+01:00 Sam Kuper :

> Hi Daniel,
>
> On 25/11/2016, Daniel McCarney  wrote:
> > I can see no good reason for this to be "SHOULD" rather than "MUST".
> >> Please can it be changed to "MUST"? Otherwise, a client might have no
> >> way of knowing why the request failed, and therefore no reasonable way
> >> to proceed.
> >
> > This seems reasonable, I would also be supportive of a change like this.
>
> Excellent. Thank you.
>
> >> That looks dangerous to me. If the server implements the requirement
> >> above, then when Mallory's attempt to replay Alice's request has just
> >> failed, the server will reply with a fresh nonce, thereby
> >> potentially giving Mallory the means to usurp Alice's session. Ouch!
> >
> > You start by talking about an adversary that is replaying existing
> > messages,
> > which causes the badNonce error when the request is replayed the second
> > time. But when you say "potentially giving Mallory the means to usurp
> > Alice's session", that would require the adversary construct a new signed
> > message using the nonce without the participation of Alice - this
> shouldn't
> > be
> > possible in the MITM threat model that the nonce usage is meant to
> address.
>
> Ah, indeed, if the request must contain the new nonce and be signed
> with Alice's private key, then you are correct, and my previous reply
> (to Philipp) was overly hasty.
>
> Thanks for your explanation, and apologies to Philipp for my
> misunderstanding.
>
> Sam
>
> ___
> 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] Nonces and replay attacks

[Philipp Junghannß]

Doesnt the request have to be signed and stuff anyway by the account key?

Am 25.11.2016 16:44 schrieb "Sam Kuper" :

> Dear all,
>
> I am new to this mailing list, and am likewise new to reading the draft
> ACME protocol with a critical eye. I hope to avoid committing any
> blunders, but ask your forbearance for my newness, should I fail.
>
> draft-ietf-acme-acme-04, section 5.5 contains two pieces of text that I
> think could be improved. These improvements would be substantive to the
> protocol, not merely editorial, which is why I am raising them on the
> mailing list.
>
> The first piece of text is this:
>
> > When a server rejects a request because its nonce value was
> > unacceptable (or not present), it SHOULD provide HTTP status code 400
> > (Bad Request), and indicate the ACME error code
> > "urn:ietf:params:acme:error:badNonce".
>
> I can see no good reason for this to be "SHOULD" rather than "MUST".
> Please can it be changed to "MUST"? Otherwise, a client might have no
> way of knowing why the request failed, and therefore no reasonable way
> to proceed.
>
> The second piece of text is this:
>
> > An error response with the "badNonce" error code MUST include a
> > Replay-Nonce header with a fresh nonce. On receiving such a response,
> > a client SHOULD retry the request using the new nonce.
>
> That looks dangerous to me. If the server implements the requirement
> above, then when Mallory's attempt to replay Alice's request has just
> failed, the server will reply with a fresh nonce, thereby
> potentially giving Mallory the means to usurp Alice's session. Ouch!
>
> That being so, a suitable replacement for the second piece of text
> quoted above would be:
>
> > An error response with the "badNonce" error code MUST NOT include a
> > Replay-Nonce header with a fresh nonce. On receiving such a response,
> > a client SHOULD log it and attempt to notify its human operator that
> > the server has reported evidence of a replay attack.
>
> Best wishes,
>
> Sam
>
> ___
> 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] Support issuing certificates to subdomains when top level domain-ownership can be verified

[Philipp Junghannß]

well I brought this already up as "walk-up authorisations" or similar.


Rich Salz brought up domains like wordpress.com and github.io as examples
where the parent shouldnt get certs with another check, but I personally
think that this is junk.
this is (obviously) because the parent could take control of the subdomain
and verify it anyway that's just how the system works. not allowing a walk
up for subs just makes it more annoying.

also talking about cache-poisoning and other funny stuff, one could say
that walk up only can occur only in certain conditions, for example that
there needs a flag set as a record in DNS and secured by DNSSec and the CA
could easily check the DNSSec. also unlike the CA system DNSSec works with
a tree-like structure so it's pretty limited on who can sign for what.

for example for the domain "google.com" there are only 3 entities that can
sign for it. one is obviously Google themselves, then we have the
Management of the .com DNSSec key and finnaly (obviously enough) the ICANN
with the root key.

so one could say that if the authorisation is done via DNSSec'ed DNS
authorisation plus a record indicating walk-up it would be fine enough and
that would be pretty strict.

it may be that in some cases the subdomains are controlled by another
entity but it isnt a secret that the parent can take control anyway.

That's just my opinin.

Best regards (or for all the german readers, MFG)

Philipp Junghannß / My1

2016-07-26 22:34 GMT+02:00 Ted Hardie <ted.i...@gmail.com>:

> On Tue, Jul 26, 2016 at 1:13 PM, Richard Barnes <r...@ipv.sx> wrote:
>
>>
>>
>> On Tue, Jul 26, 2016 at 6:48 PM, Patrick Figel <patfi...@gmail.com>
>> wrote:
>>
>>> On 26/07/16 18:00, Peter Bowen wrote:
>>> > I don't see anything in the ACME specification that disallows this
>>> > at the protocol level.  I think a CA could request you validate a
>>> > DNS identifier of 'example.com', then accept that authorization for
>>> > the issuance of 'ship.example.com'.  Conversely, ACME does not
>>> > require CAs allow such and I hope it stays that way.  CA policy
>>> > should be distinct from ACME.
>>>
>>> Agreed that this should be a policy decision.
>>
>>
>> +1
>>
>
> So, it's more than a policy decision, unfortunately; it's a combination of
> two properties of the DNS that are problematic.  The first is that control
> of a specific label has no easily generalized implication about
> administrative control of subsidiary labels.  The IAB controls .ARPA, for
> example, but has delegated e164.arpa in a way that would make allowing the
> IAB to request certificates for delegations under it to be a pretty
> problem.  The same problem occurs for many gTLDs, ccTLDs, and a number of
> second level domains.  The work in the DBOUND working group also notes
> this in describing delegation
> <https://datatracker.ietf.org/doc/draft-deccio-dbound-organizational-domain-policy/?include_text=1>
> :
>
> "However, policies governing the use of domain names do not always align
> with those lines of delegation.  There are currently no generally reliable
> methods to reconcile domain names with policy for their use."
>
> They are working on the problem, of course, but it is still a problem.
>
> The second issue is that this seriously worsens the cache poisoning
> attack; if you manage to cache poison the CA's view of the hierarchical
> ancestor, you would now be able to generate certificates for all its
> descendants.
>
> So, while I agree that this is a policy issue, I believe that the
> specification should have a statement that the default  should be
> restrictive and why.  I don't think that the text should be in an appendix,
> frankly, but should be pretty much front and center with appropriate
> warnings.
>
> (as an individual)
>
> Ted
>
>>
>>
>>> It's worth pointing out,
>>> however, that prior drafts contained language that made it clear that
>>> it's a policy decision, which seems to have been removed in the acme-03
>>> draft. It used to read:
>>> "It is up to the server's local policy to decide which names are
>>> acceptable in a certificate, given the authorizations that the server
>>> associates with the client's account key."
>>>
>>> Was this removed deliberately, or did it get lost as part
>>> of the "Application" change? I think it would make sense to add
>>> something like that to the CA Policy Considerations section, just to
>>> make it clear that this is indeed a policy decision (unless the WG
>>> thinks otherwise?)
>>>
>>
>> It was a side-effect o

Re: [Acme] Comment on draft-landau-acme-caa-00

[Philipp Junghannß]

but then again, a key enforcement can also allow for this key not needing
to prove a challenge since it already IS approved.

2016-04-22 14:50 GMT+02:00 Yaron Sheffer :

> Hi,
>
> I support tightening ACME with additional security controls, and the
> Account Key seems like a good place to start. But given that we have a
> DNS-based authorization method, this proposal looks like overkill.
>
> If the attacker has access to the DNS zone for the host being certified,
> then they can use this access (with DNS-01) to issue a certificate.
> Moreover, they can change the CAA record or add new ones, making this
> protection moot. (Reminder: CAA records are evaluated "bottom up", i.e. the
> most specific one wins).
>
> If the attacker does not have access to the DNS zone, the proposed
> protection becomes interesting. But then a simpler, easier to manage
> solution would be to limit the allowed challenges. So maybe instead of
> specifying an account key, use
>
> example.com. IN CAA 0 issue "example.net; \
>  acme-ac=dns-01
>
> (where "ac" is Allowed Challenge). This would mandate that the CA only use
> DNS-01 and no other challenge, ensuring that the ACME client must prove
> control of DNS.
>
> Thanks,
> Yaron
>
> ___
> 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] [acme] Account deletion for security currently useless if rolled over

[Philipp Junghannß]

Okay didnt know that one yet.
Am 18.04.2016 18:32 schrieb "Richard Barnes" <r...@ipv.sx>:

> You can already revoke with the cert key.
>
> On Mon, Apr 18, 2016 at 12:30 PM, Philipp Junghannß <
> teamhydro55...@gmail.com> wrote:
>
>> In my opinion it would be also nice if you could revoke with the cert key
>> making it possible to remove the cert even if the acc is down.
>> Am 18.04.2016 18:15 schrieb "sheel.at" <pub...@sheel.at>:
>>
>>> Suppose an account key gets compromised. To prevent abuse, the owner can
>>> delete the account:
>>>
>>> https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#deleting-an-account
>>> However, people having the key can simply change it without any effort:
>>>
>>> https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#account-key-roll-over
>>>
>>> What happens if the attacker does so before the owner can react, or even
>>> before the owner notices anything of the breach?
>>>
>>> I suggest changing tha specs (and implementation) to keep old keys after
>>> changes for while. More specifically:
>>> * When an account key is rolled over, the old key is kept for eg. 30
>>> days.
>>> * Multiple changes within this 30 days mean that there are multiple old
>>> keys.
>>> * Account deletion is possible with any of the saved keys, be it old or
>>> new.
>>> * Everything else (other than account deletion) only accepts the new
>>> (newest) key.
>>>
>>> Related:
>>> The owner has no possibiliy to revoke certificates issued by the
>>> attacker. For proper uses, nuking all certs when deleting the account
>>> might be not what the users like, but for the attack scenarion...
>>>
>>> Related 2 (yeah, it's getting bothersome)
>>> If there is an "optional" certificate nuking when deleting accounts, the
>>> attacker could issue certificates and then delete the accountwithout
>>> destroying the certificates(the attacker!), to prevent the real owner
>>> from destroying the certificates. Meaning, a "partially" deleted account
>>> has to stay around for ... as long as there are non-expired
>>> certificates?, just for the possibility that someone wants to delete the
>>> rest too. (But without being useful for anything else other than
>>> deleting)
>>>
>>> ...
>>> I'm rather new to the Let'sEncrypt internals, so if I missed the fact
>>> that there is a solution already, please forgive me.
>>>
>>> Otherwise, sorry, I know spec'ing and implementing this would be
>>> annoying. But without this, the possibility for deleting an account key
>>> is not particularly useful.
>>>
>>>
>>> ___
>>> 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
>>
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Exposed rate limits

[Philipp Junghannß]

well My idea would be:
display the most restrictive by default.
add option to list all.
about the code vs readable message I would think of a hybrid approach.
apply a code and a message.
the code coule be used so the client if it knows it that it could e.g.
translate it into different languges etc. and the embedded message copes
with all clients that dont know the code yet, also add a code for "other"
which can be used for stuff that doesnt have a code yet

2016-03-21 23:51 GMT+01:00 J.C. Jones :

> On Mon, Mar 21, 2016 at 3:45 PM, Niklas Keller  wrote:
> > Will it be possible to standardize all names? Other CAs may use other
> rate
> > limits. So should `RateLimit-Name` be a code or a human readable message?
>
> My guess is that getting an exhaustive list of rate limits would be
> difficult, and that implementing CAs may want to adjust these values
> quickly outside IETF.
>
> It's probably good to leave flexibility it in, if we can. Further thought:
> Instead of or in addition to a name, there could be a URI to a description
> or help document.
>
> Cheers,
>
> - J.C.
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] HTTP and DNS Challenge string

[Philipp Junghannß]

that should pretty much what it will be about.

2016-03-21 11:03 GMT+01:00 Thomas Lußnig <luss...@suche.org>:

> Currently
>
> 1) Client->Server Request(domain.xy) => Response(nonce to be signed)
> --> Server fetch CAA record
> 2) Client->Server Request(Please check via dns/http)
> --> Server check resouce
> 3*) Client->Server Is the Check complete(Please check via dns/http)
>
>
> My Idea
>
> 1) Client->Server Request(domain.xy) => Response(nonce to be signed)
> --> Server fetch CAA record + DNS(acme.pubkey.domain.xy) to get the PIN of
> account key
> 2) Client->Server Request(Signed nonce with private key, Public Key) =>
> Response(Sucess/Failed)
>
>
>
>
> Am 21.03.2016 um 10:34 schrieb Philipp Junghannß:
>
>> to sign an extra random value because it should probably have signed one
>> when trying to request the cert so they can just check for the
>>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] HTTP and DNS Challenge string

[Philipp Junghannß]

I didnt even specify a direct order in the first place but the client could
tell the user on how to do the stuff if there is no key. pre-publishing is
one of the reasons for this since it also allows you to delegate a
subdomain to someone else in DNS challenge without having to wait for a
challenge.

also you even need to sign an extra random value because it should probably
have signed one when trying to request the cert so they can just check for
the records/keyfile and compare the signature.

regards.

2016-03-21 10:29 GMT+01:00 Thomas Lußnig <luss...@suche.org>:

> Hi Philipp,
>
> why not switch the handling.
> Publish the Fingerprint of your public Key in DNS/WEB.
> And the challenge is then to sign the random value with your public key.
> This would also speed up the whole process. Since the acme server
> can get the pub key when you request the domain and check than your
> response.
> And not you tell him check the webpage now and wait till he checked the
> page.
>
> Gruß Thomas
>
>
> Am 21.03.2016 um 09:42 schrieb Philipp Junghannß:
>
> hello, I have a little proposal:
>
> https://github.com/ietf-wg-acme/acme/issues/88
>
> in short, I see not THAT much reason to use a completely random string for
> the challenges, I think it would be better to just use your account key.
> the only thing random keys are is increase annoyance when you cannot work
> automatically (try manually posting 14 challenges from SSH to your web
> folder and you'll get my point)
>
> my Idea is that instead of a random string you rather use your account key
> (or a hash of it) as the challenge. with that you dont always have to
> create and delete challenge records because you can just let it stay there
> which essentially also lowers the strain of DNS Servers during renewal
> times (in case of DNS validation)
>
> also the servers of the ACME-CA will also have less strain because they
> dont need to send extra challenges and check those, because the possession
> of the key is already proven because it needs to sign every request to the
> ACME protocol, that's why it makes sense to just use the esatblished
> identity instead of establishing something completely new and then linking
> it. They just need to download the key file/records and check whether the
> key we want is inside
>
> also when you want to create a SAN cert with http challenge for multiple
> webroots you can just copypaste the same file to all webroots and the
> automation doesnt have to worry about anything else.
>
> best regards.
>
>
> ___
> Acme mailing listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
>
>
> ___
> 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] Exposed rate limits

[Philipp Junghannß]

adding to this some parts of rate limits should be maybe made a bit clearer
if not already (e.g. if you have multiple different domains in a SAN which
will get the count, just the CN? or all of them?
also it would be nice to add a command that gives you the ability to check
the limits before even thinking of creating a cert.

2016-03-21 9:28 GMT+01:00 Niklas Keller :

> Morning,
>
> I added a PR exposing potential rate limits to clients. Rate limits can be
> used to show warnings to the user, e.g. when certificate issuance is
> limited to 5 certificates per 7 days and you already issued 3. A single
> client can't count these, because they may be on different servers using
> different clients.
>
> https://github.com/ietf-wg-acme/acme/pull/104
>
> Best Regards,
> Niklas Keller
>
> ___
> 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] Quick feedback on two PRs

[Philipp Junghannß]

as the situation is now I am against removing the PoP becase it is really
helpful when the automation cannot do its thing (there are so many reasons
why you cant really automate everything. but when there will be some other
changes to the challenges which would make it a bit more humanly possible
to create a SAN certificate with more than just 2 domains.

regards

2016-03-21 3:14 GMT+01:00 Richard Barnes :

> Hey all,
>
> I've published a two PRs that I think should be non-controversial, but
> they're significant enough that I wanted to run them by the group.  I would
> appreciate it if you could take a look and give a quick thumbs up / thumbs
> down in Github (at the indicated URIs).  If you have any substantive
> comments, please reply in this thread.
>
> #101 Remove proof-of-possession challenge
> https://github.com/ietf-wg-acme/acme/pull/101
>
> #102 Replace in-band account recovery with `meta`
> https://github.com/ietf-wg-acme/acme/pull/102
>
> I'm happy to hold any of these if they need more discussion, but if
> there's no disagreement before the I-D deadline at midnight UTC, I'll go
> ahead and merge them before I post -02.
>
> Thanks,
> --Richard
>
>
> ___
> 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