Re: [Acme] Signed JSON document / Json Content Metaheader / JSON Container

On Wed, Jan 28, 2015 at 7:54 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jan 28, 2015 at 07:50:29PM -0500, Phillip Hallam-Baker wrote: On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker

Re: [Acme] Signed JSON document / Json Content Metaheader / JSON Container

On Wed, Jan 28, 2015 at 6:20 PM, Nico Williams n...@cryptonector.com wrote: On Wed, Jan 28, 2015 at 06:11:46PM -0500, Phillip Hallam-Baker wrote: OK, but why not put all of this into the headers anyways? Well that is what I suggested in my Content-Signature work and that is exactly how

[Acme] HTTP/J Draft

Earlier on this list we discussed the question of how to use JSON to encode messages. I think that it would be useful to write this up as a draft. I don't particularly care what the rules are but I would like to avoid writing a new set of rules for each protocol that comes along. One of the main

Re: [Acme] Proposed ACME Charter Language

On Wed, May 13, 2015 at 7:39 PM, Salz, Rich rs...@akamai.com wrote: https://github.com/letsencrypt/acme-spec/issues I'd prefer if we just recorded issues there, but discussed them in the mailing list. I would prefer if we avoid getting into practices and policy issues there as well. An

Re: [Acme] various issues with the spec

As a meta point, this discussion is incomprehensible. The objective is to produce a comprehensible spec. We should agree terms of art for the actors, certs etc. and use them consistently. On Sun, Jun 14, 2015 at 3:01 AM, Fraser Tweedale fr...@frase.id.au wrote: On Sun, Jun 14, 2015 at

Re: [Acme] WG meeting at IETF 93

I would like to present OmniPublish which is the protocol I was working on before ACME came along. It is not exactly the same as ACME but I think it is important to bear both approaches in mind because we are going to end up requiring both and I think they should both work in the same way and be

Re: [Acme] WG meeting at IETF 93

Another point I think should be considered on the agenda is how to use JOSE in the spec. I think it would be a very good idea to adopt the approach Mike Jones and myself have been suggesting of using JOSE without base64 armoring for authenticating requests and responses at the Web Service level.

[Acme] Offsite?

Seems to me that we could do with some intensive F2F time to get the spec right. Like a couple of days working on the validation mechanisms, framing etc. I'm not happy that we missed the signature misuse issue. ___ Acme mailing list Acme@ietf.org

Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

On Thu, Aug 13, 2015 at 3:17 PM, Tony Arcieri basc...@gmail.com wrote: On Thu, Aug 13, 2015 at 8:41 AM, Simon Josefsson si...@josefsson.org wrote: This is not a good discriminator of the CFRG options -- this problem is a weakness in this protocol, and should be addressed here. I'd agree,

Re: [Acme] Supporting off-line (manual) validation

On Tue, Jul 28, 2015 at 3:45 AM, Richard Barnes r...@ipv.sx wrote: On Mon, Jul 27, 2015 at 7:51 PM, Phillip Hallam-Baker ph...@hallambaker.com wrote: As a general rule, any protocol that contains a component that may be subject to variation in the field needs an IANA registry. Since we

Re: [Acme] Server on >= 1024 port

On Wed, Dec 2, 2015 at 12:52 PM, Romain Fliedel wrote: > So we might have a record of the form: >> >> example.com CAA 0 acmedv1 "port=666" >> >> > If you have to modify the dns to use a custom port, why not use the dns > validation method ? (once it's available) >

Re: [Acme] Server on >= 1024 port

On Wed, Dec 2, 2015 at 1:09 PM, Romain Fliedel <romain.flie...@gmail.com> wrote: > > > 2015-12-02 18:57 GMT+01:00 Phillip Hallam-Baker <ph...@hallambaker.com>: > >> >> >> On Wed, Dec 2, 2015 at 12:52 PM, Romain Fliedel <romain.flie...@gmail.com

[Acme] Perspective on validation

The discussion on validation on different ports suggests that we have the wrong understanding of what validation is for. All that is required to validate a certificate holder under the Basic Requirements is to prove they have control over a domain. This is also the minimum required. The port

Re: [Acme] Server on >= 1024 port

On Wed, Dec 2, 2015 at 4:52 AM, Paul Millar wrote: > Hi all, > > I'm writing just to summarise this thread and check a consensus has been > reached. > > On 25/11/15 11:13, Paul Millar wrote: > >> I was wondering whether people have considered services running on a >> port

Re: [Acme] Issuing certificates based on Simple HTTP challenges

On Wed, Dec 16, 2015 at 3:27 PM, Stephen Farrell wrote: > > > On 16/12/15 20:11, Michael Wyraz wrote: >> Stephen, >> >> I fear I have no idea what you mean with a "suffix list" and such. > > (Caveat: I'm very much an amateur at DNS issues, I hope someone > else provides

Re: [Acme] DNS challenge spec doesn't support CNAME model

The point of adding more validation mechanisms should be to cover more use cases. So examples that http challenge response covers are not too helpful. I do not see the value of a second type of c/r scheme. Dns is a lousy match for c/r. Why are people so set on this? If you want to use dns, use a

Re: [Acme] Issuing certificates based on Simple HTTP challenges

On Tue, Dec 15, 2015 at 2:41 PM, Noah Kantrowitz <n...@coderanger.net> wrote: > > > On Dec 15, 2015, at 9:48 AM, Phillip Hallam-Baker <ph...@hallambaker.com> > wrote: > > > > > > > > On Tue, Dec 15, 2015 at 12:25 PM, Noah Kantrowitz <n...@coder

Re: [Acme] Issuing certificates based on Simple HTTP challenges

Here is a handy list https://cabforum.org/ipr-exclusion-notices/ On Tue, Dec 15, 2015 at 6:24 PM, Richard Barnes <r...@ipv.sx> wrote: > On Tue, Dec 15, 2015 at 4:17 PM, Phillip Hallam-Baker > <ph...@hallambaker.com> wrote: > > > > > > On Tue, Dec 15,

Re: [Acme] Issuing certificates based on Simple HTTP challenges

On Wed, Dec 16, 2015 at 8:38 AM, Stephen Farrell wrote: > > > On 16/12/15 12:20, Julian Dropmann wrote: > > If they trust you with that, they could just add an ACRE specific SRV > > (ACRE? You mean acme I guess.) > > > record, and thereby delegate that privilege to

Re: [Acme] Issuing certificates based on Simple HTTP challenges

On Tue, Dec 15, 2015 at 9:39 AM, Salz, Rich wrote: > > > There's SRVName from https://tools.ietf.org/html/rfc4985 which in theory > > already can be applied to https already. SRVNames are used in the XMPP > > world a lot, maybe other places as well. > > But you can't put a

Re: [Acme] Issuing certificates based on Simple HTTP challenges

On Tue, Dec 15, 2015 at 10:08 AM, Kim Alvefur <z...@zash.se> wrote: > On 2015-12-15 15:55, Phillip Hallam-Baker wrote: > > On Tue, Dec 15, 2015 at 9:39 AM, Salz, Rich <rs...@akamai.com> wrote: > > > >> > >>> There's SRVName from https://tools.ietf.

Re: [Acme] Issue: Allow ports other than 443

I am getting really nervous about allowing any port other than 443. I just did a scan of a very recent clean install of Windows and there are a *TON* of Web servers running for apps that didn't mention they had one. The thing is that if I am running a process on any sort of shared host, I can

Re: [Acme] Proposal for http challenge: Lookup SRV records before A/AAAA records

Seems to me that we should specify a set of use cases, reduce them to requirements and then make sure we have at least one mechanism that covers each use case.  It is not necessary for every use case to be covered by every mechanism. In fact that is the point of having multiple mechanisms.

Re: [Acme] Comments on draft-ietf-acme-acme-01

I think Terminology and Dependencies should also have a mention of HTTP / HTTPS, also RFC3339 (time format). What I would like to get to eventually is some external document describing a particular style of JOSE /JSON / HTTP / TLS Web service that can simply be referenced by a Web Service spec.

[Acme] ACME / LURK consistency

As people here are probably aware, there is a BOF for LURK which is to do with some form of remote keying (maybe). Since the narrowest scope that might be decided for LURK is supporting TLS. I think there is going to be a lot of co-development and co-deployment. So it seems to me that LURK and

Re: [Acme] CAA Account Key Binding Draft Specification

Looks good to me. I think it would also be useful to provide guidance to ACME clients as to which CA to contact so as to support use of an LRA and/or transition from one CA to another. For example, lets say the initial CA was AliceCert.com and the site decides to use BobCert.com instead. The

Re: [Acme] Proposed changes to make use of JSON in layered fashion.

On Wed, Apr 20, 2016 at 6:25 PM, Ron <r...@debian.org> wrote: > > Hi Phillip, > > On Tue, Apr 19, 2016 at 02:51:27PM -0400, Phillip Hallam-Baker wrote: >> In the meeting, I proposed that we make the use of JSON in ACME >> something that can be easily share

Re: [Acme] CAA Account Key Binding Draft Specification

It is actually very important because those of us who spend their time looking up patent prior art can't necessarily check the GitHub in 20 years time. In some of the cases I have been involved in, the plaintiff has quite literally read posts on an IETF mailing list and turned them into a patent

[Acme] Proposed changes to make use of JSON in layered fashion.

In the meeting, I proposed that we make the use of JSON in ACME something that can be easily shared across multiple Web Services. In a few years time we are quite likely to have multiple JSON Web services that people want to use together. Implementing them as a suite is going to be easiest if

Re: [Acme] Consensus -- CAA draft to WGLC?

On Thu, Jul 6, 2017 at 6:16 AM, Martin Thomson wrote: > On 6 July 2017 at 20:07, Hugo Landau wrote: > > Vendor-assigned identifiers could be supported as such: > > vnd:example.com/custom-method > > RFC 6648 explains why vendor-prefixes can be a

Re: [Acme] CAA DNS RR IODEF e-mail spam && client side CAA verification

On Thu, Oct 22, 2020 at 1:05 PM Ryan Sleevi wrote: > > > On Thu, Oct 22, 2020 at 11:59 AM Anton Luka Šijanec > wrote: > >> Hello! >> >> ... > If such a system is already in place, how can I make sure I am >> correctly implementing it on my domain? Can someone direct me to the >>

Re: [Acme] Long-lived certificates, but frequently renewed certificates

I have two separate answers to these issues. Answer 1 is to start from a clean sheet of paper and design a PKI that addresses the needs of IoT devices directly. Answer 2 is to apply some of the techniques developed for Answer 1 to the legacy infrastructure. The biggest single simplification in