Re: [Acme] Discovery of directory URL

[Alan Doherty]

I wouldn't be a fan 

At 19:02 12/03/2018  Monday, Azoff, Justin S wrote:
>I've been investigating the possibility of offering an ACME compatible 
>endpoint for local users
>to use to obtain certificates through our normal CA process.  One of the 
>issues I have identified
>is that if I were to run a local ACME server, every client would have to be 
>configured to point at it.
>Some clients only have a 'staging' flag, and don't even allow specifying the 
>full endpoint.

if the client is hardcoded for LE its not designed to be used with other acme 
services (so inappropriate to use with others)
most acme clients aren't as its configurable on all I've used 
and of those that are hardcoded for LE most are open source (so maintaining 
your own version hard coded for your private acme would be easy)

but as many users could/would 
A have multiple domains they obtain certs for (san certs)

user A (webserver admin at company providing web services for example ltd.)  
uses acme provider 1 for the public SAN for http covering www.example.com 
www.example.net www.example.org
(thus if any of these 3 specified a different provider by some dns method it 
messes with this)

B have potentially multiple acme servers that would be used by different 
clients for the same domain

user B (mailserver admin at company that provides/maintains mail serveces for 
example ltd. ) uses acme provider 2 for the public SAN for smtp-tls 
mx.example.com mx.example.net mx.example.org
public SAN for http covering webmail.example.com example.com example.net 
example.org mx.example.com mx.example.net mx.example.org  1 being a real site 
(the others being a 301 to www.whichever)
(thus any provider specified in example.com would break same)

C its much easier/faster to point a client at a single trusted(by you) acme 
server at setup than to modify potentially countless dns zones (or setting up 
local pinholes for customer zones just to override their choice of acme 
provider that your admin may disagree with)

D dns isn't a good place to put this sort of stuff IMHO

E even in the simple one domain small org scenario say all clients talk to 
private example.com  acme server to obtain internally valid certs
but the 1 in-house server needing to talk to LE (or some other) to get a 
publicly valid cert for www.example.com or mx.example.com etc can't because 
this record exists in in-house dns zone



>We could use a CAA record to prevent a cert from being issued using the 
>default LE endpoint, but
>it would be nice if we could have a SRV record similar to
>
>   _acmev2._tcp.example.org . acme.services.example.org
>
>that clients could use to auto discover what the appropriate directory 
>endpoint is.
>
>I could see one additional requirement that the SRV record must point
>to a server under the same domain.
>
>Is this a crazy idea?
>
>— 
>Justin Azofff
>
>___ 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

[Acme] Discovery of directory URL

[Azoff, Justin S]

I've been investigating the possibility of offering an ACME compatible endpoint 
for local users
to use to obtain certificates through our normal CA process.  One of the issues 
I have identified
is that if I were to run a local ACME server, every client would have to be 
configured to point at it.
Some clients only have a 'staging' flag, and don't even allow specifying the 
full endpoint.

We could use a CAA record to prevent a cert from being issued using the default 
LE endpoint, but
it would be nice if we could have a SRV record similar to

   _acmev2._tcp.example.org . acme.services.example.org

that clients could use to auto discover what the appropriate directory endpoint 
is.

I could see one additional requirement that the SRV record must point
to a server under the same domain.

Is this a crazy idea?

— 
Justin Azoff

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

Re: [Acme] Certificate chains including roots

[Martin Thomson]

The usage model I think we should aim for is where chains are used
as-is.  For instance, the chain is fed straight to the HTTPS server.
There is reasonably strong advice against sending trust anchor
certificates over the wire, and most software simply spools out
everything it is given.

I thought that we already had this discussion and concluded that roots
wouldn't be included.  That's consistent with the above.

Obviously that would leave this open to some discretion, but that's
OK.  For instance, during the period that a new CA has a
cross-signature on their root, they might include their own anchor for
maximum compatibility, but they might phase that out over time.  But
the CA is in a reasonable position to know when to move, and it isn't
as though this would prevent clients from adding or removing as they
see fit.

On Mon, Mar 12, 2018 at 3:14 PM, Jörn Heissler
 wrote:
> On Mon, Mar 12, 2018 at 16:01:24 +0100, Philipp Junghannß wrote:
>> But isn't the point of this proposal that the client CANNOT be expected
>> knowing the root like with DANE/TLSA'd servers with a custom root or
>> whatever?
>
> I must admit that I'm not very familiar with DANE.
>
> What would be a typical use case where you use ACME but you don't
> already know the root cert?
>
> ___
> 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] Certificate chains including roots

[Jörn Heissler]

On Mon, Mar 12, 2018 at 16:01:24 +0100, Philipp Junghannß wrote:
> But isn't the point of this proposal that the client CANNOT be expected
> knowing the root like with DANE/TLSA'd servers with a custom root or
> whatever?

I must admit that I'm not very familiar with DANE.

What would be a typical use case where you use ACME but you don't
already know the root cert?


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Certificate chains including roots

[Philipp Junghannß]

But isn't the point of this proposal that the client CANNOT be expected
knowing the root like with DANE/TLSA'd servers with a custom root or
whatever?

Am 12.03.2018 15:57 schrieb "Jörn Heissler" :

> On Mon, Mar 12, 2018 at 12:25:14 +, Hugo Landau wrote:
> >   1. Clarify the specification to state that the root certificate must
> >  always appear in the chain at the end. Clients should be advised to
> >  pop the root certificate if they are procuring certificate chains
> >  for non-DANE applications only. Failure to do so will result in
> >  unnecessary but harmless transmission of the root certificate
> >  during TLS handshakes.
> >
> >   2. Don't include the root certificate but provide a way to retrieve it,
> >  e.g. via a Link header.
> >
> >   3. Clarify the specification to state that the root certificate must
> >  not appear in the chain, and that roots must be retrieved using the
> >  AIA URL inside the final certificate in the chain if it is needed.
> >  This minimises the chance of clients for non-DANE applications
> >  messing up and provides a viable method for discovery of the root
> >  CA for applications which need it.
> >
> > I'd support option 1 or option 3 equally. Either way, I think this
> > should be clarified.
> >
> > Thoughts?
>
> There's one more option which I'd actually prefer.
>
>   4. Root certificate does not appear in the chain but it's expected
>  that clients already know it. E.g. look in /etc/ssl/certs/.
>
> Rationale is that the client shouldn't blindly trust that the chain
> received by the acme server is valid.
>
> ___
> 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] Certificate chains including roots

[Jörn Heissler]

On Mon, Mar 12, 2018 at 12:25:14 +, Hugo Landau wrote:
>   1. Clarify the specification to state that the root certificate must
>  always appear in the chain at the end. Clients should be advised to
>  pop the root certificate if they are procuring certificate chains
>  for non-DANE applications only. Failure to do so will result in
>  unnecessary but harmless transmission of the root certificate
>  during TLS handshakes.
> 
>   2. Don't include the root certificate but provide a way to retrieve it,
>  e.g. via a Link header.
> 
>   3. Clarify the specification to state that the root certificate must
>  not appear in the chain, and that roots must be retrieved using the
>  AIA URL inside the final certificate in the chain if it is needed.
>  This minimises the chance of clients for non-DANE applications
>  messing up and provides a viable method for discovery of the root
>  CA for applications which need it.
> 
> I'd support option 1 or option 3 equally. Either way, I think this
> should be clarified.
> 
> Thoughts?

There's one more option which I'd actually prefer.

  4. Root certificate does not appear in the chain but it's expected
 that clients already know it. E.g. look in /etc/ssl/certs/.

Rationale is that the client shouldn't blindly trust that the chain
received by the acme server is valid.


signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Certificate chains including roots

[Hugo Landau]

The current specification seems a bit ambiguous regarding whether a PEM
certificate chain includes the root CA certificate.

Most of the time the root CA shouldn't be included in a certificate
chain sent by a TLS server. However, there are circumstances in which it
is essential; namely, when DANE is used. As such, it's essential that a
client have some way to get the root certificate. Since the current
certificate retrieval protocol no longer uses link rel=up, the only way
with the specification as it stands is to always include the root
certificate in the chain.

Options:

  1. Clarify the specification to state that the root certificate must
 always appear in the chain at the end. Clients should be advised to
 pop the root certificate if they are procuring certificate chains
 for non-DANE applications only. Failure to do so will result in
 unnecessary but harmless transmission of the root certificate
 during TLS handshakes.

  2. Don't include the root certificate but provide a way to retrieve it,
 e.g. via a Link header.

  3. Clarify the specification to state that the root certificate must
 not appear in the chain, and that roots must be retrieved using the
 AIA URL inside the final certificate in the chain if it is needed.
 This minimises the chance of clients for non-DANE applications
 messing up and provides a viable method for discovery of the root
 CA for applications which need it.

I'd support option 1 or option 3 equally. Either way, I think this
should be clarified.

Thoughts?

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