> The server (ACME client) computer may be shared between various
> administrators. It may also have multiple DNS names and host multiple
> services. If I use ACME to get a certificate for a non-web service,
> like a CalDAV service (default https port = 8443). I do not want to
> touch or reconfig
> The current charter language about certificate revocation could be
> interpreted as raising the bar too high. I suggest that we can keep
> it simple.
>
> OLD:
>
> ACME certificate management must, in an automated manner, allow a
> party that has previously requested a certificate to subsequent
>> /me likes simple, and this revision
confession: it came out of a discussion in which i participated
> How about:
>
> "ACME certificate management must provide automated methods for
> revocation parallel to those use to request a certificate"?
what the heck does "parallel" mean? does it incl
>>> "ACME certificate management must provide automated methods for
>>> revocation parallel to those use to request a certificate"?
>>
>> what the heck does "parallel" mean? does it include means to revoke a
>> cert for which i have lost the private key and want to use an entirely
>> different pro
i say ship it now before some pedant such as i starts ranting about the
grammar. e.g.
> but other uses of certificates can be considered as work progresses.
s/can/may/
randy
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/ac
which is easier, going through kink on 443 or getting the IT security
team to punch a hole for ?
randy
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
>> which is easier, going through kink on 443 or getting the IT security
>> team to punch a hole for ?
> Would it help if you could choose the option that sucked least for
> your particular situation? That was what I was thinking.
yes, it would help
i admit to thinking of it as turning off a mag
> Isn't this precisely what .well-known was meant to address?
fun small research project. what percentage of well-known ports can
you connect to from the outside to a machine inside cisco? hell, to
what percentage of well-known ports outside cisco can you reach from
inside?
well-known does not
> The resolution of a certificate is the domain name, e.g. it is valid for
> all services on the machine.
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Au
> Let's Encrypt is still a future CA, not a current one.
it's in my browser and i even managed to get the client-from-hell to get
a few certs for some sites.
randy
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
>> Alright, here's the first draft.
>> https://hlandau.github.io/draft-landau-acme-caa/
> Can others in the WG read this and make a suggestion as to yes/no
> adopt? It's short (and the first para of 3.1 is a "did you read this"
> sentence fragment test? :)
excuse? i thought ietf wgs adopted inte
> https://datatracker.ietf.org/doc/draft-landau-acme-caa/
thanks. seems simple and makes sense.
randy, for adoption
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
>> That would just leave us wanting a way to also revoke certs that might
>> have been issued to an illegitimate key. But given the lag that OCSP
>> has, it might be reasonable to just auto-kill those too, since with
>> reasonable automation even a 'normal' key roll-over can probably get
>> new cer
> QUESTION: Should ACME support multiple CAs per ACME endpoint?
a major win in our never-ending search for complexity not justified by
'must have to get the plane off ther ground'
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo
14 matches
Mail list logo
