Re: [Acme] Short term certificates - two options

On 7/20/16, 12:06 PM, "Salz, Rich" wrote: >> >I think this could work, but I believe there are use cases >> >(specifically, CDNs) where people do not want to advertise the >>delegation. >> >> I favor solutions where the relying party can be aware of the >>delegation if >>

Re: [Acme] Pre-authorization approach

On 26/07/16 23:03, Richard Barnes wrote: > Option 2: copy/paste the "new-authz" flow back into the spec. > However, that's a lot of spec machinery to re-import, and it doesn't > allow the CA to express any sort of simplification due to multiple > domain names, such as the "just validate the

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

On Tue, Jul 26, 2016 at 1:54 PM, James Cloos wrote: > > "TH" == Ted Hardie writes: > > TH> The first is that control > TH> of a specific label has no easily generalized implication about > TH> administrative control of subsidiary labels. > > Which is

[Acme] Pre-authorization approach

Hey folks, At the IETF meeting, EKR pointed out the need to have a "pre-authorization" function in ACME, where the client can get authorization to issue for certain names without causing a certificate to be issued. Having thought about this a bit on the way home from the meeting, I'd like to get

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

> "TH" == Ted Hardie writes: TH> The first is that control TH> of a specific label has no easily generalized implication about TH> administrative control of subsidiary labels. Which is why we have publicsuffix. The language should note that a public suffix does not get

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

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

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

On Tue, Jul 26, 2016 at 1:13 PM, Richard Barnes wrote: > > > On Tue, Jul 26, 2016 at 6:48 PM, Patrick Figel 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

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

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,

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

> My request for the ACME would be: If I can prove I own the top level domain, > I should also be allowed to issue certs for any subdomain without need for > verification of those. Speaking as an individual, not co-chair. As a counter-example, if I own wordpress.net should I be able to get a

Re: [Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

On Tue, Jul 26, 2016 at 6:31 AM, Jostein Kjønigsen wrote: > The scenario of wanting to issue certificates for specific hosts while at > the same time having a secondary subject (a top level DNS round robin for > redundancy) is a very normal use-case. One example

[Acme] Support issuing certificates to subdomains when top level domain-ownership can be verified

Dear Ladies and gentlemen of the IETF. I was commenting on a Github issue for the ACME-spec with regard to issuing certificates for subdomains based on proven higher level domain ownership. As a response I was asked to forward my request here. And so I will. The scenario of wanting to issue

[Acme] Short term certificates - two options - a few comments

Hi Yaron, Thanks for keeping the ball rolling. It looks like the prominent operational difference between the two proposals is who has the onus for the functionality. In (1) the content owner is responsible for the proxying machinery that does the mediation between LURK and ACME. In (2) the