nnecessary
challenge round trip.
--
Richard Körber
Am 02.03.2018 um 19:28 schrieb Felipe Gasper:
> One (fairly) obvious use of the “wildcard” flag is for status reporting
> without the context of the original newOrder. The client can thus more easily
> say:
>
> Authorization for
nnecessary
challenge round trip.
--
Richard Körber
Am 02.03.2018 um 19:28 schrieb Felipe Gasper:
> One (fairly) obvious use of the “wildcard” flag is for status reporting
> without the context of the original newOrder. The client can thus more easily
> say:
>
> Authorization for
1TG3sMEMbJF6OYJ597u_g18MYMp8
Since both ways are giving different results, only one of them can be
the correct one. :)
Question 1: Which concatenation is meant to be used in RFC 8823?
Question 2: Should the RFC 8823 explicitly specify how the concatenation
should be done?
Thank
concatenation of strings."
So the computation of the key authorization is a purely string-based
operation. I cannot use the decoded and concatenated byte array for it.
Best,
Richard Körber
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
t but not the intermediate concatenated
value.
I agree. An example would be helpful to leave no room for interpretation.
Thank you for your help!
Best,
Richard Körber
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
Hello!
In section 4 of draft-ietf-acme-scoped-dns-challenges-00, an example is
given about how to calculate the hash of the account resource URL.
The example gives this account URL: "https://example.com/acme/acct/";
According to the example, the result of the
"base32(SHA-256()[0:10])" operat
Thank you! Yes, that fixed the problem.
Looking at the specs again, I should have figured it out myself.
Thanks, again!
it was "https://example.com/acme/acct/ExampleAccount"; but looks like
autometic line change was in bad place
2024-03-16 오후 8:19에 Richard Körber 이(가) 쓴 글:
Hello!
There should be an own error type if the server requires the client to agree
to the (latest) Terms of Service.
Rationale: Currently, when an account needs to accept the Terms of Service,
the server responds with this error:
{"type":"urn:acme:error:unauthorized","detail":"Must agree to sub
ains.
So, wouldn't it be sufficient that for a wildcard domain (*.example.com), only
the domain itself (example.com) is challenged?
--
Richard Körber
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
