Re: [Acme] POST-as-GET payload contents
I like using {} for the POST-as-GET payload as well.
Sincerely,
Logan Widick
On Tue, Sep 4, 2018, 12:26 Jacob Hoffman-Andrews wrote:
> New day, new thread for a specific issue I'd like to nail down quickly.
>
> > ISSUE 2: How should we signal that POST-as-GET request is different
> > from other POST requests?
> >
> > The current PR signals this by sending a JWS with an empty
> > (zero-octet) payload, instead of a JSON object. Jacob and Daniel
> > suggested that we should instead use the payload being an empty JSON
> > object as the signal. An earlier draft PR used a field in the
> > protected header.
>
> In short, this question is about whether POST-as-GETs should have:
>
> "payload": ""
>
> or
>
> "payload": "{}"
>
>
> When implementing the first one (empty payload), Daniel and I each
> separately implemented a different bug that would have also accepted:
>
> "payload": null
>
> This may be quirk of Go's handling of byte arrays, but it may turn out
> to be a common pattern in JSON libraries. The downside, if a server
> implementer landed a bug like that, would be that clients might get away
> with generating the invalid "null" form, leading to interoperability
> problems.
>
> There's also potential for client bugs that produce an empty payload
> simply due to an uninitialized field, rather than due to a POST-as-GET.
> This would produce confusing errors relating to GETs rather than a
> clearer "malformed input" error.
>
> Lastly, many clients already implement the "{}" form as a way to GET an
> account, so expanding the use of "{}" minimizes disruption.
>
> My preference is still for "{}" over "", but I am also willing to be
> convinced in the interests of landing this change speedily and keeping
> forward momentum.
>
> ___
> 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] Specify which JWS serialization is used
How about this: Specify a default format (either "application/jose" for
Compact Serialization, or "application/jose+json" with Flattened
Serialization - I have no preference which one), with optional support for
other formats if needed? Even with JOSE libraries that don't support all
serializations and/or don't provide control over which serialization is
used, a programmer would at least need to know (or experimentally find out)
if a JSON serialization or if the compact one is being produced. If a JSON
serialization is selected as the default, a programmer should be able to
convert between the two JSON serializations easily as needed before and/or
after using a JOSE library. If a JSON format is declared as the default but
the JOSE library only has the compact one, or vice-versa, conversion before
and/or after the JOSE library would be more complex but should still be
doable with guidance.
The directory meta item could be defined as something like:
- supportedSerializations: An array of supported serialization formats
as described in {{jws-serialization-formats}}. If this is not specified,
assume that the server only supports [insert selected default here].
Then, the JWS Serialization Formats section could be changed to something
like the following:
The JSON Web Signature (JWS) specification {{!RFC7515}} contains multiple
JWS serialization formats. When sending an ACME request with a non-empty
body, an ACME client implementation SHOULD use the HTTP Content-Type
{{!RFC7231}} header to indicate which JWS serialization format is used for
encapsulating the ACME request payload.
Each serialization format defined for use in ACME is described with a
content type, and a series of ACME-specific restrictions on root JWS and
nested JWS instances. A "root JWS" is a JWS used to encapsulate an entire
ACME request payload, and a "nested JWS" is a JWS contained within the ACME
request payload (such as the "externalAccountBinding" described in
{{external-account-binding}} or the "key-change" object described in
{{account-key-roll-over}}). Below are the JWS serialization formats that
are defined for use in ACME:
[same list as before but with the default format coming first]
If no Content-Type is provided, the default serialization type is [insert
selected default here]. Servers MUST support [insert selected default
here]. [NOTE: If a JSON format is selected as the default, say that a
server SHOULD support the other JSON format.] A server MAY support
additional serializations, such as [insert serialization(s) not picked
here], by including a "supportedSerializations" field in the directory
"meta" object as described in {{directory}}.
If a server receives a request using a serialization it does not support,
the server MUST send a response with HTTP status code 415 (Unacceptable
Media Type) and a problem document with error type
"unsupportedSerialization". This problem document SHOULD contain a
"supportedSerializations" array of strings indicating the acceptable
serialization content types.
[TODO: If a client uses the General JSON Serialization but it turns out the
server only supports the Flattened JSON Serialization (or vice-versa),
explain that a 415 response indicates that the client will need to switch
JSON formats]
[TODO: Insert a sentence or two specifying what happens if a supported
serialization is used but the serialization is malformed? Should this be
400 Bad Request + malformed error code + supportedSerializations?]
In the examples below, JWS objects are shown in the Flattened JSON
serialization, with the protected header and payload expressed as
base64url(content) instead of the actual base64-encoded value, so that the
content is readable. [Example readability is a very high priority
regardless of which serialization format is actually chosen as the default,
and the current convention of Flattened JSON + base64url(content) is about
as readable as it gets, so I don't think any changes will need to be made
here]
On Sun, Mar 4, 2018 at 8:33 AM, Jörn Heissler
wrote:
> On Sun, Mar 04, 2018 at 07:45:36 -0600, Logan Widick wrote:
> > Good catch. Should it be 415 (Unsupported Media Type) plus which of the
> > following (or which combination of the following):
> >
> >- A new problem document field (tentatively named
> >"supportedSerializations": an array of media type strings)?
> >- A new directory field (tentatively named "supportedSerializations":
> an
> >array of media type strings)?
> > - Should this go in the directory's "meta" object, or in the
> > directory object itself?
> >- A HTTP header?
> >- Something else?
>
> I like the directory approach with meta. Then a client could
> use this information before sending the first
Re: [Acme] Specify which JWS serialization is used
Good catch. Should it be 415 (Unsupported Media Type) plus which of the following (or which combination of the following): - A new problem document field (tentatively named "supportedSerializations": an array of media type strings)? - A new directory field (tentatively named "supportedSerializations": an array of media type strings)? - Should this go in the directory's "meta" object, or in the directory object itself? - A HTTP header? - Something else? Logan On Sun, Mar 4, 2018 at 6:58 AM, Jörn Heissler wrote: > On Fri, Mar 02, 2018 at 17:29:04 -0500, Richard Barnes wrote: > > > On Mar 2, 2018 9:47 AM, "Felipe Gasper" > wrote: > > > > > > Could there be some way of using a header like “Accept” for a server to > > > indicate whether it supports jose, jose+json, or both? > > On Fri, Mar 2, 2018 at 2:29 PM, Logan Widick > wrote: > > > > > I think the follow-on (#398) includes the Accept header in error > responses > > > (to requests with unacceptable serializations). > > > > > > > Indeed it does! > > The way I understand https://tools.ietf.org/html/rfc7231#section-6.5.6 > the 406 status and the Accept header are only valid to negotiate > server-to-client > content types. > > Is it really okay to use them for client-to-server? > I think code 415 "Unsupported Media Type" is more appropriate: > https://tools.ietf.org/html/rfc7231#section-6.5.13 > Together with an error document specifying the supported JWS > serializations. > > Cheers > Joern Heissler > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Specify which JWS serialization is used
I don't really have a preference for which serializations are used, as long as all ACME implementations (regardless of the programming language used) can support the chosen serializations, and new serializations can be added later if necessary. When I searched the listings on GitHub and jwt.io a month or two ago, I found some JOSE libraries that didn't support reading all serialization formats, and/or didn't provide programmers with control over the format produced. Thus, serialization may still be an issue unless one can convert between serializations before and/or after using such libraries. Here is a PR for one possible way to resolve the "root JWS" and "nested JWS" issue: https://github.com/ietf-wg-acme/acme/pull/403 . This PR includes the following: - Initial definitions of "root JWS" and "nested JWS" - Updated requirement for "root JWS" and "nested JWS" under the two currently defined content types (application/jose and application/jose+json) - Revisions to the registries already defined in the spec (to label nested JWS things as such and indicate that the actual types may change depending on the serialization formats used) - A new serializations registry (so that serializations can be added as needed) - I put it as a new registry under the "New Registries" section because it includes ACME-specific constraints on existing content types instead of new content types. - I have no experience adding new material to an IANA Considerations section. I'm not sure if I put the new material in the right place, formatted it correctly, included all required information (like what guidance, if any, should be provided), etc. If it is decided to change course and stick with one serialization format for now, I can make the following changes to this PR: - Clean up the "JWS Serialization Formats" section: - In PR #403 as it is today: - "One of the following Content-Type header values MUST be used to indicate the JWS serialization format" - This section includes a list describing the requirements for both JSON (Flattened and General) and Compact Serializations - To change course: - "The following Content-Type header value MUST be used to indicate the JWS serialization format" - Delete the unused serialization format from the list - Delete the unnecessary format from the new serializations registry Let me know what you think of this PR. Logan On Fri, Mar 2, 2018 at 4:51 PM, Jacob Hoffman-Andrews wrote: > > If you have suggestions here, a PR would be welcome. TBH, this issue kind > of makes me want to reverse course and say "all flattened JSON", but I get > the sense that other folks disagree? > > I'd be very much in favor of "all flattened JSON." When we started ACME, I > think there was some concern that libraries might support only Compact > Serialization (https://tools.ietf.org/html/rfc7515#section-7.1). But > experience has shown that Flattened JSON Serialization ( > https://tools.ietf.org/html/rfc7515#section-7.2.2) is pretty well > supported across languages. > > FWIW, Let's Encrypt's ACMEv2 endpoint only supports Flattened JSON > Serialization. > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Specify which JWS serialization is used
I think the follow-on (#398) includes the Accept header in error responses (to requests with unacceptable serializations). Also, there may need to be another follow-on regarding how to serialize "nested" JWS instances (like the externalAccountBinding and the inner JWS for a key change). Logan On Mar 2, 2018 9:47 AM, "Felipe Gasper" wrote: Could there be some way of using a header like “Accept” for a server to indicate whether it supports jose, jose+json, or both? -F > On Mar 2, 2018, at 9:50 AM, Richard Barnes wrote: > > Hey all, > > I merged #395 last night (thanks, Logan!). While I was reviewing that, I noticed that we need to cover the case where the client sends an encoding that the server doesn't understand. So I've posted a follow-on that adds an error code and requires its usage. LMK if you have any objections, otherwise I'll merge before submission on Monday. > > https://github.com/ietf-wg-acme/acme/pull/398 > > Thanks, > --Richard > > On Mon, Feb 12, 2018 at 2:37 PM, Logan Widick wrote: > I've created a new pull request (https://github.com/ietf-wg- acme/acme/pull/395) to partially address the lack of serialization format specification. This pull request requires use of the Content-Type HTTP header to indicate the serialization format of the outermost JWS. The pull request also includes restrictions on the serializations (no detached payload, no unencoded payload, no unprotected header, etc.). In addition, the pull request bans multiple signatures, regardless of the serialization used. The use of the Content-Type header, and the list of currently possible serializations, is mentioned in its own subsection of "Message Transport". > > The pull request does not contain advice on how to convert different serialization formats before and/or after use with a pre-existing JWS library. I have started on a separate conversion guide ( https://github.com/u2/jwe-jws-serialization-conversion-guide) for that purpose. > > The pull request does not specify how a "nested" JWS should be serialized. However, I have included an outline of one possible approach to this in the pull request's description. > > Please let me know what you think about the pull request ( https://github.com/ietf-wg-acme/acme/pull/395), and the separate conversion guide (https://github.com/u2/jwe-jws-serialization-conversion-guide) > > Logan > > On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick wrote: > Last night, I briefly surveyed the listings of JWT implementations on jwt.io. I could find only a small handful that appeared to support all serializations, and even fewer that appeared to give programmers control over what serialization was produced. Thus, assuming jwt.io is a sufficiently accurate and comprehensive listing of implementations of all and/or part of the JOSE specs, the developers of many ACME client and server implementations may find themselves needing to convert between serializations before and/or after using JOSE libraries. Such conversion processes, if needed, should be well-documented somewhere. > > I've started on a very rough draft of a possible JWS and JWE serialization conversion guide at https://github.com/u2/jwe- jws-serialization-conversion-guide. I made the conversion guide draft by copying a few items from the ACME GitHub repository (the Markdown file, the makefile, and the .gitignore), replacing the text from the Markdown file, and renaming the Markdown file. I designed the conversion guide draft to be non-ACME specific, so I've tried to include things like unencoded JWS payloads, JWEs, multiple signatures, detached payloads, etc. If you have any changes or suggestions, please let me know. > > Logan > > On Fri, Jan 5, 2018 at 7:11 PM, Jörn Heissler < acme-sp...@joern.heissler.de> wrote: > On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote: > > What do you think of the following: > > > Content type application/jose+json: MUST be supported. If used, the JWS > > will need to be in the Flattened or General serialization. Flattened MUST > > be supported; General MAY be supported. > > > Content type application/jose: MAY be supported. If used, the JWS MUST use > > the Compact serialization. Or should this content type not be allowed? > > Agreed. I wouldn't disallow "compact". And it could be clarified: > > The server SHOULD use the "Content-Type" HTTP header as an indication > for the request format. > > > JWS Unprotected Header: Not currently used in ACME. Should this be banned > > in ACME? > > I don't see much sense in those. But some client implementations might > automatically add an unprotected header like e.g. "cty". > Maybe with a "SHOULD NOT"? > > > Multiple signatures:
Re: [Acme] "Status" field clarification
Are challenge retries still supported? If so, how will retries affect the state transitions? What state would a server use to indicate that something had an error but could be retried later? Sincerely, Logan Widick On Mar 2, 2018 08:04, "Richard Barnes" wrote: Hey all, We had a couple of GitHub issues and mailing list posts expressing confusion about the "status" field in ACME objects. To try to clear all of that up, I've posted a PR that lays out required state transitions and aligns the field descriptions with that description. All the description should look very familiar. The only innovation is to introduce a "ready" state on orders, to give clients an easy way to know when to finalize. https://github.com/ietf-wg-acme/acme/pull/400 As you're probably aware the I-D deadline is Monday, so please send comments ASAP. If I don't hear anything back from this list, I'll confer with my fellow editors and we'll make a unilateral decision for us to discuss in London (and obviously roll back if needed). Thanks, --Richard ___ 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] Specify which JWS serialization is used
I've created a new pull request ( https://github.com/ietf-wg-acme/acme/pull/395) to partially address the lack of serialization format specification. This pull request requires use of the Content-Type HTTP header to indicate the serialization format of the outermost JWS. The pull request also includes restrictions on the serializations (no detached payload, no unencoded payload, no unprotected header, etc.). In addition, the pull request bans multiple signatures, regardless of the serialization used. The use of the Content-Type header, and the list of currently possible serializations, is mentioned in its own subsection of "Message Transport". The pull request does not contain advice on how to convert different serialization formats before and/or after use with a pre-existing JWS library. I have started on a separate conversion guide ( https://github.com/u2/jwe-jws-serialization-conversion-guide) for that purpose. The pull request does not specify how a "nested" JWS should be serialized. However, I have included an outline of one possible approach to this in the pull request's description. Please let me know what you think about the pull request ( https://github.com/ietf-wg-acme/acme/pull/395), and the separate conversion guide (https://github.com/u2/jwe-jws-serialization-conversion-guide) Logan On Fri, Jan 12, 2018 at 6:08 PM, Logan Widick wrote: > Last night, I briefly surveyed the listings of JWT implementations on > jwt.io. I could find only a small handful that appeared to support all > serializations, and even fewer that appeared to give programmers control > over what serialization was produced. Thus, assuming jwt.io is a > sufficiently accurate and comprehensive listing of implementations of all > and/or part of the JOSE specs, the developers of many ACME client and > server implementations may find themselves needing to convert between > serializations before and/or after using JOSE libraries. Such conversion > processes, if needed, should be well-documented somewhere. > > I've started on a very rough draft of a possible JWS and JWE serialization > conversion guide at https://github.com/u2/jwe-jws-serialization- > conversion-guide. I made the conversion guide draft by copying a few > items from the ACME GitHub repository (the Markdown file, the makefile, and > the .gitignore), replacing the text from the Markdown file, and renaming > the Markdown file. I designed the conversion guide draft to be non-ACME > specific, so I've tried to include things like unencoded JWS payloads, > JWEs, multiple signatures, detached payloads, etc. If you have any changes > or suggestions, please let me know. > > Logan > > On Fri, Jan 5, 2018 at 7:11 PM, Jörn Heissler < > acme-sp...@joern.heissler.de> wrote: > >> On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote: >> > What do you think of the following: >> >> > Content type application/jose+json: MUST be supported. If used, the JWS >> > will need to be in the Flattened or General serialization. Flattened >> MUST >> > be supported; General MAY be supported. >> >> > Content type application/jose: MAY be supported. If used, the JWS MUST >> use >> > the Compact serialization. Or should this content type not be allowed? >> >> Agreed. I wouldn't disallow "compact". And it could be clarified: >> >> The server SHOULD use the "Content-Type" HTTP header as an indication >> for the request format. >> >> > JWS Unprotected Header: Not currently used in ACME. Should this be >> banned >> > in ACME? >> >> I don't see much sense in those. But some client implementations might >> automatically add an unprotected header like e.g. "cty". >> Maybe with a "SHOULD NOT"? >> >> > Multiple signatures: MAY be supported. >> >> > Should messages signed by both MAC keys and private keys be allowed? >> >> This is already forbidden. >> >> > What about Key IDs not issued by the CA? >> > Or are multiple signatures more trouble than they're worth to the point >> of >> > banning them entirely? >> > >> > Multiple signatures on messages that need to be signed by account key: >> At >> > least one signature MUST be from the account key >> > >> > Multiple signatures on revokeCert: Should this be allowed? >> > >> > Multiple signatures on externalAccountBinding field of newAccount: >> Should >> > it be possible to bind to multiple pre-existing accounts? Or should this >> > not be allowed? >> > >> > Multiple signatures on newAccount: Not allowed?
Re: [Acme] Specify which JWS serialization is used
Last night, I briefly surveyed the listings of JWT implementations on jwt.io. I could find only a small handful that appeared to support all serializations, and even fewer that appeared to give programmers control over what serialization was produced. Thus, assuming jwt.io is a sufficiently accurate and comprehensive listing of implementations of all and/or part of the JOSE specs, the developers of many ACME client and server implementations may find themselves needing to convert between serializations before and/or after using JOSE libraries. Such conversion processes, if needed, should be well-documented somewhere. I've started on a very rough draft of a possible JWS and JWE serialization conversion guide at https://github.com/u2/jwe-jws-serialization-conversion-guide. I made the conversion guide draft by copying a few items from the ACME GitHub repository (the Markdown file, the makefile, and the .gitignore), replacing the text from the Markdown file, and renaming the Markdown file. I designed the conversion guide draft to be non-ACME specific, so I've tried to include things like unencoded JWS payloads, JWEs, multiple signatures, detached payloads, etc. If you have any changes or suggestions, please let me know. Logan On Fri, Jan 5, 2018 at 7:11 PM, Jörn Heissler wrote: > On Thu, Jan 04, 2018 at 08:03:55 -0600, Logan Widick wrote: > > What do you think of the following: > > > Content type application/jose+json: MUST be supported. If used, the JWS > > will need to be in the Flattened or General serialization. Flattened MUST > > be supported; General MAY be supported. > > > Content type application/jose: MAY be supported. If used, the JWS MUST > use > > the Compact serialization. Or should this content type not be allowed? > > Agreed. I wouldn't disallow "compact". And it could be clarified: > > The server SHOULD use the "Content-Type" HTTP header as an indication > for the request format. > > > JWS Unprotected Header: Not currently used in ACME. Should this be banned > > in ACME? > > I don't see much sense in those. But some client implementations might > automatically add an unprotected header like e.g. "cty". > Maybe with a "SHOULD NOT"? > > > Multiple signatures: MAY be supported. > > > Should messages signed by both MAC keys and private keys be allowed? > > This is already forbidden. > > > What about Key IDs not issued by the CA? > > Or are multiple signatures more trouble than they're worth to the point > of > > banning them entirely? > > > > Multiple signatures on messages that need to be signed by account key: At > > least one signature MUST be from the account key > > > > Multiple signatures on revokeCert: Should this be allowed? > > > > Multiple signatures on externalAccountBinding field of newAccount: Should > > it be possible to bind to multiple pre-existing accounts? Or should this > > not be allowed? > > > > Multiple signatures on newAccount: Not allowed? > > > > Multiple signatures on keyChange: Not allowed for outer or inner JWS? > > I see no use case. All the authentication is based on accounts and those > have exactly one keypair. Having multiple signatures would equal using > multiple accounts at the same time. That makes no sense to me. > Client libs would probably not generate multiple signatures > automatically. > Multiple signatures should be banned in my opinion. > > > JWS Unencoded Payload Option (RFC 7797): Not allowed? > > Yep, they would make things very complicated. > > > Conversion guide between the different JWS serialization formats: Is it > > completely safe to assume that any and all programmers given the JWS RFC, > > pre-existing JWS implementations with sufficient documentation, and > > pre-existing JSON libraries with sufficient documentation could figure > out > > how to convert the serialization formats as needed? > > Why, yes! Of course every programmer can do that! ;-) > > > Or is the conversion > > guide necessary? If the guide is necessary, then include a reference to a > > separate new or pre-existing conversion guide. If the guide is necessary, > > and there is no pre-existing conversion guide, how should the new > > conversion guide be published? Should the new conversion guide be > > ACME-specific, or more general (possibly with coverage of JWE as well as > > JWS features not utilized in ACME)? > > It's not necessary, *most* programmers can figure it out. But it would > doubtlessly be helpful. E.g. I didn't consider the possibility to do > this conversion in an ACME implementation before/after using a preexisting > JOSE lib. > If such a guide were to be published, it should not be ACME-specific. > > > Cheers > Jörn > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Specify which JWS serialization is used
To the best of my knowledge, the ACME signature solution was not fully addressed years ago. As far as I know, the only requirements for signatures discussed and explicitly specified in the text of the ACME draft are: Use JWS signatures (not JCS signatures) over HTTPS Don't use the "none" algorithm Use certain fields in the protected header as specified in the text Use JSON objects specified in the text as the payloads Don't use MAC keys/algorithms (with the exception of the value of the externalAccountBinding field which is a JWS with a MAC signature). (Related issues: If compact serialization is allowed, does the externalAccountBinding change from an object to a string to indicate compact serialization? What if this field is using an unsupported serialization?) Some things appear to be implied by the examples in the draft but don't appear to be explicitly specified in the text of the draft (at least not the current one), such as: Use JSON serialization (most likely flattened but JWS implementations may not give programmers control over this) Don't use unprotected headers Don't use the unencoded payload option Don't use multiple signatures (except perhaps in previous drafts that I think had multi-signature key changes instead of the nested key changes in the current draft). Implied in the examples but not explicitly specified in the text may hinder interoperability. I think ACME is in a last call. Logan On Jan 4, 2018 8:19 AM, "Anders Rundgren" wrote: > I thought the ACME signature solution was addressed years ago. Isn't ACME > in last call? > > F.Y.I. > https://cyberphone.github.io/doc/security/jose-jcs.html#Sample_Signature > > Anders > > On 2018-01-04 15:03, Logan Widick wrote: > >> What do you think of the following: >> >> Content type application/jose+json: MUST be supported. If used, the JWS >> will need to be in the Flattened or General serialization. Flattened MUST >> be supported; General MAY be supported. >> >> Content type application/jose: MAY be supported. If used, the JWS MUST >> use the Compact serialization. Or should this content type not be allowed? >> >> JWS Unprotected Header: Not currently used in ACME. Should this be banned >> in ACME? >> >> Multiple signatures: MAY be supported. Should messages signed by both MAC >> keys and private keys be allowed? What about Key IDs not issued by the CA? >> Or are multiple signatures more trouble than they're worth to the point of >> banning them entirely? >> >> Multiple signatures on messages that need to be signed by account key: At >> least one signature MUST be from the account key >> >> Multiple signatures on revokeCert: Should this be allowed? >> >> Multiple signatures on externalAccountBinding field of newAccount: Should >> it be possible to bind to multiple pre-existing accounts? Or should this >> not be allowed? >> >> Multiple signatures on newAccount: Not allowed? >> >> Multiple signatures on keyChange: Not allowed for outer or inner JWS? >> >> JWS Unencoded Payload Option (RFC 7797): Not allowed? >> >> Conversion guide between the different JWS serialization formats: Is it >> completely safe to assume that any and all programmers given the JWS RFC, >> pre-existing JWS implementations with sufficient documentation, and >> pre-existing JSON libraries with sufficient documentation could figure out >> how to convert the serialization formats as needed? Or is the conversion >> guide necessary? If the guide is necessary, then include a reference to a >> separate new or pre-existing conversion guide. If the guide is necessary, >> and there is no pre-existing conversion guide, how should the new >> conversion guide be published? Should the new conversion guide be >> ACME-specific, or more general (possibly with coverage of JWE as well as >> JWS features not utilized in ACME)? >> >> Sincerely, >> Logan Widick >> >> On Jan 4, 2018 5:02 AM, "Jörn Heissler" > <mailto:acme-sp...@joern.heissler.de>> wrote: >> >> On Thu, Jan 04, 2018 at 09:47:19 +1000, Fraser Tweedale wrote: >> > I am the author of a JOSE library, and have had to deal with >> > interoperability issues arising from the multiple serialisations >> and >> > underspecified applications/protocols. Please heed my advice. >> > >> > Where there is a choice of JSON serialisation (i.e. exactly one >> > signature), JOSE does not require or recommend a particular >> > serialisation be used. Not does the specification require or >> > recommend that there be a
Re: [Acme] Specify which JWS serialization is used
What do you think of the following:
Content type application/jose+json: MUST be supported. If used, the JWS
will need to be in the Flattened or General serialization. Flattened MUST
be supported; General MAY be supported.
Content type application/jose: MAY be supported. If used, the JWS MUST use
the Compact serialization. Or should this content type not be allowed?
JWS Unprotected Header: Not currently used in ACME. Should this be banned
in ACME?
Multiple signatures: MAY be supported. Should messages signed by both MAC
keys and private keys be allowed? What about Key IDs not issued by the CA?
Or are multiple signatures more trouble than they're worth to the point of
banning them entirely?
Multiple signatures on messages that need to be signed by account key: At
least one signature MUST be from the account key
Multiple signatures on revokeCert: Should this be allowed?
Multiple signatures on externalAccountBinding field of newAccount: Should
it be possible to bind to multiple pre-existing accounts? Or should this
not be allowed?
Multiple signatures on newAccount: Not allowed?
Multiple signatures on keyChange: Not allowed for outer or inner JWS?
JWS Unencoded Payload Option (RFC 7797): Not allowed?
Conversion guide between the different JWS serialization formats: Is it
completely safe to assume that any and all programmers given the JWS RFC,
pre-existing JWS implementations with sufficient documentation, and
pre-existing JSON libraries with sufficient documentation could figure out
how to convert the serialization formats as needed? Or is the conversion
guide necessary? If the guide is necessary, then include a reference to a
separate new or pre-existing conversion guide. If the guide is necessary,
and there is no pre-existing conversion guide, how should the new
conversion guide be published? Should the new conversion guide be
ACME-specific, or more general (possibly with coverage of JWE as well as
JWS features not utilized in ACME)?
Sincerely,
Logan Widick
On Jan 4, 2018 5:02 AM, "Jörn Heissler"
wrote:
> On Thu, Jan 04, 2018 at 09:47:19 +1000, Fraser Tweedale wrote:
> > I am the author of a JOSE library, and have had to deal with
> > interoperability issues arising from the multiple serialisations and
> > underspecified applications/protocols. Please heed my advice.
> >
> > Where there is a choice of JSON serialisation (i.e. exactly one
> > signature), JOSE does not require or recommend a particular
> > serialisation be used. Not does the specification require or
> > recommend that there be a mechanism for telling a library what JSON
> > serialisation to use. The outcome of this is that there are:
> >
> > - implementations that unconditionally produce the General JSON
> > serialisation
> >
> > - implementations that unconditionally produce the Flattened JSON
> > serialisation (and do not support multiple signatures at all)
> >
> > - implementations that produce the Flattened serialisation when
> > there is a single signature, and the General JSON serialisation
> > otherwise
> >
> > Therefore for interoperability and to avoid situations where a
> > conforming JOSE library cannot be used for ACME, I suggest that ACME
> > adopt the following regime:
> >
> > - Conforming ACME implementations MUST process JWS objects using the
> > Flattened JWS JSON Serialization and SHOULD process JWS objects
> > using the General JWS JSON Serialization.
> >
> > - Conforming ACME implementations MAY refuse to process JWS objects
> > with multiple signatures. If an implementation accepts
> > multiple-signature JWS objects, it MUST validate at least one
> > signature using the account's public key.
>
> This would work for me. I'm currently writing a new client (We need more
> ACME clients!) and I'd prefer to stick to a single hard coded
> serialization format which works with every conforming CA. Adding
> flexibility (Use "flat" for this CA, use "general" for that CA, etc.)
> would be troublesome.
>
> But I'm worried about client implementations that use the next best JOSE
> library which "unconditionally produces the General JSON serialisation".
> Most CAs would support it ("SHOULD"). But some might decide not to:
> "Yeah, we SHOULD support this. But our JOSE library only understands
> the flat format and everyone but YOU does use the flat format".
> Then who's to blame, the client or the CA?
>
> Should this be changed to "MUST" or to "MAY"?
> I.e. "flat" MUST be supported, "general" MUST/MAY be supported,
> "compact" MAY be supported but needs a "application/jose" content type.
>
>
> On
Re: [Acme] Specify which JWS serialization is used
Here is a pull request: https://github.com/ietf-wg-acme/acme/pull/382 Let me know what you think. Sincerely, Logan Widick On Wed, Jan 3, 2018 at 6:21 PM, Logan Widick wrote: > This looks good to me. > > As for using JOSE implementations that lack support for the JSON > serialization formats (and only support the compact one), is there an RFC, > Internet-Draft, or similar document with an explanation of the conversion > process already prepared (that can simply be thrown into the ACME draft's > references section)? Or would it be necessary to include an appendix in the > ACME draft with an outline of the conversion process? The conversion > process looks fairly straightforward. However, it would be nice if there > was a document or part of a document that could be easily referenced. > > Logan > > On Wed, Jan 3, 2018 at 5:47 PM, Fraser Tweedale wrote: > >> On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote: >> > Hello and happy new Year! >> > >> > I've found an inaccuracy in the ACME specs. >> > >> > https://tools.ietf.org/html/rfc7515#section-7 states: >> > >> > Applications using this specification need to specify what >> serialization >> > and serialization features are used for that application. >> > >> > Although this is neither a "SHOULD" nor a "MUST", I think ACME should >> specify >> > which serialization formats need to be supported by server >> implementations. >> > >> > RFC7515 defines four serialization formats: >> > >> > * JWS Compact Serialization >> > * General JWS JSON Serialization Syntax >> > * One signature only >> > * Multiple signatures >> > * Flattened JWS JSON Serialization Syntax >> > >> > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm >> l#rfc.section.6.2 >> > states: >> > >> > In the examples below, JWS objects are shown in the JSON or >> > flattened JSON serialization >> > >> > All examples in the ACME specification use only the flattened >> serialization. >> > Depending on the clarification above, this might need to be amended too. >> > >> > Best regards >> > Jörn Heissler >> >> I am the author of a JOSE library, and have had to deal with >> interoperability issues arising from the multiple serialisations and >> underspecified applications/protocols. Please heed my advice. >> >> Where there is a choice of JSON serialisation (i.e. exactly one >> signature), JOSE does not require or recommend a particular >> serialisation be used. Not does the specification require or >> recommend that there be a mechanism for telling a library what JSON >> serialisation to use. The outcome of this is that there are: >> >> - implementations that unconditionally produce the General JSON >> serialisation >> >> - implementations that unconditionally produce the Flattened JSON >> serialisation (and do not support multiple signatures at all) >> >> - implementations that produce the Flattened serialisation when >> there is a single signature, and the General JSON serialisation >> otherwise >> >> Therefore for interoperability and to avoid situations where a >> conforming JOSE library cannot be used for ACME, I suggest that ACME >> adopt the following regime: >> >> - Conforming ACME implementations MUST process JWS objects using the >> Flattened JWS JSON Serialization and SHOULD process JWS objects >> using the General JWS JSON Serialization. >> >> - Conforming ACME implementations MAY refuse to process JWS objects >> with multiple signatures. If an implementation accepts >> multiple-signature JWS objects, it MUST validate at least one >> signature using the account's public key. >> >> Cheers, >> Fraser >> >> ___ >> 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] Specify which JWS serialization is used
This looks good to me. As for using JOSE implementations that lack support for the JSON serialization formats (and only support the compact one), is there an RFC, Internet-Draft, or similar document with an explanation of the conversion process already prepared (that can simply be thrown into the ACME draft's references section)? Or would it be necessary to include an appendix in the ACME draft with an outline of the conversion process? The conversion process looks fairly straightforward. However, it would be nice if there was a document or part of a document that could be easily referenced. Logan On Wed, Jan 3, 2018 at 5:47 PM, Fraser Tweedale wrote: > On Thu, Jan 04, 2018 at 12:07:34AM +0100, Jörn Heissler wrote: > > Hello and happy new Year! > > > > I've found an inaccuracy in the ACME specs. > > > > https://tools.ietf.org/html/rfc7515#section-7 states: > > > > Applications using this specification need to specify what > serialization > > and serialization features are used for that application. > > > > Although this is neither a "SHOULD" nor a "MUST", I think ACME should > specify > > which serialization formats need to be supported by server > implementations. > > > > RFC7515 defines four serialization formats: > > > > * JWS Compact Serialization > > * General JWS JSON Serialization Syntax > > * One signature only > > * Multiple signatures > > * Flattened JWS JSON Serialization Syntax > > > > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme. > html#rfc.section.6.2 > > states: > > > > In the examples below, JWS objects are shown in the JSON or > > flattened JSON serialization > > > > All examples in the ACME specification use only the flattened > serialization. > > Depending on the clarification above, this might need to be amended too. > > > > Best regards > > Jörn Heissler > > I am the author of a JOSE library, and have had to deal with > interoperability issues arising from the multiple serialisations and > underspecified applications/protocols. Please heed my advice. > > Where there is a choice of JSON serialisation (i.e. exactly one > signature), JOSE does not require or recommend a particular > serialisation be used. Not does the specification require or > recommend that there be a mechanism for telling a library what JSON > serialisation to use. The outcome of this is that there are: > > - implementations that unconditionally produce the General JSON > serialisation > > - implementations that unconditionally produce the Flattened JSON > serialisation (and do not support multiple signatures at all) > > - implementations that produce the Flattened serialisation when > there is a single signature, and the General JSON serialisation > otherwise > > Therefore for interoperability and to avoid situations where a > conforming JOSE library cannot be used for ACME, I suggest that ACME > adopt the following regime: > > - Conforming ACME implementations MUST process JWS objects using the > Flattened JWS JSON Serialization and SHOULD process JWS objects > using the General JWS JSON Serialization. > > - Conforming ACME implementations MAY refuse to process JWS objects > with multiple signatures. If an implementation accepts > multiple-signature JWS objects, it MUST validate at least one > signature using the account's public key. > > Cheers, > Fraser > > ___ > 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] Specify which JWS serialization is used
I agree that a serialization format (or set of formats) would need to be standardized. Related thread: https://www.ietf.org/mail-archive/web/acme/current/msg01690.html Sincerely, Logan Widick On Wed, Jan 3, 2018 at 5:07 PM, Jörn Heissler wrote: > Hello and happy new Year! > > I've found an inaccuracy in the ACME specs. > > https://tools.ietf.org/html/rfc7515#section-7 states: > > Applications using this specification need to specify what > serialization > and serialization features are used for that application. > > Although this is neither a "SHOULD" nor a "MUST", I think ACME should > specify > which serialization formats need to be supported by server implementations. > > RFC7515 defines four serialization formats: > > * JWS Compact Serialization > * General JWS JSON Serialization Syntax > * One signature only > * Multiple signatures > * Flattened JWS JSON Serialization Syntax > > https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme. > html#rfc.section.6.2 > states: > > In the examples below, JWS objects are shown in the JSON or > flattened JSON serialization > > All examples in the ACME specification use only the flattened > serialization. > Depending on the clarification above, this might need to be amended too. > > Best regards > Jörn Heissler > > ___ > 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] Question about the new finalizeURL approach, and the order object format after finalizeURL
In the new finalizeURL approach to orders, do order objects need to contain a CSR after a user attempted to finalize the order, or after the order is finalized? Would the CA have to store the CSR after it's posted, or after the certificate is issued? >From the text, I assume that the body of the finalizeURL is a POST containing an ACME JWS message whose payload is a JSON object with the "csr" field. Is that correct? What would this POST look like? I'm asking these questions because I haven't been able to find an example of the finalizeURL POST in the draft ( https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md), and because I see "csr" fields in some of the order objects. I've created a branch of my fork of the GitHub repository ( https://github.com/u2/acme/tree/remove-csr-fields-from-order-and-add-example-finalize-post) with my understanding of the new finalizeURL POST. Specifically, in this branch, I am assuming that the CSR is not stored as part of the order. I am also assuming that the finalizeURL POST is an ACME JWS message whose payload is a JSON object with the "csr" field (which is in the same base64url format it was in before finalizeURL was introduced). Am I understanding the finalizeURL correctly? Sincerely, Logan Widick ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions
Here is a PR to remove the "tel" contacts from the examples:
https://github.com/ietf-wg-acme/acme/pull/353
In the PR, I am assuming that the ACME servers can support additional
contact schemes (schemes not defined in ACME specs) but must document
(somehow) what subsets of what additional schemes are supported. However, I
haven't added any text indicating this assumption. I also haven't added any
text indicating how the subsets of the additional contact schemes can be
documented.
Is this assumption correct? If so, should the assumption be documented any
further in the spec? If so, what would be the best way to document this
assumption further?
Logan
On Fri, Nov 17, 2017 at 11:17 AM, Daniel McCarney
wrote:
> I would be supportive of removing non-mailto contact examples.
>
> I don't think it's accurate to say that "mailto" is the only contact
> scheme currently supported by the ACME standard. That isn't the case for
> the spec as-written today - it is the only mandatory contact scheme. I
> believe its been left intentionally open ended what other schemes may be
> supported by a server.
>
> In my mind ACME servers wishing to support `tel` should come up with their
> own understanding of what parts of the relevant RFCs they support and use
> the `unsupportedContact` and `invalidContact` errors as appropriate based
> on the `tel://` contacts received. I don't think there is value trying to
> create a subprofile of `tel` for ACME use that is defined in the ACME draft.
>
> - cpu
>
>
>
> On Fri, Nov 17, 2017 at 11:12 AM, Logan Widick
> wrote:
>
>> Or, would it be best to remove the non-mailto contacts from the examples,
>> and add a note indicating that "mailto" is the only contact URI scheme
>> currently supported by the ACME standards?
>>
>> Sincerely,
>>
>> Logan Widick
>>
>> On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick
>> wrote:
>>
>>> This is related to my previous "Allowable mailto contacts" thread
>>> earlier this month. However, this is about a different type of contact, so
>>> I decided to start a new thread.
>>>
>>> Although ACME servers don't have to include support for "tel" (RFC 3966)
>>> contacts, "tel" contacts appear in multiple examples in the ACME
>>> specification. Thus, some may try to include "tel" contact support in their
>>> ACME server implementations.
>>>
>>> Although the example "tel" contacts in the ACME specification seem to
>>> indicate a simple, narrow subset (the "global-number" with zero "par"
>>> instances), the "tel" specification has many more possible productions. For
>>> example, both "global-number" and "local-number" may have "par" instances
>>> (like ";name1=value1;name2=value2") after the phone numbers.
>>>
>>> Assuming I understand the "local-number" specification correctly, a
>>> "local-number" could potentially contain a pound sign ("#") for reasons
>>> related to DTMF. If I understand the current and past URI specifications
>>> correctly, this could be problematic. Specifically, a URI parser may put
>>> the parts of the "local-number" after a "#" in the fragment.
>>>
>>> If someone wanted to implement "tel" contact support for an ACME server,
>>> what subset of "tel" would be required? Would both "global-number" and
>>> "local-number" instances be allowed? What restrictions would apply to
>>> "global-number" and "local-number" instances? Which types of "par"
>>> instances would be allowed? Extension? ISDN-subaddress? Others?
>>>
>>> On a more general note, I think that as ACME becomes more widely used,
>>> the subject of what subsets of what contact URI schemes would be allowed
>>> under ACME (as opposed to what schemes are supported by a specific ACME
>>> server, which was a separate issue already discussed in March on the
>>> mailing list under "Allowing clients to understand the account creation
>>> functionality supported by a server") may come up more often. Would it be a
>>> good idea to request the creation of an "ACME Contact Schemes Registry"
>>> like in the ASCII art figures below?
>>>
>>>
>>>
>>>
>>> ++---+---+--
>>> ---+
>>> | Scheme | Status| Reference | ACME
Re: [Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions
Or, would it be best to remove the non-mailto contacts from the examples,
and add a note indicating that "mailto" is the only contact URI scheme
currently supported by the ACME standards?
Sincerely,
Logan Widick
On Wed, Oct 25, 2017 at 3:18 PM, Logan Widick
wrote:
> This is related to my previous "Allowable mailto contacts" thread earlier
> this month. However, this is about a different type of contact, so I
> decided to start a new thread.
>
> Although ACME servers don't have to include support for "tel" (RFC 3966)
> contacts, "tel" contacts appear in multiple examples in the ACME
> specification. Thus, some may try to include "tel" contact support in their
> ACME server implementations.
>
> Although the example "tel" contacts in the ACME specification seem to
> indicate a simple, narrow subset (the "global-number" with zero "par"
> instances), the "tel" specification has many more possible productions. For
> example, both "global-number" and "local-number" may have "par" instances
> (like ";name1=value1;name2=value2") after the phone numbers.
>
> Assuming I understand the "local-number" specification correctly, a
> "local-number" could potentially contain a pound sign ("#") for reasons
> related to DTMF. If I understand the current and past URI specifications
> correctly, this could be problematic. Specifically, a URI parser may put
> the parts of the "local-number" after a "#" in the fragment.
>
> If someone wanted to implement "tel" contact support for an ACME server,
> what subset of "tel" would be required? Would both "global-number" and
> "local-number" instances be allowed? What restrictions would apply to
> "global-number" and "local-number" instances? Which types of "par"
> instances would be allowed? Extension? ISDN-subaddress? Others?
>
> On a more general note, I think that as ACME becomes more widely used, the
> subject of what subsets of what contact URI schemes would be allowed under
> ACME (as opposed to what schemes are supported by a specific ACME server,
> which was a separate issue already discussed in March on the mailing list
> under "Allowing clients to understand the account creation functionality
> supported by a server") may come up more often. Would it be a good idea to
> request the creation of an "ACME Contact Schemes Registry" like in the
> ASCII art figures below?
>
>
>
>
> ++---+---+--
> ---+
> | Scheme | Status| Reference | ACME Restrictions
> |
> ++---+---+--
> ---+
> | mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to"
> portion |
> || | | No "hfields" are allowed
> |
> || | | [Source: "Allowable mailto contacts"
> thread]|
> ++---+---+--
> ---+
> | tel| Optional | RFC 3966 | [insert restrictions picked in this
> thread] |
> ++---+---+--
> ---+
>
> Figure 1: A possible "ACME Contact Schemes Registry" table. In this
> version, the ACME restrictions on the original contact scheme
> specifications are stated in the table, and the original contact scheme
> specification is listed as the "Reference". These relationships are
> depicted graphically in Figure 2 (below).
>
>
>
>
> +---+++
> | RFC 6068 (mailto RFC) || RFC 3966 (tel RFC) |
> +---+++
>
> Figure 2: RFC relationships for Figure 1
>
>
>
>
> ++---+---+
> | Scheme | Status| Reference |
> ++---+---+
> | mailto | Mandatory | RFC |
> || | (ACME RFC)|
> || | |
> ++---+---+
> | tel| Optional | RFC |
> || | (Some RFC after RFC ) |
> ++---+---+
>
> Figure 3: Another possible "ACME Contact Schemes Registry&q
[Acme] Allowable "tel" contacts; publishing allowed contact schemes and their ACME-specific restrictions
This is related to my previous "Allowable mailto contacts" thread earlier
this month. However, this is about a different type of contact, so I
decided to start a new thread.
Although ACME servers don't have to include support for "tel" (RFC 3966)
contacts, "tel" contacts appear in multiple examples in the ACME
specification. Thus, some may try to include "tel" contact support in their
ACME server implementations.
Although the example "tel" contacts in the ACME specification seem to
indicate a simple, narrow subset (the "global-number" with zero "par"
instances), the "tel" specification has many more possible productions. For
example, both "global-number" and "local-number" may have "par" instances
(like ";name1=value1;name2=value2") after the phone numbers.
Assuming I understand the "local-number" specification correctly, a
"local-number" could potentially contain a pound sign ("#") for reasons
related to DTMF. If I understand the current and past URI specifications
correctly, this could be problematic. Specifically, a URI parser may put
the parts of the "local-number" after a "#" in the fragment.
If someone wanted to implement "tel" contact support for an ACME server,
what subset of "tel" would be required? Would both "global-number" and
"local-number" instances be allowed? What restrictions would apply to
"global-number" and "local-number" instances? Which types of "par"
instances would be allowed? Extension? ISDN-subaddress? Others?
On a more general note, I think that as ACME becomes more widely used, the
subject of what subsets of what contact URI schemes would be allowed under
ACME (as opposed to what schemes are supported by a specific ACME server,
which was a separate issue already discussed in March on the mailing list
under "Allowing clients to understand the account creation functionality
supported by a server") may come up more often. Would it be a good idea to
request the creation of an "ACME Contact Schemes Registry" like in the
ASCII art figures below?
++---+---+--
---+
| Scheme | Status| Reference | ACME Restrictions
|
++---+---+--
---+
| mailto | Mandatory | RFC 6068 | Exactly one "addr-spec" in the "to"
portion |
|| | | No "hfields" are allowed
|
|| | | [Source: "Allowable mailto contacts"
thread]|
++---+---+--
---+
| tel| Optional | RFC 3966 | [insert restrictions picked in this
thread] |
++---+---+--
---+
Figure 1: A possible "ACME Contact Schemes Registry" table. In this
version, the ACME restrictions on the original contact scheme
specifications are stated in the table, and the original contact scheme
specification is listed as the "Reference". These relationships are
depicted graphically in Figure 2 (below).
+---+++
| RFC 6068 (mailto RFC) || RFC 3966 (tel RFC) |
+---+++
Figure 2: RFC relationships for Figure 1
++---+---+
| Scheme | Status| Reference |
++---+---+
| mailto | Mandatory | RFC |
|| | (ACME RFC)|
|| | |
++---+---+
| tel| Optional | RFC |
|| | (Some RFC after RFC ) |
++---+---+
Figure 3: Another possible "ACME Contact Schemes Registry" table. In this
version, the "Reference" RFCs discuss the ACME-specific restrictions for
the contact schemes, and refer to the original specifications for the
contact schemes. These relationships are depicted graphically in Figure 4
(below).
+-+
| ACME restrictions on mailto |
+--+--+
^
|
| Contains
|
+--+--+ +--+
| RFC (ACME RFC) |References| RFC 6068 |
+ +> + (mailto RFC) |
| | | |
+--+--+ +--+
^
|
| References
|
+--+---+ +---+
| RFC |References| RFC 3966 |
+ (An RFC after RFC ) +> + (tel RFC) |
| | | |
+--+---+ +---+
^
|
| Contained in
|
+--+--+
| ACME Restrictions
Re: [Acme] Allowable mailto contacts
I was not involved with RFC 6068 in any way. However, from my understanding
of the RFC, that subset ("mailto:us...@example.com";) might (roughly) look
something like:
1. No hfields (that appears to be the RFC 6068 term for the query string
and its parameters) are allowed (The spec doesn't appear to have a fragment)
2. Only one e-mail address per mailto contact
Or at least that is how I would understand the constraints.
Sincerely,
Logan Widick
On Oct 19, 2017 3:20 PM, "Jacob Hoffman-Andrews" wrote:
On 10/19/2017 10:59 AM, Logan Widick wrote:
> What portions of the "mailto" URI scheme (RFC 6068) must an ACME server
> be able to accept as contacts?
Good question. I think we'd like to specify the narrowest subset
possible, i.e. "mailto:us...@example.com";. What would that look like in
the language of RFC 6068?
___
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] Allowable mailto contacts
All, What portions of the "mailto" URI scheme (RFC 6068) must an ACME server be able to accept as contacts? The examples I saw in the draft depict one-item "to" productions with no headers (e.g. "mailto:us...@example.com";), but I couldn't find further details on what is allowed and what is not. Would ACME servers need to accept multi-item "to" productions (e.g. "mailto: us...@example.com,us...@example.com")? What headers from RFC 5322 would ACME servers need to be able to accept? For example, would an ACME server need to accept the following: "mailto:us...@example.com?to=us...@example.com"; "mailto:us...@example.com?cc=us...@example.com"; "mailto:us...@example.com?bcc=us...@example.com"; "mailto:us...@example.com?subject=Hello%20World"; "mailto:us...@example.com?keywords=hello,world,acme"; Sincerely, Logan Widick ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Revisiting Proactive Issuance & new-order CSR
Would it be possible to extract the key and identifiers from the CSR, add the key to the database if it doesn't already exist, find or create the authorizations for the identifiers, not store the CSR, and then assemble the certificate from the (valid) authorizations and key later? Alternatively, could one get rid of the CSRs altogether, and have the new-order be a nested JWS? The inner JWS would be signed by the key that goes on the certificate and would contain everything required to generate the certificate (identifiers, requested dates if applicable, etc.). The outer JWS would be signed by the ACME account key and link the inner JWS to the ACME account. What goes in a CSR or certificate that can't be reconstructed later? Logan On Sep 19, 2017 2:26 PM, "Daniel McCarney" wrote: Hi folks, Just over a year ago in a thread titled "Proactive vs On-Finalization Certificate Issuance"[0] we reached the consensus on the question of whether to issue a certificate "on-finalization" or "proactively" with the conclusion to standardize on proactive issuance. Implementation experience shows that proactive issuance is slow in practice. An order can be associated with many authorizations and an authorization can be associated with many orders. This interacts poorly with optimizations Let's Encrypt has developed from in-the-field experience with ACME and it is difficult to rate-limit effectively. I propose that we return to the on-finalization style approach and that we provide the CSR during finalization.. ## Issues with proactive issuance ### Authorization Reuse Proactive issuance requires that when an authorization is switched to a valid state by the result of a challenge update that we find the associated orders and iterate each order's authorizations to see if all of the authorizations are valid and issuance can occur. Let's Encrypt reuses existing authorizations[1][2] whenever possible, as encouraged by ACME. This has been of huge value in reducing resource consumption (both in terms of database storage and challenge/API requests). Many clients create pending authorizations they do not finalize and similarly re-create pending authorizations for identifiers that the account already has valid authorizations for. Unchecked this leads to significant database growth and resource consumption, even with aggressive rate-limits[3]. The combination of authorization reuse and proactive issuance means a given authorization can be associated with many orders. This necessitates an expensive many-to-many query at each authorization update to see if any associated orders are now complete. One possible workaround is a rate-limit that would constrain the number of orders an authorization can be associated with. However establishing the value of the limit to both reduce server-side load & also effectively support Let's Encrypt's large-volume integrators and their issuance patterns is challenging. ### CSR-first new-order flow To support proactive issuance the CA also needs to have the CSR for the order at-hand when checking each authorization in case issuance can proceed. The `new-order` request that creates the order therefore carries the full CSR that was previously delivered by the "certificate finalize" message. We see users create many more authorizations than they are able to finalize successfully. With the legacy "new-cert" flow our authorization reuse dramatically helped reduce the DB space used up by authorizations that will never lead to issuance because no CSR is stored until all identifiers are validated. With the new-order flow we have to accept and store a full CSR before handing back authorizations to the client. Reuse of authorizations does not prevent the DB bloat that will occur from users submitting new order requests and not fulfilling them. The CSR contains a full public key and is one of the single largest contributors to DB disk space usage. Addressing this will require another strict rate limit on outstanding new-orders and is again difficult to “dial-in” in to both prevent excessive resource consumption and also maintain the ability for big integrators to process large-scale issuance using our API. # Proposed Change I believe we should change the `new-order` endpoint to not accept a full CSR but to instead accept a list of identifiers that the ACME client wishes to authenticate & issue for. Authorizations can be created and returned for those domains as happens today. The order resource should be changed to have a “finalizeURL” field which provides the client a URL to POST a CSR to indicate that the CA should issue the certificate. Proactive issuance should be removed outright. This will address both the problem of scanning existing many-to-many orders & their authorizations as well as the db bloat that will occur from front-loading the delivery of the CSR. It may be tempting to leave proactive issuance as an optional feature but this will require maintaining the CSR in the new-order and
Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token
Would it be possible to add a section for how to follow this pattern in the
presence of space constraints?
One possible way would be to divide H(H(kA)) and H(kA) into N pieces as
needed to get through the system. Each request would include the "piece
number" in some way so that the system can work even in the (probably rare)
event that pieces of either H(H(kA)) or H(kA) are identical. The ACME
server would make N requests (one for each of the N pieces). If N=1, the
piece number would be omitted and only 1 request would be made. In the
event of failure, the problem document could indicate the failing pieces in
an array.
That way, the same pattern works regardless of space constraints.
As for key comparison, here are some ideas:
1. Put the key thumbprint (produced using the same hash function H
specified in the challenge) in the revised key authorization structure in
lieu of the key. Include the key ID as another field in the key
authorization structure.
2. Require that only a given subset of JWK fields appears (like the fields
required for thumbprints). Include the key ID as another field in the key
authorization structure.
Sincerely,
Logan Widick
On Jun 14, 2017 10:22, "Ilari Liusvaara" wrote:
On Wed, Jun 14, 2017 at 09:23:59AM -0400, Richard Barnes wrote:
> Hey Ilari,
>
> Thanks for this analysis. I agree that a tighter and clearer binding of
> the challenge/response pair to the validation transaction would be
> desireable, as would more uniformity across challenges. I would like to
> propose a slightly different structure, though.
>
> ===
>
> The essential elements of a challenge are (1) the content of the
challenge,
> (2) the content of the response, (3) the content of the validation query,
> and (4) the content of the validation response (where in 3 and 4, we mean
> the part that is specific to the validation, vs. .well-known or
> _acme-challenge). Right now, (1) and (2) are the same for all challenges,
> but (3) and (4) differ.
>
> http: (1) token (2) keyAuthorization (3) token (4) keyAuthorization
> tls: (1) token (2) keyAuthorization (3) H(token) (4) H(keyAuthorization)
> dns: (1) token (2) keyAuthorization (3) (nil) (4) H(keyAuthorization)
>
> I think we could meet the requirements above with the following steps:
>
> 1. Update the keyAuthorization structure to be a JSON object binding the
> validation to a bunch of stuff, e.g.:
>
> {
> "identifier": {"type": "dns", "value": "example.com"},
> "method": "dns-01",
> "key": { ... },
> "nonce: "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
> }
>
> 2. Have the client provide the serialized keyAuthorization in its response
> to the challenge (in ACME) and have the server verify that it decodes
> properly, has only the identified fields, and the fields have the proper
> values.
This has the raw key, which means one has to compare raw keys. IIRC,
that is somewhat frowned on.
> 3. Derive the validation query and response values from the serialized
> keyAuthorization value provided in the response, using a "reveal the
> preimage" pattern, either:
> 3.a. query = H(kA), response=kA, or
> 3.b. query = H(H(kA)), response=H(kA)
>
> I kind of like the latter better, because it meets all the transport
> requirements for DNS and TLS (since the hashes are small). It also
enables
> the server to verify that a challenge/response pair is valid without
> necessarily revealing to the server the details of the validation; if the
> server really wants to know, it can demand the raw key authorization.
I expect the most common check is check for identifier.
But being able to calculate where the response goes from the key
authorization (e.g.
'http://somehost3.example.net/.well-known/acme-challenge/yeag2...',
'_acme-validation.somehost3.example.net' or
'gesc3<...>.token.acme.invalid') is sure nice to have.
> That would give us a uniform structure across challenges:
>
> all: (1) token (2) keyAuthorization (3) H(H(keyAuthorization)) (4)
> H(keyAuthorization)
I don't think there is any extra space in DNS for the query. IIRC,
there is 255 byte total length restriction for DNS QNAMEs in addition
to the 63 byte per-component limit.
> What would folks think of that? It's a large-ish change for this stage of
> the process, but it seems like the regularity it provides will help
> simplify analysis and make implementation easier, so I'm inclined to do
it.
-Ilari
___
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] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token
I think that this may require revising the challenge. Would a "two-token" challenge pattern help mitigate the risk of stateless clients for the HTTP challenge and for future challenges that may otherwise have similar issues? For example, assume that the challenge has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, and tokenB would be used only for responses. The key authorization would include both tokens to ensure that the tokens were received correctly. For example, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP validation by sending a request to "http://example.com/.well-known/acme-challenge/tokenA"; and get back the revised key authorization (or anything else with tokenB in it). Since tokenB was not sent with the request, the server would have to have known tokenB somehow. One possible drawback of this approach is the increased storage required for the extra token. An alternate approach may be to require that a request parameter sent during validation for any type of challenge (now existing or later developed) must include a hash of something containing the challenge token rather than something containing the token itself. For example, the HTTP challenge could be revised by having the validation go to " http://example.com/.well-known/acme-challenge/SHA256_hash_of_the_token"; instead of "http://example.com/.well-known/acme-challenge/token";. The TLS-SNI challenge uses this "hashed token for requests" pattern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS SNI extension during challenge verification) is constructed by hashing the token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having challenges to use this "hashed token for requests" pattern is that hashing would become such an integral part of the challenge process that if a hash algorithm is compromised, new versions of all challenges will need to be released. In both ideas above, I suggested applying the same general "pattern" (of what should be used for making validation requests and what should be used for making validation responses) to all challenges. Although this statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in a "security considerations" subsection) to require or recommend all challenges to use the same pattern (or choose from a list of multiple approved patterns) would prevent future challenges from having similar issues. On a different note, would requiring the provisioned challenge resource (in this case, the response to the "http://example.com/.well-know n/acme-challenge/some_token_or_hash_of_the_token" request) to be digitally signed by the account JWK and/or the CSR key (most likely by having the response be a JWS containing the key authorization rather than the key authorization itself) improve security, worsen security, or have no impact on security? If it would improve security, would this be feasible for each type of challenge? Sincerely, Logan Widick On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd wrote: > The following feedback is based on cd7c5e9 (current HEAD of master). > > Section 8.3 states that the token value for HTTP validation "MUST have at > least 128 bits of entropy." > > Section 11.3 explains that one goal of this is that "the entropy > requirement prevents ACME clients from implementing a “naive” validation > server that automatically replies to challenges without participating in > the creation of the intial authorization request." > > However, because of the way the token is used in the validation process, > as a part of the request, this goal is not met. It is possible to configure > a webserver to respond to all requests under .well-known/acme-challenge > with the ASCII representation of the key authorization. (See, e.g., > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.) > > Essentially, the server informs the client of the token during the > validation process, removing any need for the client to have known it. > > If this is acceptable, the entropy requirement should be removed. If this > is unacceptable, the challenge and validation should be revised. > > Regards, > Zach Shepherd > > > ___ > 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] Account URI recovery
What would the server return if "only-return-existing" is true and the account doesn't exist? On Thu, Apr 27, 2017 at 2:40 PM, Richard Barnes wrote: > > > On Tue, Apr 18, 2017 at 1:34 AM, Hugo Landau wrote: > >> >In reviewing a PR today noting that a client can find the account >> URI for >> >a key pair using a new-account request with an empty payload [1], >> Jacob >> >and I thought it might be a little more robust to use an explicit >> signal. >> >I've posted a PR that adds a "recovery" field to indicate to the >> server >> >that it should not create an account if one does not exist already. >> Which >> >is a little ironic in a request to an endpoint designed to create an >> >account, but saves us creating a whole new endpoint. >> >[1]https://github.com/ietf-wg-acme/acme/pull/296 >> I don't think this should be called recovery. It's too reminiscent of >> the old removed account recovery mechanisms and will be confusing. >> >> How about "existing": true? >> > > Good idea. To be extra clear, I think I'm going to with > "only-return-existing". > > > ___ > 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] "Slide 16" ("up" Link Relation) Follow Up from IETF 98
On Wed, Apr 26, 2017 at 2:50 PM, Richard Barnes wrote:
>
>
> On Wed, Apr 26, 2017 at 2:09 PM, Logan Widick
> wrote:
>
>> According to the draft minutes, as of the end of IETF 98, the plan was to
>> eliminate the "up" link relation from authorization to order since an
>> authorization can belong to multiple orders and nobody seemed to rely on
>> this relation. However, I still see this "up" relation on GitHub. Is the
>> plan still to remove that "up" relation, has the plan changed, or is the
>> plan to wait and see if anyone uses the relation first?
>>
>
> We just haven't gotten around to implementing it yet :) Here's a PR:
>
> https://github.com/ietf-wg-acme/acme/pull/298
>
Good to know. Thanks!
>
>
>> As for the "up" link relation from challenge to authorization (not
>> mentioned on slides), this could encounter a similar problem. As a simple
>> example to illustrate the potential problem, assume a server issues an
>> order with two authorizations: one authorization for (http-01 or dns-01),
>> and another authorization for (tls-sni-02 or dns-01). To prevent the client
>> having to complete the same challenge twice, assume that the server used
>> the same dns-01 challenge instance for both authorizations. For the common
>> dns-01 challenge, where does the "up" relation point to? This could become
>> a more significant issue as new identifiers, challenges, etc. are added in
>> the future. How should this be addressed?
>>
>
> Why would a server do what you're saying? It seems like the construct you
> propose basically just takes the OR combinations of challenges in the
> individual authz and ANDs them. We had agreed a long time ago that a
> single OR layer was sufficient for all known use cases. And if you want to
> create an AND, this is about the least elegant way you could create the
> AND, vs. say a conjuction challenge type, or the "combinations" array we
> had before.
>
> Given that, I'm comfortable saying that each challenge belongs to exactly
> one authz.
>
I was thinking that there could be situations where a challenge belongs to
multiple authzs (which would complicate the "up" link). I thought of two
types of such situations:
1. A server that follows something like the above scenario. This might
not be that likely.
2. A type of "thing" that people may want to put in a certificate in the
future that may require multiple identifiers to represent. This would mean
that a challenge could end up validating multiple identifiers. That would
require multiple authzs for the same challenge, since an authz is for one
identifier only.
For the second type of situation, I was going to reply with a scenario that
involved future demand for physical addresses in certificates. A physical
address is already required for some types of certificates (see section
9.2.7, "Subject Physical Address of Place of Business Field", in the EV
spec at https://cabforum.org/wp-content/uploads/EV-V1_6_1.pdf as an
example) and
I thought that a physical address would be example of one "thing" that
would require multiple identifiers to represent (street, city/town,
state/province, country, and postcode). However, I think one could get
around that with some type of special representation. Initial but likely
inelegant possibilities could include encoding the address components as
URL query parameters inside the value string (e.g.
"streetAddress=123%20Test%20Street&localityName=Testville&stateOrProvince=
AnyState&country=AnyCountry&postCode=123456"), or as a similar JSON object
inside the value string (e.g. '{"streetAddress": "123 Test Street",
"localityName": "Testville", "stateOrProvince": "AnyState", "country":
"AnyCountry", "postcode": "123456"}').
(I know that the guiding use case for ACME is DV not EV, but I was thinking
that there may be demand for ACME-based EV in the future.)
A physical address was the most complex example of a "thing" that I could
think of that someone may want to put in a certificate in the future, and
that I thought may require multiple identifiers to represent. However, as
mentioned above, there could even be a way to merge the parts of a physical
address into a single identifier. Thus, I am now convinced that each
"thing" that someone could ever want put in a certificate could be
represented as a single identifier. Therefore, I would be comfortable
saying that a challenge validates exactly one identifier. Combine this with
the low (or zero) odds of my initial scenario happening, and I am also now
comfortable saying a challenge belongs to exactly one authz.
Logan
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] "Slide 16" ("up" Link Relation) Follow Up from IETF 98
According to the draft minutes, as of the end of IETF 98, the plan was to eliminate the "up" link relation from authorization to order since an authorization can belong to multiple orders and nobody seemed to rely on this relation. However, I still see this "up" relation on GitHub. Is the plan still to remove that "up" relation, has the plan changed, or is the plan to wait and see if anyone uses the relation first? As for the "up" link relation from challenge to authorization (not mentioned on slides), this could encounter a similar problem. As a simple example to illustrate the potential problem, assume a server issues an order with two authorizations: one authorization for (http-01 or dns-01), and another authorization for (tls-sni-02 or dns-01). To prevent the client having to complete the same challenge twice, assume that the server used the same dns-01 challenge instance for both authorizations. For the common dns-01 challenge, where does the "up" relation point to? This could become a more significant issue as new identifiers, challenges, etc. are added in the future. How should this be addressed? Sincerely, Logan Widick ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Multiple Accounts with Same Key
So there would need to be a new error type (possibly named something like "accountKeyCollision")? If so, what would be the right HTTP code? 400 (Bad Request)? Or something else? On receiving the error, should the client either generate a different key to change to or use the account URL recovery mechanism? Would the desired response change if the key clash involved a deactivated account (whether by client or CA) instead of an active one? On Thu, Apr 20, 2017 at 3:29 PM, Zach Shepherd wrote: > Given that account recovery is based on key (with or without #294 > <https://github.com/ietf-wg-acme/acme/issues/294>), it seems like > allowing multiple accounts to coexist with the same key would be > problematic. > > > It also seems like attempting to create a second account with the same key > would almost always indicate user- or client-error. > > Responding with an error seems best, but no existing error type seems > appropriate. > > ------ > *From:* Acme on behalf of Logan Widick < > logan.wid...@gmail.com> > *Sent:* Thursday, April 20, 2017 9:35 AM > *To:* ACME WG > *Subject:* [Acme] Multiple Accounts with Same Key > > All, > > How should a server respond if a client is trying to perform an action > that would result in multiple active accounts having the same account key? > For example: > >- Sending a key-change request with a newKey that is already in use by >another account >- (If https://github.com/ietf-wg-acme/acme/issues/294 > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_issues_294&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=fT5vYOMkmme0438ks680s1E87y3_9uzpVRXo68BKP0g&s=RQZTzj8SNgzWJCM0DOIr88G0VC9ETYS7ZMt_QKVTT1I&e=> > is >merged into master) Sending a new-account request (that doesn't have the >new "recovery" field or has the new field set to false) with a key that is >already used by another account > > Should the server respond with an error code? Allow multiple accounts with > the same key to coexist? Do something else? > > Sincerely, > > Logan Widick > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Multiple Accounts with Same Key
All, How should a server respond if a client is trying to perform an action that would result in multiple active accounts having the same account key? For example: - Sending a key-change request with a newKey that is already in use by another account - (If https://github.com/ietf-wg-acme/acme/issues/294 is merged into master) Sending a new-account request (that doesn't have the new "recovery" field or has the new field set to false) with a key that is already used by another account Should the server respond with an error code? Allow multiple accounts with the same key to coexist? Do something else? Sincerely, Logan Widick ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2
On Apr 3, 2017 16:07, "Sean Leonard" wrote:
On 4/3/2017 5:54 AM, Logan Widick wrote:
I think that having separate URIs to reduce bloat is a good idea. I
understand that the client needs to send the CSR as a field in the
new-order request payload for security. However, in the server response,
could the CSR be a URI that would allow the client to retrieve the CSR that
the client submitted in DER format? So, could new-order requests look like:
{
csr: "base64url(derEncodedCSR)"
//rest of fields in new-order here
}
And the server's order response look like:
{
csrLink: "[link to DER encoded CSR]"
certificate: "[link to DER encoded certificate]"
chains: [array of links to chains as suggested by Niklas]
//rest of fields in order response here (except for "csr")
}
The wrinkle with this proposal is that CSRs are likely non-public data.
They could contain personally identifiable information in the metadata, or
other random stuff. It is undesirable to have a link that has to be
maintained for the lifetime of the order history, which could be harvested
by search engines or otherwise made public. Typically CAs harvest the
public key and discard the rest (after verifying the authenticity of the
CSR). Therefore, I am not in favor of URIs for CSR data.
Since CAs would harvest data from CSRs and then discard the rest after
authenticity checks, and the identifiers would appear elsewhere (in the
authorizations), could the "csr" field apply to the new-order request and
be absent from the order object?
The case for URIs for issued end-entity certificates is half-half.
Certificates are public documents, but it's an extra round-trip and you
have to save the same amount of state on the client side (i.e., the
certificate URI).
The case for URI(s) for CA certificates in the validation chain is
strongest, since they are unlikely to change and are reused across many
customers. Basically "de-duplication". On the other hand, there are
business/usability advantages to packaging up "everything you need to run
your web server" in one neat package.
When certificates are embedded in order objects, won't the order objects
get quite large?
For consistency, I think the chain links (when retrieved) should be
concatenated DER.
I am in favor of DER. :) (But less sure about whether links are desirable
in the first place.)
I could have sworn that when certificate retrieval is done over the wire,
CMS (PKCS #7) is an IETF standardized type for blobs of certificates. Oh
yeah, here it is:
RFC 5280 Section 4.2.2.1 (it's repeated elsewhere):
HTTP server implementations accessed via the URI SHOULD specify the
media type application/pkix-cert [RFC2585
<https://tools.ietf.org/html/rfc2585>] in the content-type header
field of the response for a single DER encoded certificate and SHOULD
specify the media type application/pkcs7-mime [RFC2797
<https://tools.ietf.org/html/rfc2797>] in the
content-type header field of the response for "certs-only" CMS
messages. For FTP, the name of a file that contains a single DER
encoded certificate SHOULD have a suffix of ".cer" [RFC2585
<https://tools.ietf.org/html/rfc2585>] and the
name of a file that contains a "certs-only" CMS message SHOULD have a
suffix of ".p7c" [RFC2797 <https://tools.ietf.org/html/rfc2797>].
Consuming clients may use the media type
or file extension as a hint to the content, but should not depend
solely on the presence of the correct media type or file extension in
the server response.
Just sayin'... ;-)
It is worth pointing out that PKCS #7 / CMS "certs-only", amounts to
concatenated DER certificates plus a little bit of goo at the beginning and
end (which can be ignored/skipped). Here is a dump of a .p7s file I have
lying around using asn1js:
SEQUENCE(2 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.2
[0](1 elem)
SEQUENCE(5 elem)
INTEGER1
SET(0 elem)
SEQUENCE(1 elem)
OBJECT IDENTIFIER1.2.840.113549.1.7.1
[0](3 elem)
SEQUENCE(3 elem)
SEQUENCE(3 elem)
SEQUENCE(3 elem)
SET(0 elem)
In this case, the SEQ -> [0] -> SEQ -> [0] has three certificates, which
start with SEQUENCE. Rip and go.
Finally, here is how you convert from p7s to textual certificates:
openssl pkcs7 -inform DER -in yourfile.p7s -print_certs
The advantage of the command-line/OpenSSL recipe above, is that you are
guaranteed that the output will only be -BEGIN CERTIFICATE- things.
Non-certificates shall not pass.
That already standardized type would be better.
On Apr 3, 2017 06:29, "Niklas Keller" wrote:
One potential issue I can see with embedding certificates with the
currently proposed format directly into orders are alternative chains.
Chains usually do not change between orders, so they could be kept with
separate URIs for cachability and less bloat in the order
Re: [Acme] Account URI recovery
>From the text, if the field isn't present, should the server act like it was set to false? If this new field is false, and an account exists, then what happens to the pre-existing account, its orders, its certificates and its authorizations? Sincerely, Logan Widick On Apr 17, 2017 17:45, "Richard Barnes" wrote: > In reviewing a PR today noting that a client can find the account URI for > a key pair using a new-account request with an empty payload [1], Jacob and > I thought it might be a little more robust to use an explicit signal. I've > posted a PR that adds a "recovery" field to indicate to the server that it > should not create an account if one does not exist already. Which is a > little ironic in a request to an endpoint designed to create an account, > but saves us creating a whole new endpoint. > > https://github.com/ietf-wg-acme/acme/pull/296 > > Please let me know if you have any comments on the approach here. > > Thanks, > --Richard > > ___ > 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] "Slide 21" follow-up (textual encoding question) PART 2
I think that having separate URIs to reduce bloat is a good idea. I
understand that the client needs to send the CSR as a field in the
new-order request payload for security. However, in the server response,
could the CSR be a URI that would allow the client to retrieve the CSR that
the client submitted in DER format? So, could new-order requests look like:
{
csr: "base64url(derEncodedCSR)"
//rest of fields in new-order here
}
And the server's order response look like:
{
csrLink: "[link to DER encoded CSR]"
certificate: "[link to DER encoded certificate]"
chains: [array of links to chains as suggested by Niklas]
//rest of fields in order response here (except for "csr")
}
For consistency, I think the chain links (when retrieved) should be
concatenated DER.
Sincerely,
Logan Widick
On Apr 3, 2017 06:29, "Niklas Keller" wrote:
One potential issue I can see with embedding certificates with the
currently proposed format directly into orders are alternative chains.
Chains usually do not change between orders, so they could be kept with
separate URIs for cachability and less bloat in the order response.
e.g.
"certificate": base64url(derEncodedCertificate),
"chains": [
"https://.../chain";,
"https://.../alternate-chain";
]
Regards, Niklas
___
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] Allowing clients to understand the account creation functionality supported by a server
I think that there should be a way for servers to tell clients what
types of contact information and what types of identifiers are
supported. Perhaps some part of the directory object could have an
array of dummy contacts to show off the URI schemes. For example:
contactTypes: ["mailto:exam...@example.com";, "tel:000-000-"]
Alternatively, the contactTypes may be a list of schemes. For example:
contactTypes: ["mailto", "tel"]
Another part of the directory object could have information on
supported identifiers. For example:
identifierTypes: ["dns"]
Alternatively, the identifierTypes could include possible challenge
types that the server may issue. For example:
identifierTypes: [
{"identifierType": "dns", "challengeTypes": ["http", "tls-sni", "dns"]}
]
Or, the identifierTypes may include information on possible
authorizations. For example, consider an ACME server that requires 2
authorizations for a domain. One of the two authorizations must
require a successful "http" or "tls-sni" challenge, while the other
authorization requires a successful "dns" challenge. Then, the
identifierTypes may look like (with // lines as comments only):
identifierTypes: [
{"identifierType": "dns", "authorizationTypes": [
//first authorization: client must complete either HTTP or
TLS-SNI challenge
["http", "tls-sni"],
//second authorization: client must complete DNS challenge
["dns"]
]}
]
I have three options above for identifiers as I am not sure if
broadcasting the challenges and/or authorizations may be a security
issue or if it may be too complicated for the client or server.
Consensus would have to be reached around one of the three identifier
options, some other way to include supported identifier info in the
directory, or excluding the supported identifier info from the
directory. Similar consensus would need to be reached for the
contacts.
Sincerely,
Logan Widick
-- Forwarded message --
> From: Zach Shepherd
> To: "c...@letsencrypt.org"
> Cc: "acme@ietf.org"
> Bcc:
> Date: Thu, 23 Mar 2017 18:06:04 +
> Subject: Re: [Acme] Allowing clients to understand the account creation
> functionality supported by a server
> Let's consider a simple world where all ACME servers support mailto and some
> ACME servers support tel.
>
> To create an account, the user provides the necessary information to their
> AMCE client: one or more email addresses and zero or more phone numbers. The
> ACME client then attempts to supply all of this information to in an account
> creation request. Some of the time, this will result in an error because the
> ACME server does not support tel.
>
> When the ACME client receives this error, it could:
> 1. Display it to the user and ask the user to adjust their input accordingly.
> (A poor user experience.)
> 2. Attempt to parse to the error message to confirm that the problem was the
> tel. (Hacky.)
> 3. Assume that the problem was the tel and retry without that. (Very hacky.)
>
> A new ACME server could come along that requires at least one tel or that
> doesn't support mailto. As a result, ACME clients may chose to attempt #2
> and/or #3 before falling back to #1.
>
> This means that ACME clients have one of six different behaviors (#1, #2, #3,
> #2 falling back to #1, #3 falling back to #1, #2 falling back to #3 falling
> back to #1), some of which add a non-trivial amount of complexity to attempt
> to parse error messages (yuck.) and some of which end up pushing the
> complexity onto the end-user in end anyways. (Or worse, ACME clients wind up
> with hard-coded assumptions based on a specific ACME server implementation
> and become less portable.)
>
> Providing information about the supported contact schemes in a machine
> readable format (e.g., in response to a GET requests on the server's
> new-account URI) does add work for ACME server implementors, but not so much
> that it's worth complicating the end-user experience.
>
> Regards,
> Zach
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
[Acme] Hash algorithms for challenges
I noticed that the challenges in the draft seem to be tied to the same
hash algorithm (SHA-256). Would it be possible to have the the server
include an array of supported hash algorithms, and then have the
client specify which one of the server's supported algorithms is used
in the response? This way, the hash algorithms can be changed when
needed without changing the challenges themselves.
For example, consider the following directory, modified to include the
server's supported hash algorithms:
{
"new-nonce": "https://example.com/acme/new-nonce";,
//other standard URIs here
"meta": {
"terms-of-service": "https://example.com/acme/terms";,
"website": "https://www.example.com/";,
"caa-identities": ["example.com"],
"hash-algorithms": ["SHA-256", "SHA-512"]
},
Alternatively, the server's hash algorithms could be included in the
challenges, like this:
{
"type": "http-01",
"url": "https://example.com/authz/1234/0";,
"token": "DGyRejmCefe7v4NfDGDKfA",
"hash-algorithms":["SHA-256", "SHA-512"]
}
Then, the client indicates the preferred hash algorithm (from the
server's list) in the response:
{
"protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1";,
"nonce": "Q_s3MWoqT05TrdkM2MTDcw",
"url": "https://example.com/acme/authz/asdf/0";
}),
"payload": base64url({
"type": "http-01",
"keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE",
"hash-algorithm": "SHA-256"
}),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
}
For compatibility with existing implementations, the default hash
algorithm if none is specified could be SHA-256.
Sincerely,
Logan Widick
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] JWS serialization
So flattened and general JSON are both allowed, and the non-JSON compact is not allowed? On Feb 15, 2017 8:38 PM, "Fraser Tweedale" wrote: > On Tue, Feb 14, 2017 at 04:02:35PM -0800, Jacob Hoffman-Andrews wrote: > > Flattened JSON, IMO. And I think we should standardize on that single > > representation. > > > I think we should not specify only that a JSON serialisation be > used. We SHOULD NOT specify that flattened must be used. Many JOSE > libraries do not care and will decode either JSON representation as > long as it is valid. Many JOSE libraries would not even provide a > knob to tell it to admit only the flattened serialisation (or vice > versa). > > If the intent is to require that exactly one signature is used, then > just say that. > > Thanks, > Fraser > > > On 02/14/2017 03:39 PM, Logan Widick wrote: > > > All, > > > > > > Which JWS serialization is to be used when implementing? The document > > > indicates that the examples are in either flattened JSON or general > > > JSON serializations for readability. But which serialization must be > > > used for the actual implementations? > > > > > > Sincerely, > > > > > > Logan Widick > > > > > > ___ > > > 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
[Acme] JWS serialization
All, Which JWS serialization is to be used when implementing? The document indicates that the examples are in either flattened JSON or general JSON serializations for readability. But which serialization must be used for the actual implementations? Sincerely, Logan Widick ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] external-account-binding information
What type is the external-account-binding field of an account object? I am asking this because there is an "external-account-token" field in the "Fields in Account Objects" section of type string, there is no "external-account-token" field mentioned elsewhere, and the "external-account-binding" example that occurred earlier in the document appears to be a JSON serialized JSON Web Signature (JWS) object. Thank you, Logan Widick ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
