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 <s...@sn3rd.com> 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 XXXX below by the RFC number.]] > > spt > >> On Jul 18, 2018, at 15:56, Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> >> wrote: >> >> For completeness, these are >> draft-ietf-acme-acme-13 >> draft-ietf-acme-tls-alpn-01 >> draft-ietf-acme-ip-02 >> >> From: Rich Salz <rs...@akamai.com> >> Date: Wednesday, July 18, 2018 at 2:47 PM >> To: "acme@ietf.org" <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
