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
enation 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
F6OYJ597u_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 you for yo
zation digest 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
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!
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])"
