Thanks for the continued discussion, all! Replies to multiple emails inline.
On Tue, Sep 19, 2023 at 4:17 PM Ben Burkert wrote:
> The way we solve this is at the intermediate CA level, which we refer to
> as a SubCA. Each SubCA is an intermediate CA that issues end entity
> certs, and a template
Aaron,
Also (very) late to the game, and my experience is mostly with private CAs:
We have used certificate profiles for decades, but not with ACME. These
profiles are currently specified in a document called 'certificate
profiles'. Even in our most widely used systems (that issue to more than
My personal opinion here is that adding a profile field to the Order object
is likely to hamper client adoption, and as Ben just said, makes
configuration more difficult if CAs don't have matching profiles.
An alternative approach that I believe has been used is adding URL
parameters to the direct
Hello,
Apologies for chiming in late here; I'm with a startup that is just
coming out of stealth mode so I have been quietly following these
discussions. I bring this up because we build & operate ACME powered CAs
on behalf of users, and we've already introduced our own concept similar
to profiles
On Thu, Sep 07, 2023 at 05:12:57PM +0100, Q Misell wrote:
> I agree with what Aaron says about the difficulty in validating that a
> complex request from the client meets whatever requirements the CA is
> adhering to. I do however think that a simple list of profiles isn't the
> most suitable.
Can
k you very much for this proposal to extend ACME!
>
>
>
> /Rufus
>
>
>
> *Von: *Acme im Auftrag von Aaron Gable 40letsencrypt....@dmarc.ietf.org>
> *Datum: *Donnerstag, 31. August 2023 um 00:21
> *An: *IETF ACME
> *Betreff: *[Acme] Proposal: ACME Profiles
>
&g
, that every profile object must contain a URL to the
CP/CPS of the respective CA (or to the CCADB entry).
Thank you very much for this proposal to extend ACME!
/Rufus
Von: Acme im Auftrag von Aaron Gable
Datum: Donnerstag, 31. August 2023 um 00:21
An: IETF ACME
Betreff: [Acme] Proposal: ACME
On Thu, Aug 31, 2023 at 08:22:27AM -0700, Aaron Gable wrote:
> On Thu, Aug 31, 2023 at 2:09 AM Ilari Liusvaara
> wrote:
>
> > 1) There may be a number of orthogonal properties, causing the total
> >number of possible profiles be very large (the CA-side code is
> >NOT complex).
> >
>
> I'
On Thu, Aug 31, 2023 at 2:09 AM Ilari Liusvaara
wrote:
> 1) There may be a number of orthogonal properties, causing the total
>number of possible profiles be very large (the CA-side code is
>NOT complex).
>
I'm not super concerned with combinatorial explosions of profiles. A CA
could off
> For context, it was myself who was interested in ACME CAs advertising
their supported features via the directory or a capabilities endpoint,
my client has an unusual emphasis on multi-CA use and automated CA fallback.
The HTTPAPI working group just adopted a draft for "API catalogs" that might
On Wed, Aug 30, 2023 at 03:21:30PM -0700, Aaron Gable wrote:
>
> I believe it is time for us to seriously consider the topic of “profiles”.
>
> For the purposes of this discussion, a profile is a collection of
> characteristics which affect the contents of the final certificate issued
> by an ACM
Hi,
For context, it was myself who was interested in ACME CAs advertising
their supported features via the directory or a capabilities endpoint,
my client has an unusual emphasis on multi-CA use and automated CA fallback.
Aaron's proposal does actually complement that because in the future an
Hi ACME community,
I believe it is time for us to seriously consider the topic of “profiles”.
For the purposes of this discussion, a profile is a collection of
characteristics which affect the contents of the final certificate issued
by an ACME CA. For example, two different profiles might cause
13 matches
Mail list logo
