Re: [Acme] draft-ietf-acme-star

2019-09-13 Thread Thomas Fossati
On 13/09/2019, 13:41, "Thomas Fossati" wrote: > It seems to me that this might still be possible modulo > recurrent-certificate-adjust (rcp) being upper bounded by > recurrent-cert-validity (rcv), i.e., slightly changing the calculations > in 3.5 like this: > > notBefore = nrd[i] - predating

Re: [Acme] draft-ietf-acme-star

2019-09-13 Thread Thomas Fossati
Thanks Richard for raising this and Ryan for taking the time to explain. On 11/09/2019, 17:52, "Ryan Sleevi" wrote: > I'm not Richard, but with respect to publicly trusted certificates, > issuing a certificate with a notBefore set prior to that certificate > was issued is seen as, minimally,

Re: [Acme] draft-ietf-acme-star

2019-09-12 Thread Roman Danyliw
Hi! > -Original Message- > From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Thomas Fossati > Sent: Thursday, September 12, 2019 7:38 AM > To: Salz, Rich ; Richard Barnes > Cc: IETF ACME ; Thomas Fossati > > Subject: Re: [Acme] draft-ietf-acme-star > >

Re: [Acme] draft-ietf-acme-star

2019-09-12 Thread Thomas Fossati
On 11/09/2019, 18:40, "Salz, Rich" wrote: > > the protocol is still correct/consistent. But, let's be bold as > > it's probably worth taking the risk :-) > > We can ask that the IESG/IETF do a simultaneous re-review period of > something like two weeks. Sounds good, thank you. IMPORTANT

Re: [Acme] draft-ietf-acme-star

2019-09-11 Thread Salz, Rich
>the protocol is still correct/consistent. But, let's be bold as it's probably worth taking the risk :-) We can ask that the IESG/IETF do a simultaneous re-review period of something like two weeks. Thanks. ___ Acme mailing list

Re: [Acme] draft-ietf-acme-star

2019-09-11 Thread Ryan Sleevi
On Wed, Sep 11, 2019 at 12:09 PM Thomas Fossati wrote: > 2 The pre-dating that the ACME server MUST do on cert rotation to > prevent the client to fetch a not-yet-valid credential (i.e., the > overlap you mention). > > IIUC, you are suggesting to drop the former, i.e., removing the ability >

Re: [Acme] draft-ietf-acme-star

2019-09-11 Thread Thomas Fossati
Hi Rich, Richard, (Merging both your emails into one reply.) On 09/09/2019, 23:57, "Salz, Rich" wrote: > I don't care about the STAR acronym not bring known by those who don't > know :) but I think Richard's comments – most of which are, really, > wordsmithing nits of message-field names –

Re: [Acme] draft-ietf-acme-star

2019-09-09 Thread Salz, Rich
: Richard Barnes Date: Monday, September 9, 2019 at 6:44 PM To: Thomas Fossati Cc: "acme@ietf.org" Subject: Re: [Acme] draft-ietf-acme-star On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati mailto:thomas.foss...@arm.com>> wrote: Hi Richard, Thank you for the detailed review. As y

Re: [Acme] draft-ietf-acme-star

2019-09-09 Thread Richard Barnes
On Mon, Sep 9, 2019 at 4:15 AM Thomas Fossati wrote: > Hi Richard, > > Thank you for the detailed review. As you note yourself, this is quite > late in the document life-cycle (the draft completed IETF LC over a > month ago), which is unfortunate, given that every one of your comments > is an

Re: [Acme] draft-ietf-acme-star

2019-09-09 Thread Thomas Fossati
Hi Richard, Thank you for the detailed review. As you note yourself, this is quite late in the document life-cycle (the draft completed IETF LC over a month ago), which is unfortunate, given that every one of your comments is an actual protocol change. As far as we understand, none of them can be

[Acme] draft-ietf-acme-star

2019-08-28 Thread Richard Barnes
I had a chance to take a look at this draft as a result of being a designated expert on the registries. I approved the registrations, but independently, I have several major concerns about the draft. In no particular order - The use of the "STAR" acronym is not helpful. This is not an acronym