Re: [Acme] Proposed ACME Charter Language
On Wed, May 13, 2015 at 7:36 PM, Ted Hardie ted.i...@gmail.com wrote: On Wed, May 13, 2015 at 4:22 PM, Randy Bush ra...@psg.com wrote: 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 proof of ownership/control? To me it means if you prove control of a domain in order to request a cert by methods 1, 2, or 3, then you can request revocation if you can prove control by the same set of methods. and what if i can prove control by method 42? So, the point I'm getting at is that the system ought to provide an automated way to request revocation if the requester can meet the same bar as it would take to request or renew a certificate. If 42 is one of the ways to meet that bar, well and good. If 42 is not one of the ways to meet the original bar, then putting effort to automating revocation on that basis seems off to me. I'm not particularly interested in automating revocation on the basis that someone has a court order, for example, even if that would be a method to prove you are an authorized party. Sure, you can hand the CA a court order, but they should look at it careful like, not automate the revocation. The length of this paragraph is why I liked Russ's first revision (allow an authorized party to request revocation). Ultimately, the CA is going to have some policy about who it allows to revoke. The protocol needs to provide authentication of the requestor to support that policy decision, but beyond that, the policy is up to the CA. --Richard I do not think it means that you have to pick the same one from the set, but it is something for the working group to discuss. which is one of the reasons russ's phrasing was so good; it left it for the wg to discuss and did not overly constrain the space. I think I want a wee bit more constraining here than you do. Is there language you like better for that? yes, russ's randy, who has had his say I'm hardly going to fall on a sword over this, but I wanted to explain why I see the issue worth discussion now. Ted ___ 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] Proposed ACME Charter Language
On Wed, May 13, 2015 at 7:39 PM, Salz, Rich rs...@akamai.com wrote: https://github.com/letsencrypt/acme-spec/issues I'd prefer if we just recorded issues there, but discussed them in the mailing list. I would prefer if we avoid getting into practices and policy issues there as well. An IETF working group has a finite lifetime and a limited constituency. Both make it a bad place to decide security policy. We write 'Security Considerations' not 'Security requirements'. Validation processes are like algorithms. The IETF can recommend but can't make a final decision. I think we all agree that it would be a bad thing if RFC5280 had made SHA-1 support a MUST and that this has in effect been superseded and this is a good thing. I don't think we are very likely to be changing crypto algorithms very frequently in the future. We seem to have a grip on those. But validation processes seem to me to be something that are not just likely to change, we would want to keep a watchful eye on. It isn't even the case that stronger validation mechanisms are necessarily better or necessarily necessary. We are going to a world where security is going to be required and insecurity becomes the exception. We are not going to a world where perfect security is required though. If 'some' security is required we can get rid of the low assurance security signal (aka padlock icon) and replace it with a danger signal. for no security. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Proposed ACME Charter Language
On Wed, May 13, 2015 at 11:39:36PM +, Salz, Rich wrote: https://github.com/letsencrypt/acme-spec/issues I'd prefer if we just recorded issues there, but discussed them in the mailing list. Folks should also be aware that because letsencypt needs to move fast to get working and interoperable clients and servers for its launch, there's a fair chance that it will wind up with a deployed solution that diverges from the draft spec in various ways, and can't block on an IETF WG's deliberations. For that reason I think it's probably best if the WG and spec work doesn't start in earnest until after Let's Encrypt has launched (IIRC that was the consensus in Dallas, too). And in the pre-launch period, a bug tracker is the most efficient and practical way for us to keep track of things that we absolutely need to fix/diverge from the draft spec on. -- Peter Eckersleyp...@eff.org Chief Computer Scientist Tel +1 415 436 9333 x131 Electronic Frontier FoundationFax +1 415 436 9993 ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Proposed ACME Charter Language
On 13 May 2015 at 16:39, Salz, Rich rs...@akamai.com wrote: I'd prefer if we just recorded issues there, but discussed them in the mailing list. I'd go further and treat that as a private enterprise. They might help track our issues for us, but until we have an official tracker, it has no real standing. ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Proposed ACME Charter Language
Hi Russ, On 20/04/15 17:11, Russ Housley wrote: Stephen: If that paragraph were removed, would you be happier with the charter? If so, consider it gone. I would be happier yes. But I think we're better off having the discussion now, before chartering, since otherwise we may end up re-doing it a number of times. If that discussion ends up with rough consensus for a don't duplicate position then text such as you propose would be correct. If that discussion ends up with rough consensus on a duplicate away, earlier efforts failed position then it'd probably be a good idea to say so in the charter text. (So, your bit of puzzling text is very useful in the end - it may force us to get this out of the way early.) I'm willing to assume that an attempt to replace things that people are using will meet with vigorous discussion. Right. People are using CMC, but not afaik when dealing with any public CAs for getting certificates for public Internet services. I think CMP has some similar but much smaller set of real uses. (*) And I'm not sure if EST has gotten traction. SCEP has uses but that's another kettle of cans of worms and fish;-) I think it would be better to have the vigorous discussion about CMC vs.ACME-JSON-etc (if that's the one we need to have) before we form the WG. But is that in fact the meat of your concern here? If so, then I assume you'd be arguing for use of CMC/CRMF PDUs in ACME messages. If not, I'm not back to being puzzled. Can you clarify? Cheers, S. (*) Last I checked, there still were a set of real users of CMP that meant it would be wrong to declare it HISTORIC. If that's changed since, it might be a fine thing to do though, and I'm happy to help there, so if anyone has info please let us know, though that'd be better done via mail on the pkix list (and then saag) and not here. Russ On Apr 20, 2015, at 12:05 PM, Stephen Farrell wrote: On 20/04/15 16:57, Russ Housley wrote: Stephen: I did not see the ACME effort as trying to throw everything out. If it is not used, then I don't think we're throwing it out:-) Rather, throw out the parts that have been an impediment to the kind of automation proposed by ACME, but document the shortcoming. Sorry, I'm still not getting it. I don't see any need for ACME to document why CMP etc failed or what was wrong with CMP that may have caused it to fail. And the same for CMC etc. BTW by fail here I mean: not used by the major deployed PKIs on the public Internet. I also see no need at all to even try to re-use ASN.1 PDU structures that are defined in CRMF etc. I do think that ACME ought learn from the past of course, and am confident that there will be enough participants involved who have that history for that to not be problematic. But I do not think ACME ought be required to re-use any ASN.1 PDU definitions from any previous RFCs on this topic. Do we agree or disagree on that last? (I'm trying to get to quite specific meanings for duplicate.) Cheers, S. Russ On Apr 20, 2015, at 11:43 AM, Stephen Farrell wrote: Hi Russ, This bit puzzles me a lot, other bits puzzle me a little:-) On 20/04/15 16:23, Russ Housley wrote: The ACME WG will not duplicate work from previous IETF certificate management efforts. If accepted, that would seem to me to nullify the entire effort. Can you explain why I'm reading it wrong? ACME absolutely will duplicate work from previous IETF certificate management efforts that have failed to get traction over the last decade and a half. That is entirely fine IMO and needs no explicit justification whatsoever since we have 15 years of crystal clear non-use, outside of niche environments. (It is true that what is now considered a niche was not so considered back then.) In fact I believe anyone who claims such duplication is a problem should be the one to provide evidence for that by documenting exactly why and at what scale. It is just not credible for us to pretend that CMC, CMP, or EST are widely used for certificate management on the public Internet. If I'm wrong there I would really love to see the evidence but absent such, duplicating bits of functionality present in current RFCs that are not at all widely used is what is needed for this effort and needs to be encouraged. I think we really ought bottom out on this aspect before chartering - it'd be dumb of us to charter an ACME WG that has to fight all the CRMF battles over again, or the ASN.1 vs. whatever issues. So I hope lots of voices chime in and say what they think. S. ___ 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
Re: [Acme] Proposed ACME Charter Language
Stephen: If that paragraph were removed, would you be happier with the charter? If so, consider it gone. I'm willing to assume that an attempt to replace things that people are using will meet with vigorous discussion. Russ On Apr 20, 2015, at 12:05 PM, Stephen Farrell wrote: On 20/04/15 16:57, Russ Housley wrote: Stephen: I did not see the ACME effort as trying to throw everything out. If it is not used, then I don't think we're throwing it out:-) Rather, throw out the parts that have been an impediment to the kind of automation proposed by ACME, but document the shortcoming. Sorry, I'm still not getting it. I don't see any need for ACME to document why CMP etc failed or what was wrong with CMP that may have caused it to fail. And the same for CMC etc. BTW by fail here I mean: not used by the major deployed PKIs on the public Internet. I also see no need at all to even try to re-use ASN.1 PDU structures that are defined in CRMF etc. I do think that ACME ought learn from the past of course, and am confident that there will be enough participants involved who have that history for that to not be problematic. But I do not think ACME ought be required to re-use any ASN.1 PDU definitions from any previous RFCs on this topic. Do we agree or disagree on that last? (I'm trying to get to quite specific meanings for duplicate.) Cheers, S. Russ On Apr 20, 2015, at 11:43 AM, Stephen Farrell wrote: Hi Russ, This bit puzzles me a lot, other bits puzzle me a little:-) On 20/04/15 16:23, Russ Housley wrote: The ACME WG will not duplicate work from previous IETF certificate management efforts. If accepted, that would seem to me to nullify the entire effort. Can you explain why I'm reading it wrong? ACME absolutely will duplicate work from previous IETF certificate management efforts that have failed to get traction over the last decade and a half. That is entirely fine IMO and needs no explicit justification whatsoever since we have 15 years of crystal clear non-use, outside of niche environments. (It is true that what is now considered a niche was not so considered back then.) In fact I believe anyone who claims such duplication is a problem should be the one to provide evidence for that by documenting exactly why and at what scale. It is just not credible for us to pretend that CMC, CMP, or EST are widely used for certificate management on the public Internet. If I'm wrong there I would really love to see the evidence but absent such, duplicating bits of functionality present in current RFCs that are not at all widely used is what is needed for this effort and needs to be encouraged. I think we really ought bottom out on this aspect before chartering - it'd be dumb of us to charter an ACME WG that has to fight all the CRMF battles over again, or the ASN.1 vs. whatever issues. So I hope lots of voices chime in and say what they think. S. ___ 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
