Re: [Acme] AD review of draft-ietf-acme-acme

[Kathleen Moriarty]

Hi Richard,

On Mon, Oct 30, 2017 at 6:27 PM, Richard Barnes  wrote:
>
>
> On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty
>  wrote:
>>
>> Hi Richard,
>>
>> Thanks for posting the diff, I reviewed the changes and they look
>> good, but I have a couple of questions.  FYI - I had started looking
>> at the PR, but something came up, sorry for the delay and this was a
>> good reminder.
>>
>> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes  wrote:
>> > Hi Kathleen,
>> >
>> > Thanks for the review.  Some responses inline.  I've started a PR to
>> > respond
>> > to these comments here:
>> >
>> > https://github.com/ietf-wg-acme/acme/pull/345
>> >
>> > I agree with Daniel that we should hold off on IETF LC until we've
>> > addressed
>> > the issues around proactive issuance / caching of CSRs.  That may
>> > require a
>> > re-WGLC, but once that's closed, it should be safe to send to IETF LC.
>> >
>> >
>> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
>> >  wrote:
>> >>
>> >> Hello,
>> >>
>> >> Thank you to the editors and WG for your efforts on
>> >> draft-ietf-acme-acme, it's a well written and easy to understand
>> >> draft.  I do have a few comments, that need to be address by the
>> >> editors and SHEPHERD.
>> >>
>> >> Please review the idnits.  There are a few warnings that should be
>> >> correctable and can be addressed, but more importantly, it calls out
>> >> several downrefs that are not in the shepherd writeup.  These need to
>> >> be in the writeup and then also mentioned in the IETF last call
>> >> announcement (I'll make sure the latter happens).
>> >>
>> >> Here's my mostly editorial comments:
>> >>
>> >> Introduction:
>> >> It reads very well, but it would be helpful to those unfamiliar with
>> >> the work to explicitly state that ACME is about DV certificates.  The
>> >> first sentence of the last paragraph seems like the best place to add
>> >> this in.
>> >> Current text:
>> >>This document describes an extensible framework for automating the
>> >>issuance and domain validation procedure, thereby allowing servers
>> >>and infrastructural software to obtain certificates without user
>> >>interaction.
>> >> Proposed:
>> >>This document describes an extensible framework for automating the
>> >>issuance and domain validation procedure for DV certificates,
>> >> thereby allowing servers
>> >>and infrastructural software to obtain certificates without user
>> >>interaction.
>> >
>> >
>> > As others have pointed out, ACME is not just about DV.  PR has some
>> > clarification on this point.
>>
>> I see the text on uses in other PKI contexts in the introduction, but
>> don't see anything on the certificate types and out-of-band processes
>> (as is the case for the STIR use case Mary mentioned).  Maybe I'm
>> missing it, can you tell me where to look?
>
>
> I don't think you're missing anything.  What do you mean by "certificate
> types and out-of-band processes"?  How is that different from "other PKI
> contexts"?

I think by PKI-context, you mean the application of use, is that
right?  I am separating out the type of certificate (DV, EV, etc.) as
you have done in the second paragraph of the introduction.  When
reading the rest of the document, there isn't text that says what type
of certificate ACME produces without any additional processes
(out-of-band authentication/validation).  If you think about
administrators who operate servers (whatever the protocol) or even
those who may wish to incorporate ACME into a new application, they
will may have to figure out what level ACME provides as a default and
also know that there can be additional processes added to obtain
certificates types at a higher assurance level using ACME.  Since the
text already does a nice job of explaining the certificate types, this
should be an easy follow up that I think will be very helpful to
people outside of the IETF or who look at this in the future.

Maybe something like the following:

   Strictly following the automation enabled by ACME, DV certificates
are issued.
   Additional processes can be provided by the CA to increase the level of
   validation on an end entity to issue certificates at a higher
assurance level,
   for instance an EV certificate.  

Does that help?  Thinking about this in former roles and having been
to some conferences lately, I think being explicit about this will
help those trying to evaluate and deploy ACME.  They may look for
providers who meet the assurance levels they need knowing there are
options and understanding the baseline provided by this spec.

Thanks,
Kathleen


>
>
>>
>> >
>> >
>> >>
>> >> I do like how the introduction is framed as it’s clear the level of
>> >> security provided by the certificates issued via ACME.  Thanks for
>> >> that.
>> >>
>> >> The introduction should also make it clear that ACME can be used for
>> >> other services using DV 

[Acme] I-D Action: draft-ietf-acme-telephone-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : ACME Identifiers and Challenges for Telephone Numbers
Authors : Jon Peterson
  Richard Barnes
Filename: draft-ietf-acme-telephone-01.txt
Pages   : 8
Date: 2017-10-30

Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificate for telephonoe numbers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-telephone/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-telephone-01
https://datatracker.ietf.org/doc/html/draft-ietf-acme-telephone-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-telephone-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] I-D Action: draft-ietf-acme-service-provider-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : ACME Identifiers and Challenges for VoIP Service 
Providers
Authors : Mary Barnes
  Chris Wendt
Filename: draft-ietf-acme-service-provider-02.txt
Pages   : 9
Date: 2017-10-30

Abstract:
   This document specifies identifiers and challenges required to enable
   the Automated Certificate Management Environment (ACME) to issue
   certificates for VoIP service providers to support Secure Telephony
   Identity (STI).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-service-provider/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-service-provider-02
https://datatracker.ietf.org/doc/html/draft-ietf-acme-service-provider-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-service-provider-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD review of draft-ietf-acme-acme

[Richard Barnes]

On Mon, Oct 30, 2017 at 5:00 PM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> Hi Richard,
>
> Thanks for posting the diff, I reviewed the changes and they look
> good, but I have a couple of questions.  FYI - I had started looking
> at the PR, but something came up, sorry for the delay and this was a
> good reminder.
>
> On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes  wrote:
> > Hi Kathleen,
> >
> > Thanks for the review.  Some responses inline.  I've started a PR to
> respond
> > to these comments here:
> >
> > https://github.com/ietf-wg-acme/acme/pull/345
> >
> > I agree with Daniel that we should hold off on IETF LC until we've
> addressed
> > the issues around proactive issuance / caching of CSRs.  That may
> require a
> > re-WGLC, but once that's closed, it should be safe to send to IETF LC.
> >
> >
> > On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
> >  wrote:
> >>
> >> Hello,
> >>
> >> Thank you to the editors and WG for your efforts on
> >> draft-ietf-acme-acme, it's a well written and easy to understand
> >> draft.  I do have a few comments, that need to be address by the
> >> editors and SHEPHERD.
> >>
> >> Please review the idnits.  There are a few warnings that should be
> >> correctable and can be addressed, but more importantly, it calls out
> >> several downrefs that are not in the shepherd writeup.  These need to
> >> be in the writeup and then also mentioned in the IETF last call
> >> announcement (I'll make sure the latter happens).
> >>
> >> Here's my mostly editorial comments:
> >>
> >> Introduction:
> >> It reads very well, but it would be helpful to those unfamiliar with
> >> the work to explicitly state that ACME is about DV certificates.  The
> >> first sentence of the last paragraph seems like the best place to add
> >> this in.
> >> Current text:
> >>This document describes an extensible framework for automating the
> >>issuance and domain validation procedure, thereby allowing servers
> >>and infrastructural software to obtain certificates without user
> >>interaction.
> >> Proposed:
> >>This document describes an extensible framework for automating the
> >>issuance and domain validation procedure for DV certificates,
> >> thereby allowing servers
> >>and infrastructural software to obtain certificates without user
> >>interaction.
> >
> >
> > As others have pointed out, ACME is not just about DV.  PR has some
> > clarification on this point.
>
> I see the text on uses in other PKI contexts in the introduction, but
> don't see anything on the certificate types and out-of-band processes
> (as is the case for the STIR use case Mary mentioned).  Maybe I'm
> missing it, can you tell me where to look?
>

I don't think you're missing anything.  What do you mean by "certificate
types and out-of-band processes"?  How is that different from "other PKI
contexts"?



> >
> >
> >>
> >> I do like how the introduction is framed as it’s clear the level of
> >> security provided by the certificates issued via ACME.  Thanks for
> >> that.
> >>
> >> The introduction should also make it clear that ACME can be used for
> >> other services using DV certificates, not just HTTP.  This is
> >> mentioned in the Terminology section, but I think a clear sentence
> >> upfront would be helpful.
> >>
> >> Section 2: Nit/suggestion: Change the tense to read as a published RFC
> >> in the last paragraph, last sentence (take it or leave it).
> >> Current:
> >>Such close integration of ACME with HTTPS
> >>servers would allow the immediate and automated deployment of
> >>certificates as they are issued, sparing the human administrator from
> >>much of the time-consuming work described in the previous section.
> >> Proposed:
> >>Such close integration of ACME with HTTPS
> >>servers allows the immediate and automated deployment of
> >>certificates as they are issued, sparing the human administrator from
> >>much of the time-consuming work described in the previous section.
> >
> >
> > Done.
> >
> >
> >>
> >> IANA Section:
> >> Everything looks good except that RFC5226 has been obsoleted, so the
> >> new reference is RFC8126 and “specification required”
> >> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same
> >> thing, so using that is fine.
> >
> >
> > Updated reference.
> >
> >
> >>
> >> Security considerations:
> >> I think it would be good to mention here that they are DV certs so the
> >> reader understands from he introduction and this section the level of
> >> cert issued through ACME and doesn’t assume a higher level of
> >> assurance.
> >>
> >> s/ACME is a protocol for managing certificates/ACME is a protocol for
> >> managing DV certificates/
> >
> >
> > Given the discussion about DV, I don't think this change is appropriate.
> >
> >
> >>
> >> 10.1 - I know this is obvious to the people in the WG, but a reference
> >> to RFC7525 to properly configure TLS 

Re: [Acme] AD review of draft-ietf-acme-acme

[Kathleen Moriarty]

Hi Richard,

Thanks for posting the diff, I reviewed the changes and they look
good, but I have a couple of questions.  FYI - I had started looking
at the PR, but something came up, sorry for the delay and this was a
good reminder.

On Thu, Oct 19, 2017 at 12:45 PM, Richard Barnes  wrote:
> Hi Kathleen,
>
> Thanks for the review.  Some responses inline.  I've started a PR to respond
> to these comments here:
>
> https://github.com/ietf-wg-acme/acme/pull/345
>
> I agree with Daniel that we should hold off on IETF LC until we've addressed
> the issues around proactive issuance / caching of CSRs.  That may require a
> re-WGLC, but once that's closed, it should be safe to send to IETF LC.
>
>
> On Fri, Sep 22, 2017 at 4:14 PM, Kathleen Moriarty
>  wrote:
>>
>> Hello,
>>
>> Thank you to the editors and WG for your efforts on
>> draft-ietf-acme-acme, it's a well written and easy to understand
>> draft.  I do have a few comments, that need to be address by the
>> editors and SHEPHERD.
>>
>> Please review the idnits.  There are a few warnings that should be
>> correctable and can be addressed, but more importantly, it calls out
>> several downrefs that are not in the shepherd writeup.  These need to
>> be in the writeup and then also mentioned in the IETF last call
>> announcement (I'll make sure the latter happens).
>>
>> Here's my mostly editorial comments:
>>
>> Introduction:
>> It reads very well, but it would be helpful to those unfamiliar with
>> the work to explicitly state that ACME is about DV certificates.  The
>> first sentence of the last paragraph seems like the best place to add
>> this in.
>> Current text:
>>This document describes an extensible framework for automating the
>>issuance and domain validation procedure, thereby allowing servers
>>and infrastructural software to obtain certificates without user
>>interaction.
>> Proposed:
>>This document describes an extensible framework for automating the
>>issuance and domain validation procedure for DV certificates,
>> thereby allowing servers
>>and infrastructural software to obtain certificates without user
>>interaction.
>
>
> As others have pointed out, ACME is not just about DV.  PR has some
> clarification on this point.

I see the text on uses in other PKI contexts in the introduction, but
don't see anything on the certificate types and out-of-band processes
(as is the case for the STIR use case Mary mentioned).  Maybe I'm
missing it, can you tell me where to look?

>
>
>>
>> I do like how the introduction is framed as it’s clear the level of
>> security provided by the certificates issued via ACME.  Thanks for
>> that.
>>
>> The introduction should also make it clear that ACME can be used for
>> other services using DV certificates, not just HTTP.  This is
>> mentioned in the Terminology section, but I think a clear sentence
>> upfront would be helpful.
>>
>> Section 2: Nit/suggestion: Change the tense to read as a published RFC
>> in the last paragraph, last sentence (take it or leave it).
>> Current:
>>Such close integration of ACME with HTTPS
>>servers would allow the immediate and automated deployment of
>>certificates as they are issued, sparing the human administrator from
>>much of the time-consuming work described in the previous section.
>> Proposed:
>>Such close integration of ACME with HTTPS
>>servers allows the immediate and automated deployment of
>>certificates as they are issued, sparing the human administrator from
>>much of the time-consuming work described in the previous section.
>
>
> Done.
>
>
>>
>> IANA Section:
>> Everything looks good except that RFC5226 has been obsoleted, so the
>> new reference is RFC8126 and “specification required”
>> https://tools.ietf.org/html/rfc8126#section-4.6 still means the same
>> thing, so using that is fine.
>
>
> Updated reference.
>
>
>>
>> Security considerations:
>> I think it would be good to mention here that they are DV certs so the
>> reader understands from he introduction and this section the level of
>> cert issued through ACME and doesn’t assume a higher level of
>> assurance.
>>
>> s/ACME is a protocol for managing certificates/ACME is a protocol for
>> managing DV certificates/
>
>
> Given the discussion about DV, I don't think this change is appropriate.
>
>
>>
>> 10.1 - I know this is obvious to the people in the WG, but a reference
>> to RFC7525 to properly configure TLS 1.2 should be included to protect
>> against the mentioned attacks.  If you want to also reference TLS 1.3
>> and specify no 0-RTT that would be good too.  It’d be great to see
>> this get widely deployed, so there may be a number of newcomers
>> reading this to make their lives easier with cert
>> issuance/maintenance.
>
>
> I don't see how TLS configuration plays into the security considerations for
> ACME.  How you use the certificates you get from ACME is your business, and
> indeed, 

Re: [Acme] I-D Action: draft-ietf-acme-acme-08.txt

[Richard Barnes]

This just rolls up all of the PRs that we've landed since -07.  Shouldn't
be any surprises.

On Mon, Oct 30, 2017 at 3:50 PM,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Automated Certificate Management
> Environment WG of the IETF.
>
> Title   : Automatic Certificate Management Environment
> (ACME)
> Authors : Richard Barnes
>   Jacob Hoffman-Andrews
>   James Kasten
> Filename: draft-ietf-acme-acme-08.txt
> Pages   : 75
> Date: 2017-10-30
>
> Abstract:
>Certificates in PKI using X.509 (PKIX) are used for a number of
>purposes, the most significant of which is the authentication of
>domain names.  Thus, certificate authorities in the Web PKI are
>trusted to verify that an applicant for a certificate legitimately
>represents the domain name(s) in the certificate.  Today, this
>verification is done through a collection of ad hoc mechanisms.  This
>document describes a protocol that a certification authority (CA) and
>an applicant can use to automate the process of verification and
>certificate issuance.  The protocol also provides facilities for
>other certificate management functions, such as certificate
>revocation.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-acme-acme/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-acme-acme-08
> https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-08
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Daniel McCarney]

>
> Wouldn't it be a lot better not to do the validations at all if you can
> tell at new-order time that you're not going to be willing to issue?


Yes, that would be better in this one capacity. However I don't think it
comes close to justify the scaling issues associated with accepting the CSR
up-front, and as mentioned, there are other reasons why validations may
occur for an order that the CA isn't willing to issue at the time of
finalization.

There also isn't a CAA-PKP so we're bikeshedding about impact on features
that are both unspecified & unimplemented.

- Daniel / cpu

On Mon, Oct 30, 2017 at 3:33 PM, Richard Barnes  wrote:

>
>
> On Mon, Oct 30, 2017 at 10:15 AM, Daniel McCarney 
> wrote:
>
>> > Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key).
>> Implementing that without knowing the public key at validation time is
>> annoying.
>>
>> Can you expand on "annoying"?
>>
>> It seems completely possible to reject the order finalization message
>> based on a CAA-PKP property.
>>
>
> Wouldn't it be a lot better not to do the validations at all if you can
> tell at new-order time that you're not going to be willing to issue?
>
>
>
>> In-fact, we already have to be rechecking CAA for authorizations
>> validated more than 8 hours ago at the time of issuance so there must be
>> code in place to check CAA at finalization and clients must be prepared for
>> their order to be rejected at finalization based on CAA already.
>>
>> I don't see how this is any more annoying.
>>
>> - cpu
>>
>> On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara <
>> ilariliusva...@welho.com> wrote:
>>
>>> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote:
>>> >
>>> > The ACME protocol should permit CAs to implement policy as far as is
>>> > reasonably practicable with regard to the workflows around which the
>>> > protocol is organised. Providing the CSR up-front allows the CA to
>>> > predicate order processing on aspects of that CSR, both with regard to
>>> > the present protocol and any future extensions, both now and in the
>>> > future in ways that we can and cannot foresee. I don't think it's
>>> > appropriate to defer giving critical information to the CA until the
>>> > last minute due to a resource utilisation concern which LE has already
>>> > proven capable of dealing with, especially when the whole point of the
>>> > order flow in the first place was to provide more flexibility for CAs
>>> to
>>> > institute policy.
>>>
>>> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI
>>> key). Implementing that without knowing the public key at validation
>>> time is annoying.
>>>
>>> As to why one would want something like that, it would allow limiting
>>> trust on certficiate management system without deploying something as
>>> dangerous as HPKP.
>>>
>>>
>>>
>>> -Ilari
>>>
>>
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Daniel McCarney]

> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI key).
Implementing that without knowing the public key at validation time is
annoying.

Can you expand on "annoying"?

It seems completely possible to reject the order finalization message based
on a CAA-PKP property. In-fact, we already have to be rechecking CAA for
authorizations validated more than 8 hours ago at the time of issuance so
there must be code in place to check CAA at finalization and clients must
be prepared for their order to be rejected at finalization based on CAA
already.

I don't see how this is any more annoying.

- cpu

On Tue, Oct 24, 2017 at 10:17 AM, Ilari Liusvaara 
wrote:

> On Tue, Oct 24, 2017 at 02:45:01PM +0100, Hugo Landau wrote:
> >
> > The ACME protocol should permit CAs to implement policy as far as is
> > reasonably practicable with regard to the workflows around which the
> > protocol is organised. Providing the CSR up-front allows the CA to
> > predicate order processing on aspects of that CSR, both with regard to
> > the present protocol and any future extensions, both now and in the
> > future in ways that we can and cannot foresee. I don't think it's
> > appropriate to defer giving critical information to the CA until the
> > last minute due to a resource utilisation concern which LE has already
> > proven capable of dealing with, especially when the whole point of the
> > order flow in the first place was to provide more flexibility for CAs to
> > institute policy.
>
> Example: Suppose that CAA-PKP got added (restrict issuance on SPKI
> key). Implementing that without knowing the public key at validation
> time is annoying.
>
> As to why one would want something like that, it would allow limiting
> trust on certficiate management system without deploying something as
> dangerous as HPKP.
>
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Revisiting Proactive Issuance & new-order CSR

[Daniel McCarney]

Hi Hugo,

Providing the CSR up-front allows the CA to predicate order processing on
> aspects of that CSR, both with regard to the present protocol and any
> future extensions, both now and in the future in ways that we can and
> cannot foresee. I don't think it's appropriate to defer giving critical
> information to the CA until the last minute due to a resource utilisation
> concern which LE has already proven capable of dealing with


The open-ended policy accommodations you mention sound nice in theory but
at the start of this thread I offered concrete cases that suffer as a
result of this decision and I would like to see concrete use-cases used as
counter argument. Are there any CAs that have expressed interest in policy
decisions based on the CSR? If so, can they please explain in concrete
terms how they would *not* be able to do so with the CSR submitted at
finalization time?

This thread was specifically started because the LE implementation showed
that the current design would pose considerable problems with resource
utilization. I don't think it's appropriate to assume that in contradiction
to that direct experience it will be a problem LE is capable of dealing
with without more concrete suggestions as to how.

- cpu


On Tue, Oct 24, 2017 at 9:45 AM, Hugo Landau  wrote:

> 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
> reasonably practicable with regard to the workflows around which the
> protocol is organised. Providing the CSR up-front allows the CA to
> predicate order processing on aspects of that CSR, both with regard to
> the present protocol and any future extensions, both now and in the
> future in ways that we can and cannot foresee. I don't think it's
> appropriate to defer giving critical information to the CA until the
> last minute due to a resource utilisation concern which LE has already
> proven capable of dealing with, especially when the whole point of the
> order flow in the first place was to provide more flexibility for CAs to
> institute policy.
>
> A possible compromise would be to require the CSR to be submitted both
> on new-order and on finalization, but that's quite clumsy.
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme