Fries, Steffen <[email protected]> wrote: > Besides this, we see further use cases, in which the connection to the PKI is > not always available. This may be the case if the connection to the CA is only > temporary available or not directly available. Here, the approach would require > a rather asynchronous handling. In such a setup the domain registrar could for > instance store the object (certification request) and forward it upon > connectivity to the PKI for further processing. The forward may be based on a > communication connection or even manually. This asynchronous approach requires > that the object itself is self-protecting ensuring its integrity (like a PKCS#7 > wrapping of the PKCS#10 request or similar). Based on the specified BRSKI > features, we did not see the support for this type of requirements directly.
BRSKI is simply the mechanism to create a secure channel.
What happens afterwards is up to EST-RFC7030 (or something else, but the ANIMA
ACP specifies EST-RFC7030).
7030 section 4.2.3 says, near the end:
If the server responds with an HTTP [RFC2616] 202, this indicates
that the request has been accepted for processing but that a response
is not yet available. The server MUST include a Retry-After header
as defined for HTTP 503 responses. The server also MAY include
informative human-readable content. The client MUST wait at least
the specified "retry-after" time before repeating the same request.
The client repeats the initial enrollment request after the
appropriate "retry-after" interval has expired. The client SHOULD
log or inform the end-user of this event. The server is responsible
for maintaining all states necessary to recognize and handle retry
operations as the client is stateless in this regard; it simply sends
the same request repeatedly until it receives a different response
code. All other return codes are handled as specified in HTTP
[RFC2616].
so a delayed reply is permissible.
BRSKI could perhaps be more clear about whether the pledge is expected to:
1) keep the TLS connection open.
1B) do this virtually via TLS session resumption ticket
2) if it closes it, should it keep track of the Registrar certificate?
3) alternatively, should it try again and expect a voucher to be presented?
(which gets into: whether it records the nonce, and is happy with a
replay of the nonced voucher it got before)
{I found the non-standard quoting styles and HTML parts made the thread
incredibly difficult to follow. We have access to WG lists via IMAP,
so you can use quite a number of programs other than what your IT department
expects you to use for email.}
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
