Re: [Acme] optional MIME parameter for application/pem-certificate-chain
I'm not sure how helpful this is, but we've typically found that allowing a client to specify certificate delivery in one of 3 formats addresses >99% of use-cases. I would shy away from connecting this to the MIME parameter and would prefer something along the lines of what Richard offered as an example. I also agree with this being WONTFIXed for the moment. Since the spec already allows the client to specify additional MIME values in the Accept header, such as application/x-pkcs7-certificates, application/pkix-cert, or application/x-x509-ca-cert, this may not need to be addressed by changes in the draft. If we wanted to be more prescriptive, however, a field that allows specifying one of the following delivery formats would provide some incremental value, imo: 1. A response as described in 7.4.2, but which only includes the end-entity. 2. A response as described in 7.4.2. 3. A response as described in 7.4.2, but which additionally includes the root. On Fri, Aug 10, 2018 at 10:50 AM Salz, Rich wrote: > In general, the root of a chain is often "out of band" and you don't send > it. The receiving party gets a cert chain, and validates everything to > make sure that it lists up to a root that is in their local trust store. > They maintain and decide what's in that trust store, via out-of-band > mechanisms. So while it could be an issue, in overall practice it usually > isn't. > > Hope this helps. > > > ___ > 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] WGLC comments: draft-ietf-acme-tls-alpn-01 (Re: Confirming consensus)
Thanks for taking a look. I’ve opened https://github.com/rolandshoemaker/acme-tls-alpn/pull/6/files to address most of these comments. For (4) the plan is to simply version it as suggested, that’s why we went with a two part OID with the base and then a versioned extension. If we need to rotate to a new algorithm we can simply increment that and define whatever new algorithm we want in another document. For (5) I agree with Martin, the input isn’t being duplicated across two different PRFs so there shouldn’t really be a problem here. Once these changes are merged I’ll send an email to Russ Housley to get the OID registered, I could swear I already did this but apparently not. > On Aug 8, 2018, at 7:31 PM, Sean Turner wrote: > > Couple of comments: > > 0) s2: Use the update text: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and "OPTIONAL" in this document are to be interpreted as > described in BCP 14 [RFC2119] [RFC8174] when, and only when, they > appear in all capitals, as shown here. > > 1) s3: For the base64URL safe text can you point to the base document; I > think it’s s6.1? > > 2) s3/s5.1: OID CLASH! id-pe 30 is already assigned. See: > https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 > > 3) s4: Insert obligatory reference to RFC4086 > (https://datatracker.ietf.org/doc/rfc4086/) for the randomness considerations > of the token. I’ll submit something against acme-acme so you may just be > able to borrow that. > > 4) General: How are you addressing the algorithm agility concerns raised in > BCP 201 (https://datatracker.ietf.org/doc/rfc7696/)? Is it just going to be > v2 if you need SHA-384? > > 5) General: Okay so I’m no cryptographer, but should the hash algorithm used > in the challenge correspond to the hash algorithm used in the PRF/HKDF? I > mean if I’m going to use TLS 1.3 and TLS_AES_256_GCM_SHA384 should I really > use SHA-256? > > 6) s5: I’d probably just add the following in s5. I think everybody knows > what’s going on, but it’s good to be specific: > > [[RFC Editor: please replace below by the RFC number.]] > > spt > >> On Jul 18, 2018, at 15:56, Salz, Rich >> wrote: >> >> For completeness, these are >>draft-ietf-acme-acme-13 >>draft-ietf-acme-tls-alpn-01 >>draft-ietf-acme-ip-02 >> >> From: Rich Salz >> Date: Wednesday, July 18, 2018 at 2:47 PM >> To: "acme@ietf.org" >> Subject: Confirming consensus >> >> As discussed in a separate thread, we added mandatory-to-implement JSON >> signing crypto (TLS 1.3 signing algorithms); note that this does not affect >> the certificates themselves. >> >> We decided to move draft-ietf-acme-tls-alpn and draft-ietf-acme-ip to >> working group last call. >> >> If you disagree with either of these decisions, please speak up by Monday. >> Note that the WGLC for the main document is being re-run in parallel with >> IESG and soon IETF review. >> >> >> ___ >> 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 mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] optional MIME parameter for application/pem-certificate-chain
In general, the root of a chain is often "out of band" and you don't send it. The receiving party gets a cert chain, and validates everything to make sure that it lists up to a root that is in their local trust store. They maintain and decide what's in that trust store, via out-of-band mechanisms. So while it could be an issue, in overall practice it usually isn't. Hope this helps. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] optional MIME parameter for application/pem-certificate-chain
My feelings are similar to Richard's. There are probably some niche
usecases for this feature that merit thought but I think it would benefit
from larger design discussion. Given that we're very close to finishing the
base specification and there hasn't been significant demand for this to
date I think it makes the most sense to defer for a follow up.
On Fri, Aug 10, 2018 at 9:16 AM, Richard Barnes wrote:
> Hi Felix,
>
> Thanks for reflecting this back to the list. The concrete implementation
> concerns are helpful.
>
> I'm concerned that the need here is more than just a simple MIME
> parameter. The MIME parameter is just an aspect of the media type; it just
> tells you what's in the object you're looking at. It sounds like for your
> use cases, you would also need a way for the client to *request* that the
> root be included. In fact, it's not clear to me that you need the MIME
> parameter if you have that.
>
> In addition, I think these concerns can be handled cleanly in an
> extension, e.g., by adding an optional field to the new-order object that
> requests the root cert be included.
>
> So while I'm not opposed to addressing this issue in general, I'll propose
> that we not address this in the base spec.
>
> --Richard
>
> On Fri, Aug 10, 2018 at 6:38 AM Felix Fontein ietf.org> wrote:
>
>> Hello,
>>
>> this came up in the discussion of
>> https://github.com/ietf-wg-acme/acme/issues/435 ("An optional MIME
>> parameter for application/pem-certificate-chain?"). I'm interested in
>> a reliable way to retrieve the root certificate, resp. the complete
>> certificate chain including a root certificate. This is sometimes
>> needed, for example for setting up an AWS ELB load balancer, or for
>> configuring OCSP verification in nginx, and also to simply verify the
>> validity of the returned chain down to the root.
>>
>> During the discussion in the Github issue, Logan Widick suggested a
>> boolean MIME parameter (with suggested name "includeroot") for
>> application/pem-certificate-chain.
>>
>> Since the issue (originally about another MIME parameter) is now
>> closed, I want to bring this suggestion up on the mailing list. My
>> suggestion would be that this parameter is optional (with no explicit
>> default value, i.e. the default is to do what the ACME server already
>> did before), and a formulation which suggests the server SHOULD respect
>> this parameter. I think the name "includeroot" is fine, but it could
>> also be "include-root" or something different.
>>
>> Are there any opinions on this?
>>
>> Thanks and best regards,
>> Felix Fontein
>>
>> ___
>> 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 mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] I-D Action: draft-ietf-acme-acme-14.txt
This version just addresses a bunch of small things found during IETF LC. EKR: I think this is ready for the IESG's consideration. Thanks, --Richard On Fri, Aug 10, 2018 at 9:24 AM 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 > Daniel McCarney > James Kasten > Filename: draft-ietf-acme-acme-14.txt > Pages : 88 > Date: 2018-08-10 > > Abstract: >Public Key Infrastructure X.509 (PKIX) certificates are used for a >number of purposes, the most significant of which is the >authentication of domain names. Thus, certification authorities >(CAs) 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 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. > >RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for >this draft is maintained in GitHub. Suggested changes should be >submitted as pull requests at https://github.com/ietf-wg-acme/acme >[1]. Instructions are on that page as well. Editorial changes can >be managed in GitHub, but any substantive change should be discussed >on the ACME mailing list (acme@ietf.org). > > > 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-14 > https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-14 > > > 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
[Acme] I-D Action: draft-ietf-acme-acme-14.txt
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 Daniel McCarney James Kasten Filename: draft-ietf-acme-acme-14.txt Pages : 88 Date: 2018-08-10 Abstract: Public Key Infrastructure X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) 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 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. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org). 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-14 https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-14 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] optional MIME parameter for application/pem-certificate-chain
Hello,
this came up in the discussion of
https://github.com/ietf-wg-acme/acme/issues/435 ("An optional MIME
parameter for application/pem-certificate-chain?"). I'm interested in
a reliable way to retrieve the root certificate, resp. the complete
certificate chain including a root certificate. This is sometimes
needed, for example for setting up an AWS ELB load balancer, or for
configuring OCSP verification in nginx, and also to simply verify the
validity of the returned chain down to the root.
During the discussion in the Github issue, Logan Widick suggested a
boolean MIME parameter (with suggested name "includeroot") for
application/pem-certificate-chain.
Since the issue (originally about another MIME parameter) is now
closed, I want to bring this suggestion up on the mailing list. My
suggestion would be that this parameter is optional (with no explicit
default value, i.e. the default is to do what the ACME server already
did before), and a formulation which suggests the server SHOULD respect
this parameter. I think the name "includeroot" is fine, but it could
also be "include-root" or something different.
Are there any opinions on this?
Thanks and best regards,
Felix Fontein
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
