solution.
Thanks,
Yaron
Forwarded Message
Subject:New Version Notification for draft-sheffer-acme-star-02.txt
Date: Sat, 27 May 2017 13:06:24 -0700
From: internet-dra...@ietf.org
To: Oscar de Dios , Yaron Sheffer
, Thomas Fossati ,
Diego Lopez , Oscar Gonzalez de
I'm not sure I understand why the section that describes HTTP
validation so specifically forbids using HTTPS. On the other hand, I
can think of use cases where I would want *only* HTTPS
authorization:
- The server only supports HTTPS, and perhaps port 80 is blocked b
When we allow the issued certificate to revoke itself, this has major
implications, in particular for delegated certificates. But even for
regular certs, it is the account's private key that's more secure (it is
managed by the security personnel where such exist, it is not deployed
on multiple
t 11:32 AM, Yaron Sheffer <mailto:yaronf.i...@gmail.com>> wrote:
I'm not sure I understand why the section that describes HTTP
validation so specifically forbids using HTTPS.
This was because of the default-vhost attack.
https://ietf-wg-acme.github.io/acme/#rfc.section.1
In the "Applying for Certificate Issuance" section: the notBefore and
notAfter fields are not part of the CSR, and it is not clear if the
server is allowed to change them according to its own policy. E.g. for a
shorter period than requested.
Thanks,
Yaron
_
* Order Objects, "authorizations". The text says, "For final orders, the
authorizations that were completed." Are we using "completed" to mean
"successfully completed"? Maybe we should say so explicitly.
* Directory object: not wishing to be drawn into the TOS discussion
again, but I think the
On 30/05/17 18:48, Richard Barnes wrote:
On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <mailto:yaronf.i...@gmail.com>> wrote:
When we allow the issued certificate to revoke itself, this has
major implications, in particular for delegated certificates. But
even for regu
wrote:
"""
The server MUST return an error if it cannot fulfill the request as
specified, and MUST NOT issue a certificate with contents other than
those requested.
"""
https://ietf-wg-acme.github.io/acme/#rfc.section.7.4
On Tue, May 30, 2017 at 11:51
Yes, exactly.
On 30/05/17 18:49, Richard Barnes wrote:
That just argues for adding for an "https-06" (which is always HTTPS)
to go alongside "http-01" (which is always HTTP).
On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer <mailto:yaronf.i...@gmail.com>>
<mailto:r...@ipv.sx>> wrote:
On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer
mailto:yaronf.i...@gmail.com>> wrote:
When we allow the issued certificate to revoke itself, this has
major implications, in particular for delegated certificates. But
even for regular c
Resending, this post seems to have been lost in the noise. Should I open
a PR? Multiple PRs?
Thanks,
Yaron
On 30/05/17 18:52, Yaron Sheffer wrote:
* Order Objects, "authorizations". The text says, "For final orders,
the authorizations that were completed." Are we
Following on comments made in the interim meeting, I would like to
request the author to add a few paragraphs to clarify the use case(s) of
these IP-based certs and rev the draft, before we go into the adoption
discussion on the list.
Thanks,
Yaron
I opened PRs for my other comments, but this one is not editorial.
There's a long list of checks to be run by the CA for account key
roll-over, and the current check #8 is "Check that the “newKey” field of
the key-change object also verifies the inner JWS." I think that
requiring that "newKey"
Hi,
At the request of the WG chairs we split the document into two. One is
now a WG document: draft-ietf-acme-star-00
(https://datatracker.ietf.org/doc/draft-ietf-acme-star/). This is the
ACME extension that allows the ACME client to request recurrent, short
term certificates.
The second do
Hi Martin, Thomas,
Hi Martin,
Thanks for your review.
On 19/06/2017, 23:34, "Acme on behalf of Martin Thomson" wrote:
A few brief comments on this draft.
[snip]
I don't understand Section 3.3 at all. I'd recommend removing this
section. The DNO will decide what authorizations it requests
On 25/06/17 03:52, Martin Thomson wrote:
On 24 June 2017 at 02:24, Yaron Sheffer wrote:
Expires is to ensure that the certificate is not
cached beyond the point where a newer certificate will be issued. You
should remove this text.
OK
Is there some other common header to denote that the
/2017 08:32 AM, Yaron Sheffer wrote:
- The server only supports HTTPS, and perhaps port 80 is blocked by a
firewall. This situation applies to many REST endpoints.
This is in general a bad configuration. Leaving port 80 open for the
purposes of redirects is safe, and provides a better first-time
I support moving forward with the document.
However I think the treatment of the acme-methods (or
validation-methods) param is inconsistent, before and certainly after
Richard's PR. The original draft only allows ACME methods and the
special name "non-acme". This leaves the responsibility to e
licant, not
the CA. Is there a reason you would trust CA X to do "http-01" but not
CA Y? (I totally understand why "account-uri" is CA-specific, though.)
I would suggest pulling out "validation-methods" from being an
attribute to being a "tag" / &qu
The second paragraph is hard for me to parse. Let me try to reword it.
The presence of this parameter in a property further constrains
certificate issuance for that property. Whenever the parameter is
included in a property, a CA MUST NOT use any validation method unless
the method is explicit
- Clarify server side behavior on cancellation
Thanks,
Yaron
Forwarded Message
Subject: New Version Notification for draft-ietf-acme-star-02.txt
Date: Wed, 29 Nov 2017 06:56:16 -0800
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios , Yaron
Sheffer , Thomas
Subject: New Version Notification for draft-ietf-acme-star-03.txt
Date: Sat, 03 Mar 2018 12:29:30 -0800
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios , Yaron
Sheffer , Thomas Fossati
, Oscar de Dios
, Diego Lopez
, Antonio Agustin Pastor Perales
, Antonio Pastor
A new version
Hi Richard,
I think we're in a good place, even from a STAR perspective (where
certificates must be accessible with a GET, or the whole thing breaks
down). To clarify the behavior further, I suggest to add the following
text after the paragraph that says that "The server MAY allow GET
request
IMO Richard's proposal is too coarse, in the sense that servers may want
to publish some certificates with GET and others with POST-as-GET. So
either this should not be a server-wide flag, or if it is, it should be
augmented by a per-Order flag where the client can request what it needs.
Befor
...@ietf.org
To: Oscar Gonzalez de Dios , Yaron
Sheffer , Thomas Fossati
, Oscar de Dios
, Diego Lopez
, Antonio Agustin Pastor Perales
, Antonio Pastor
A new version of I-D, draft-ietf-acme-star-04.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository
: New Version Notification for
draft-sheffer-acme-star-delegation-00.txt
Date: Fri, 19 Oct 2018 19:29:33 -0700
From: internet-dra...@ietf.org
To: Yaron Sheffer , Thomas Fossati
, Antonio Agustin Pastor Perales
, Antonio Pastor
, Diego Lopez
A new version of I-D, draft-sheffer-acme-star
ting (2 weeks), seek shepherd, and then
send to IESG
- START-delegation; now is an ACME profile, after feedback
Call for adoption
Richard: This is what is set to the IdO for DNS challenge? Yaron: Yes.
Thomas Fossati: No, the DNS challenge is run just on the regular identifier
name (the &qu
Hi Alexey,
Overall, this seems to be workable and useful.
* In Sec. 3, definition of the format of the email address should
refer to RFC 5322 (specifically, Sec. 3.4.1) and not 5321.
* I've never seen "*" used to denote wildcards in the context of
45 AM, "Yaron Sheffer" wrote:
Alexey hasn't posted yet an updated version, and I edited the first part
of the minutes (the STAR portion only), now attached with my changes.
Chairs, please take a look, some of the changes are potentially
important, as they refe
Message
Subject: New Version Notification for
draft-sheffer-acme-star-delegation-01.txt
Date: Tue, 13 Nov 2018 12:39:45 -0800
From: internet-dra...@ietf.org
To: Yaron Sheffer , Thomas Fossati
, Antonio Agustin Pastor Perales
, Antonio Pastor
, Diego Lopez
A new version of I-D
owing my most recent comments on it.
STAR (Short-term Automatically Renewed Certs) - Yaron Sheffer
Proposed moving to publish; authors don’t feel a new WGLC is needed.
=> Chairs asked WG to read the current version, as an informal
alternative to a new WGLC.
Rescorla: My view is that the chan
...@ietf.org
To: Oscar Gonzalez de Dios , Yaron
Sheffer , Oscar de Dios
, Thomas Fossati
, Diego Lopez ,
Antonio Agustin Pastor Perales ,
Antonio Pastor
A new version of I-D, draft-ietf-acme-star-07.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.
Name
Subject: New Version Notification for draft-ietf-acme-star-delegation-01.txt
Date: Mon, 26 Aug 2019 23:17:15 -0700
From: internet-dra...@ietf.org
To: Yaron Sheffer , Thomas Fossati
, Antonio Agustin Pastor Perales
, Antonio Pastor
, Diego Lopez
A new version of I-D, draft-ietf-acme-star
Hi Ryan,
Apologies for the very late reply.
I accept your comments below, and we will reword this section as a
recommendation or best practice. The flexibility of CAA means that the solution
must be tailored to the particular CA(s) trusted by the IdO. This is
unfortunate in the sense that we
Agree on both points.
From: Ryan Sleevi
Date: Thursday, 10 October 2019 at 18:16
To: Yaron Sheffer
Cc: Thomas Fossati , Ryan Sleevi
, "acme@ietf.org"
Subject: Re: [Acme] Fwd: New Version Notification for
draft-ietf-acme-star-delegation-01.txt
On Thu, Oct 10, 2019
bmitted by Yaron Sheffer and posted to the
IETF repository.
Name: draft-ietf-acme-star
Revision: 10
Title: Support for Short-Term, Automatically-Renewed (STAR)
Certificates in Automated Certificate Management Environment (ACME)
Document date:
, "internet-dra...@ietf.org" wrote:
A new version of I-D, draft-ietf-acme-star-delegation-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.
Name: draft-ietf-acme-star-delegation
Revision: 02
Title:
On 3/8/20, 22:41, "internet-dra...@ietf.org" wrote:
A new version of I-D, draft-ietf-acme-star-delegation-03.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.
Name: draft-ietf-acme-star-delegation
Revi
It would not be the first time people confused Yoav and myself. I am honored...
Yaron (me) is not planning to be there, I am banned by both my company and my
government.
Re: STAR, Rich didn't get it completely right: the base STAR is in AUTH48 and
might actually get published in the next day or
On 8/25/20, 15:20, "internet-dra...@ietf.org" wrote:
A new version of I-D, draft-ietf-acme-star-delegation-04.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.
Name: draft-ietf-acme-star-delegation
Revision: 04
Hi Roman,
Thank you for the detailed review. We will go through your comments and will
rev the document accordingly, but in the meantime, let me respond specifically
to the issue of the CSR template syntax.
The CSR template is potentially a long/complicated JSON document (example:
[1]), and we
This version addresses Roman's (rather extensive) AD review. Thank you Roman!
Regards,
Yaron
On 2/21/21, 20:27, "internet-dra...@ietf.org" wrote:
A new version of I-D, draft-ietf-acme-star-delegation-05.txt
has been successfully submitted by Yaron Sheffer an
n-schema-07]. Practically, implementers ignore the CDDL
and use the more assessible JSON. I appreciate this approach is additional
work and pulls in another "technology" that isn't a natural fit in the ACME
ecosystem.
Do you see any alternatives?
Regards,
Roman
Hi Russ,
Please see the remaining open issues from your review - we have reopened the
GitHub issues:
https://github.com/yaronf/I-D/issues/139
https://github.com/yaronf/I-D/issues/145
https://github.com/yaronf/I-D/issues/146
https://github.com/yaronf/I-D/issues/147
https://github.com/yaronf/I-D/i
I-D, draft-ietf-acme-star-delegation-07.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.
Name: draft-ietf-acme-star-delegation
Revision: 07
Title: An ACME Profile for Generating Delegated Certificates
Docum
Hi Francesca,
Thank you for your review and for getting the CBOR community and Carsten
involved.
We will be tracking your comments here: https://github.com/yaronf/I-D/issues/173
And Carsten's review of CDDL and JSON Schema here:
https://github.com/yaronf/I-D/issues/170
Thanks,
Yaron
We have already addressed the GenArt comments, thank you Suresh!
I will respond to Lars's review separately.
Yaron
On 4/6/21, 15:52, "Lars Eggert" wrote:
Suresh, thank you for your review. I have entered a Discuss ballot for this
document based on my own review.
Lars
>
Hi Lars,
Thank you for your review. We will be tracking your comments at
https://github.com/yaronf/I-D/issues/168 (the Discuss) and
https://github.com/yaronf/I-D/issues/169 (all other comments).
Yaron
On 4/6/21, 15:41, "Lars Eggert via Datatracker" wrote:
Lars Eggert has entere
Thank you Éric for your review. We will be tracking it here:
https://github.com/yaronf/I-D/issues/176
Yaron
On 4/8/21, 00:02, "Éric Vyncke via Datatracker" wrote:
Éric Vyncke has entered the following ballot position for
draft-ietf-acme-star-delegation-07: No Objection
Wh
This is a minor update to address a few remaining comments by Ben.
Thanks,
Yaron
On 6/11/21, 11:27, "internet-dra...@ietf.org" wrote:
A new version of I-D, draft-ietf-acme-star-delegation-09.txt
has been successfully submitted by Yaron Sheffer and posted to th
*Overstepping the Technical Boundaries.* As it was pointed out during
the BoF, the proposed initiative does not address any technical issue,
but, instead, is pushing a specific BUSINESS model. I found very
inappropriate the examples of "I could not get my certificates in 45
minutes.." as this is a
Hi Scott,
On 03/31/2015 01:22 AM, Scott Rea wrote:
G'day Yaron,
I will make 2 brief observations:
a) Max and I actually proposed some usability focused work around TLS
certs to the PKIX WG about 6 or 7 years ago, when PKIX was still going
strong, and we were told that usability is not the purv
The title says it all. People have been using serial numbers for
ages to identify the cert (and yes, we all know the problems with
revocation). Why not keep it like that?
Thanks,
Yaron
___
Acme mailing list
Acme@ie
(Resending, sorry about the HTML mail)
The title says it all. People have been using serial numbers for ages to
identify the cert (and yes, we all know the problems with revocation).
Why not keep it like that?
Thanks,
Yaron
___
Acme mailing lis
Many clients will want to fail if the CA decides to "go offline". I
think logic that keeps state on the CA is too complex. Better to allow
the client to say "if offline validation is needed, please fail the
whole transaction".
Thanks,
Yaron
In the context of the LURK BoF, I've been thinking about using (an
extension of) ACME to issue short-term certificates to a CDN, so
that the CDN would not need a copy of the origin server's long-term
private key. I believe that this is reasonably easy to do, but what
I do
But that wasn't my question. I understand how a CDN and ACME can
co-exist. My question was how to prevent a malicious CDN from creating a
"black" certificate for my server as soon as they control the content on
www.example.com. The ACME draft has some text around this problem in
Sec. 10.2, but
On 04/11/2016 08:39 PM, Jacob Hoffman-Andrews wrote:
On 04/11/2016 08:23 AM, Yaron Sheffer wrote:
But that wasn't my question. I understand how a CDN and ACME can
co-exist. My question was how to prevent a malicious CDN from creating
a "black" certificate for my server as soon
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
Hi,
At the LURK BoF this week there was some interest in having a solution
where a domain owner can delegate to some other entity (which we will
call "the TLS server") the authority to terminate TLS connections on its
behalf, using short-term certificates. These certificates allow the
domain owne
On 20/07/16 13:04, Carl Wallace wrote:
On 7/20/16, 5:51 AM, "Acme on behalf of Yaron Sheffer"
wrote:
Option 2 could take the form of a non-critical extension. The flow could
be something along these lines:
- TLS server generates a key pair and sends request for delegation tic
On 20/07/16 14:43, Niklas Keller wrote:
2016-07-20 11:51 GMT+02:00 Yaron Sheffer mailto:yaronf.i...@gmail.com>>:
Hi,
At the LURK BoF this week there was some interest in having a solution
where a domain owner can delegate to some other entity (which we will
call "the
On 20/07/16 13:07, Tom Ritter wrote:
On 20 July 2016 at 04:51, Yaron Sheffer wrote:
4. Option 1 looks to the ACME server as a normal cert request, and
therefore will swamp the CT logs with lots of short-term certs. With
Option 2, we can log to CT the issuance of the delegation ticket instead
.
Thanks,
Yaron
On 20/07/16 17:43, Andrew Ayer wrote:
On Wed, 20 Jul 2016 11:51:57 +0200
Yaron Sheffer wrote:
Second, I would like the group's advice in choosing between two very
different approaches to this problem.
I prefer option 1, but with a tweak. I think the server should only
Hi Carl,
I agree to both your points in principle, but see Rich's mail.
Thanks,
Yaron
On 20/07/16 17:46, Carl Wallace wrote:
On 7/20/16, 11:32 AM, "Yaron Sheffer" wrote:
Hi Carl,
I think this could work, but I believe there are use cases
(specifically, CDNs) wher
Hi Chris,
The LURK CDN use case is described here:
https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-02#section-5.3
Personally I care more about the case of the TLS server being part of
the cloud infrastructure (e.g. Amazon ELB or even an on-premise F5 box),
and talking to enterprise
On 21/07/16 12:03, Chris Drake wrote:
Hi Yaron,
The premise seems wrong:
These certificates allow the domain owner to terminate the TLS server's
authorization when necessary,
What that is technically true, it does not facilitate the *purpose* of
the termination (which would be to prevent con
On 21/07/16 12:36, Sean Leonard wrote:
On Jul 20, 2016, at 2:51 AM, Yaron Sheffer wrote:
Option 2: Certificate Delegation
This option moves more of the responsibility to the ACME server.
1. Domain owner contacts the ACME server and obtains a "delegation
ticket" which is specific
On 22/07/16 12:56, Richard Barnes wrote:
On Fri, Jul 22, 2016 at 12:52 PM, Yaron Sheffer mailto:yaronf.i...@gmail.com>> wrote:
On 21/07/16 12:36, Sean Leonard wrote:
On Jul 20, 2016, at 2:51 AM, Yaron Sheffer
mailto:yaronf.i...@gmail.com&g
On 22/07/16 13:21, Chris Drake wrote:
Hi Yaron,
Best I can tell, everyone has jumped onto solving a cool problem,
without there actually being any reason to solve it?
I asked about the use case, and CDN authority revocation was all I got
(imho a really *weak* reason). Maybe I got it wrong?
Wh
I think we are slowly but surely getting into the weeds on this one.
When we talk about "CDN revocation" (for lack of a better term), we mean
that after a certain date, the owner of the content:
- Does not want the CDN, or a rogue employee of the CDN, to present the
content as an authoritative
/easy
(especially as a cdn will normally have a maxed out san cert on each ip to
enable swapping/loadbalancing reassigning domains to servers on the fly, and
thus 1 customer demanding a 2 day renewal basically causes all to be 2 day
renewal)
at 17:38 25/07/2016 Monday, Yaron Sheffer wrote:
I
From: Hugo Landau
To: Richard Barnes
Cc: acme@ietf.org
Subject: Re: [Acme] URI-based CAA account binding
Message-ID: <20161003002918.ga5...@andover.lhh.devever.net>
Content-Type: text/plain; charset=iso-8859-1
Thanks for the draft, Hugo.? In general, the idea of making CAA more
precise s
Hi,
In the security considerations, specifically 5.6, we omit the trivial
but most pertinent risk: the CAA record type must be implemented by all
CAs in order to be fully effective. Any CA that does not honor CAA can
potentially (mis-)issue a rogue cert for the domain in question.
I suspect
From: Karthikeyan Bhargavan
To: Ray Cheng
Cc: "acme@ietf.org" , Jacob Hoffman-Andrews
Subject: Re: [Acme] Proposal for adding arbitrary CA-specific
name-value pairs to registration object
Message-ID:
Content-Type: text/plain; charset=utf-8
It is worth noting that ?external_sec
Fulfilling my promise made the other day ? A PR to address the CAA issue.
Rich's new text reads as follows: "Further, an ACME-based CA can use the
Certification Authority Authorization record {{!RFC6844}} to prevent it
from being misdirected and generate an unauthorized issuance."
IMHO we
Date: Fri, 31 Mar 2017 09:07:14 +0300
From: Ilari Liusvaara
To: "Dr. Pala"
Cc: acme@ietf.org
Subject: Re: [Acme] draft-shaffer-acme-star-lurk: key lifetime ?
Message-ID:
<20170331060714.ga26...@lk-perkele-v2.elisa-laajakaista.fi>
Content-Type: text/plain; charset=utf-8
On Thu, Mar 30, 2
Version Notification for draft-sheffer-acme-star-00.txt
Date: Wed, 19 Apr 2017 13:17:46 -0700
From: internet-dra...@ietf.org
To: Oscar Gonzalez de Dios , Oscar
de Dios , Diego Lopez
, Thomas Fossati , Yaron
Sheffer
A new version of I-D, draft-sheffer-acme-star-00.txt
has been successfully
78 matches
Mail list logo
