Hi,
I hereby give AUTH48 for RFC8647 as it currently appears here:
https://www.rfc-editor.org/authors/rfc8647.txt
The document is ready for publication as RFC8647.
Yours,
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman
AUTH48 on
2019-09-27.
Yours,
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
> Perfect; thanks, Hugo.
>
> Barry
New I-D posted.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
On Thu, Jun 20, 2019 at 09:52:40PM +0100, Hugo Landau wrote:
> > I note (and thanks for the heads-up, Ben) that there's new ABNF in
> > Section 4 of this version. I have a DISCUSS-level question on it.
> >
> > The ABNF allows for the value of "validationmethods&qu
> I note (and thanks for the heads-up, Ben) that there's new ABNF in
> Section 4 of this version. I have a DISCUSS-level question on it.
>
> The ABNF allows for the value of "validationmethods" to be empty, but
> the first paragraph of Section 4 says, "The value of this parameter,
> if
Sorry, I somehow missed this one.
> --
> DISCUSS:
> --
>
> I think we need to have some privacy considerations text about how this
> mechanism exposes ACME
On Thu, May 30, 2019 at 07:23:46PM +, Salz, Rich wrote:
> Thanks for the review and feedback, Barry.
>
> Hugo, please post a new draft with your proposed changes; nothing there seems
> other than editorial clarifications.
Done.
___
Acme mailing
> This all makes sense. Would it be reasonable to recommend not just
> "ca-", but "ca--"? Experience has shown that if "flarb"
> is a common thing among CAs (or whatever) and Verisign implements a
> "ca-flarb", that will tend to leak and become an unregistered
> standard... but that's far less
> --
> DISCUSS:
> --
>
> Firstly, thank you for writing this -- I do however have some concerns around
> Section "5.6. Use with and without DNSSEC"
>
> 1:
> §5.4:
>
> > Suppose that both CA A and CA B issue account URIs of the form
> >
> > "account-id:1234"
>
> This is a little concerning as an example, as "account-id" isn't a registered
> URI scheme. Consider instead using:
>
> urn:example:account-id:1234
>
Done.
> --
> DISCUSS:
> --
>
> — Section 4 —
>
>If appropriate non-ACME identifiers are not present in the
>ACME Validation Methods IANA registry, the CA MUST
> --
> COMMENT:
> --
>
> Hugo, thank you for the work put into this document. Adding some examples was
> a
> good idea.
>
> I found it interesting that the
nsions for Account URI and ACME
> Method Binding
> Author : Hugo Landau
> Filename: draft-ietf-acme-caa-06.txt
> Pages : 9
> Date: 2019-01-15
>
> Abstract:
>The CAA DNS record allows a domain to communi
On Sat, Dec 29, 2018 at 03:23:35AM +, Salz, Rich wrote:
>
> + Validation methods beginning with the prefix "ca-" are reserved for
> CA-local
> + meaning and may not be registered.
>
> "need not be" ? Or "SHOULD NOT be" ?
My intention was that the rules of the registry state
> Would like to see proposed wording, but the concept seems fine.
How about, changes marked:
Validation methods do not have to be compatible with ACME in order to be
registered. For example, a CA might wish to register a validation method in
order to support its use with the ACME
> I'm open to alternative methods of preventing conflicts. A prefix could
> > be reserved for CA-specific use, e.g. "nonacme-".
> >
>
> That would be fine.
Amended to:
Where a CA supports both the "validationmethods" parameter and one or
more non-ACME challenge methods, it MUST assign
On Sun, Nov 04, 2018 at 07:18:05PM -0800, Eric Rescorla wrote:
> IMPORTANT
> S 4.
> > Where a CA supports both the "validationmethods" parameter and one or
> > more non-ACME challenge methods, it MUST assign identifiers to those
> > methods. These identifiers MUST be chosen to
> Hi Jacob,
> Perhaps not as elegant and concise, but a workaround would be to temporarily
> (until 6844-bis gets incorporated into the Baseline Requirements) prohibit
> multiple parameters in the same CAA record and instead require that multiple
> parameters span multiple issue/issuewild
> Can the authors of each draft please send a brief (one or two sentences is
> fine) status to the mailing list about their drafts? Also indicate if you
> want WG time to present, talk about issues, etc. We are scheduled to meet
> during the Tuesday afternoon session, from 17:20-18:20 (last
ding
> Author : Hugo Landau
> Filename: draft-ietf-acme-caa-05.txt
> Pages : 9
> Date: 2018-06-21
This revision removes the hyphens from what were previously the
"account-uri" and "validatio
> It seems the quickest way to address this is to remove the hyphens from the
> labels and continue progressing the doc.
>
> Hugo, can you do this in the next few days, or should we (chairs) find
> someone else?
Done.
___
Acme mailing list
ding
> Author : Hugo Landau
> Filename: draft-ietf-acme-caa-04.txt
> Pages : 9
> Date: 2018-05-27
>
> Abstract:
>The CAA DNS record allows a domain to communicate issuance policy to
>CAs, but only a
The specification as it stands seems to be a bit vague on the subject of
challenge retries.
It suggests that a challenge should be retried automatically by the server, and
that the challenge should remain in the "processing" state for this time. It
also states that the "invalid" state should
> I must admit that I'm not very familiar with DANE.
>
> What would be a typical use case where you use ACME but you don't
> already know the root cert?
Where DANE is used, a trust anchor is referenced by a hash of its public
key or certificate, which is placed in a DNSSEC-secured DNS record.
The current specification seems a bit ambiguous regarding whether a PEM
certificate chain includes the root CA certificate.
Most of the time the root CA shouldn't be included in a certificate
chain sent by a TLS server. However, there are circumstances in which it
is essential; namely, when DANE
My thoughts:
- Requiring an explicit action against the order after the fulfilment of
authorizations to cause issuance seems fine to me.
- I think moving the submission of the CSR to the end of this process is
a mistake.
The ACME protocol should permit CAs to implement policy as far as is
e here, is there? SSH uses
f...@example.com-type identifiers for extensions, but there's no
implication that only example.com will implement those extensions, on
the contrary. Nor is the XML namespace "http://www.w3.org/1999/xhtml; is
intended to only be used by the W3C.
It would be very helpful if
ding
> Author : Hugo Landau
> Filename: draft-ietf-acme-caa-03.txt
> Pages : 9
> Date: 2017-08-30
>
> Abstract:
>The CAA DNS record allows a domain to communicate issuance policy to
>CAs, but only a
Since the consensus seems to be to change to "validation-methods",
here's the wording I propose for the validation-methods section:
Extensions to the CAA Record: validation-methods Parameter
==
A CAA parameter "validation-methods" is
> > https://github.com/ietf-wg-acme/acme/pull/332
Alright, if the ACME spec wants to genericise its validation methods
registry, I'm okay with the validation-methods change as-is.
Questions:
1. Should we drop "non-acme", since any non-ACME method can have its own
identifier listed? I think
>On Thu, Jul 6, 2017 at 11:57 AM, Salz, Rich <[1]rs...@akamai.com> wrote:
>
> So let's see. Can we live with this?
>
> Create a spec-required registry for validation method names.
>
>I share Hugo's concern about divergence here. Should we maybe just put
>these in the
Since there was no objection on the list, I've incorporated the more
readable paragraph discussing the "account-uri" parameter. This is the
only change.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
> A CA MAY proceed with issuance if a CAA record is present whose value matches
> the account-uri parameter of the account making the request.
> If no CAA records have such a match, then the CA MUST NOT proceed with
> issuance.
This neglects to include the other criteria for validation of a CAA
> Like Russ, I find the statement very difficult to read. Would
> inverting it be better?
>
> > A CA MUST NOT issue authorize issuance if a CAA record is present unless
> > the "account-uri" parameter identifies the account making a certificate
> > issuance request.
See previous reply.
> Hugo, the CAA document is in WGLC. Russ raised the following issue on some
> text in section 2:
>
> . . . A CA MUST only consider a property with an "account-uri"
> parameter to authorize issuance where the URI specified is an URI
> that the CA recognises as identifying the account
>The idea is that as long as the challenge status is still "pending", the
>server is still retrying. Once it gives up, it marks the challenge as
>"invalid".
Bad idea. This prevents a server from supporting retries unless it
commits to continuously reverifying the challenge itself. A
>In reviewing a PR today noting that a client can find the account URI for
>a key pair using a new-account request with an empty payload [1], Jacob
>and I thought it might be a little more robust to use an explicit signal.
>I've posted a PR that adds a "recovery" field to indicate
Or that might be my usual overengineering.
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
I agree that end certificate data should be inlined in the certificate
object, rather than being hosted at a separate certificate URI, so long
as GET requests for order resources do not require authentication and
can thus be easily polled (which is currently the case).
I'm indifferent as to
This is a proposed change to enable challenges to be retried.
https://github.com/ietf-wg-acme/acme/pull/292
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
> I think the way CAs traditionally handle this is as you suggest: by
> making challenges retryable. Note that this implies that orders
> typically never get invalidated, they just expire after some period of
> time (or error out if there's a problem during issuance, like CAA). This
> also implies
t, insofar that it inflates the number of database objects
which must be generated and stored by a CA. It also increases the
time that the issuance process will take very substantially.
I'd prefer option 1. Thoughts?
Hugo Landau
___
Acme mailing list
A
> Have you seen the thread on the LAMPS (SPASM) mailing list, titled
> "CAA Erratum 4515"? That raises some technical issues, which make me
> (as an individual at least) think it's premature.
I wasn't aware of this.
However, as far as I'm aware mandatory CAA checking is now a done deal:
> > The CAA check is/was easy to make and crippling it
> > by not making it a requirement was IMNSHO a mistake.
> ...
> > I urge the WG to reconsider.
>
> Does anyone else agree with Viktor? Please speak up on the list this week if
> so.
I'd agree that the CAA check should be made mandatory.
and anything which isn't
> the above two categories) was within example.org.
--
Hugo Landau
I know of no warrant or notice of a kind defined within the Investigatory
Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not
been brought to the attention of the publi
On Fri, Feb 17, 2017 at 01:02:07PM -0800, Jacob Hoffman-Andrews wrote:
> Introduces an error field for orders. Orders can fail independent of
> authorizations because of last-minute CAA checking, failure to submit to
> CT logs, timeouts, etc.
--
Hugo Landau
I know of no warrant or no
domains. For example, the
ability to create unlimited numbers of secure origins has real value to
some classes of web application.
--
Hugo Landau
I know of no warrant or notice of a kind defined within the Investigatory
Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that h
tion.
>
> I suspect that this is by far not the case today. In fact many managed DNS
> servers still do not support this record type either.
I think it's implied that all security considerations applicable to CAA
are inherited by ACME-CAA. But the specification could probably stand to
be more cl
nt CAA records can specify
different methods.
Made use of single/double quotes more consistent.
Made use of term 'validation' vs. 'verification' more consistent.
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
}.
If a routing key isn't specified, a routing key of "default" can be used.
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
> One way to accomplish this in the protocol is to simply add a "ca-extension"
> object to the registration object, where the "ca-extension" object is an
> array of name-value pairs of strings. For example:
>
> {
> "protected": base64url({
>"alg": "ES256",
>"jwk": {...},
>"nonce":
> For "DNSName" authorizations, the same constraints still hold - there is
> a defined DNS name, and the challenges apply to that specific name.
This looks good. Only a slight nitpick — the label "DNSName" seems
out-of-kilter with the naming convention used by the rest of the
standard. "dns-name"
> One of the most common ACME deployment failures observed in practice is
> for servers to be configured to serve only the end-entity certificate,
> without the intermediate certificates. This is a particularly pernicious
> problem because some browsers will still trust the resulting
>
> The most likely out-of-band channel is email, right? So the CA would
> send out email informing their customers that there's a new ToS, and the
> customer needs to explicitly agree to it in the next N days, or they
> will be unable to use the service.
>
> There are a couple of options the CA
> I don't see a problem with having the directory show that the current
> ToS is "version 3", and the registration object show that explicit
> assent was obtained for "version 1", and leaving it up to the legal
> acrobatics in the text of version 1 to say that explicit assent isn't
> required for
If you're going to make this change I'd also consider changing
authorizations so that the failure of individual challenges is nonfatal
to the authorization if there are other challenges which could be
completed to satisfy the authorization. This would be useful in addition
to the ability to retry
I think the TOS URI mechanism should be preserved, and the specification
should be changed to state that if no new act of assent is required,
the URI stored in a registration should be updated to match it
automatically.
> I think this may be where we are not understanding each other. This is
>
at all
if the agreement is designed so that updates apply automatically. Each
version should probably have an immutable archival URI, but a single
fixed URI could point to the current version. Still, this needs to be
worked out in the spec.)
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Yes, I considered this. The first version of my proposal, which I didn't
publish, had a 'sufficient' parameter which makes the CAA step
sufficient rather than necessary.
I removed this because it seemed to me like a fundamental transformation
of the CAA record from a necessary to sufficient step,
Alright, here's the first draft.
https://hlandau.github.io/draft-landau-acme-caa/
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
This is already the case for HTTP, TLS-SNI and DNS challenges because
they are based on key authorizations which are based on account key
thumbprints. Did you have something else in mind?
Hugo Landau
On Fri, Feb 26, 2016 at 05:21:53PM -0800, Peter Eckersley wrote:
> If we're going to do acco
', would suffice in itself for authorization. This would
obviously require revision of CABF BR, but I was rather more ambivalent
about it because it changed CAA from a necessary to a sufficient step.
This doesn't do that; I think it fits well in the framework of CAA,
as opposed to some other proposals
he special token value if they wanted to
special-case deterministic authorization.)
Hugo Landau
On Thu, Feb 25, 2016 at 02:17:39PM -0700, J.C. Jones wrote:
> Hugo,
>
> There's a concept on the new DV ballot called a Request Token which could
> accomplish this: a structure somehow inc
; the response would then prove the server knew the token.
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
presentation functionality. The practicalities of that mechanism must be
considered.
On Fri, Jan 22, 2016 at 10:27:25AM -0800, Andrew Ayer wrote:
> On Fri, 22 Jan 2016 16:13:07 +
> Hugo Landau <hlan...@devever.net> wrote:
>
> > Firstly, I've drafted a specification for
/directory
Thoughts?
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
While developing a client, one minor consideration was remembering for
which hostnames authorizations have been obtained. My client remembers
the expiry date of authorizations so that it can avoid unnecessarily
requesting authorizations which have already been obtained.
A general princple of my
On Sat, Dec 05, 2015 at 07:10:43PM +0100, Niklas Keller wrote:
>Hello,
>what's the reason why "authorizations" and "certificates" are optional in
>registration objects? They should both not be optional IMO, because they
>can be used nicely to lower the load on the CA, because
I'd like to propose the following addition to the specification.
Any comments?
CAA Record Use
--
An ACME server SHOULD support CAA DNS records as described in
{{RFC6844}}. The server SHOULD look for such records when issuing
authorizations, as opposed to when issuing certificates.
> Is such a thing planned? Are there security reasons against doing
> this? Are there security reasons against doing this on a DNSSEC signed
> domain (which klausurschokola.de is)?
Personally, I wouldn't think it unreasonable to allow an ACME client to
request that a specific IP be used for the
On Mon, Nov 23, 2015 at 09:52:07AM -0800, Martin Thomson wrote:
> Could we ask IANA for a reserved system port (<1024)? Then it would
> be possible for an ACME client to operate without disturbing running
> services.
I wrote this on the github issue, but should have posted it here:
It seems
>If the issuer of the DNS challenge flushes its DNS cache and checks with
>the authoritative server itself, the propagation delay doesn't seem like
>an issue. Are there particular issuers/conditions for which you believe
>the issuer would have to rely on caching resolvers?
This
terministic
DNS response weakens this?
Binding to the public key would prevent the regular changing of keys. As
it is there's little reason not to generate a new key for each renewed
certificate request unless you're doing end-key pinning.
Hugo Landau
___
Ac
endorsement
of a given account key to represent the domain? This could be reverified
easily by subsequent authorizations.
Hugo Landau
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
new CSR (either from a previous CSR or from the
previous certificate), one option might be to allow a certificate URL to be
passed in new certificate requests instead of a CSR. Taking this route would
make certificate URLs immutable, removing the Content-Location complicat
75 matches
Mail list logo
