Michael Richardson <mcr+i...@sandelman.ca> 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). I realized the exclusive close binding to EST and was questioning this based on some use cases mentioned in an earlier email like enrolling device in a plant / building / train wagon. I completely understand the mandatory support on the domain registrar side but not the pledge side. My understanding from ANIMA ACP is that one has to support EST on an ACP node in any case, even if a different enrollment protocol is used. It may not be a problem for new products, but existing products leveraging the voucher approach may need to be adopted more than functionally necessary. Also, if self-containment of the certification request would help to address asynchronous use cases, EST as is may have some restrictions.
> 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. Yes, the pledge may retry, but there are certain restrictions: - You either have to keep the TLS connection open (as you mentioned below) or perform resumption. Depending on the use case, you may not have a direct connection to the CA so it may take some time before the certificate will be provided. If you chose resumption the pledge needs to generate a new PKCS#10 request to take the changed tls_unique into account. This will also require the EST server to keep track of repeated certification requests from the same pledge. I also made some further notes below in your list. - If the RA/CA is not directly reachable, the authorization decision for the certification request needs to be done on the EST server (well, this is actually also the case for the online case). Not a problem if the RA is co-located with the Domain Registrar. If the RA/CA are located in the operators backend, the Domain Registrar would basically perform a store and forward of the certification request/response and may not be involved directly in the authorization. The binding to the requesting identity would be removed after the first EST server and not be visible to the (backend) RA. Besides authorization also the tracking of components is often done in the central location in conjunction with the RA. An example may be a train wagon in which the components shall be equipped with the certificates of the new owner. The domain is basically the wagon and issuing certificates would be done in the railway companies backend once the wagon is connected. To prepare this, the components in the wagon can already prepare this be registering locally at the domain registrar. > BRSKI could perhaps be more clear about whether the pledge is expected to: > 1) keep the TLS connection open. Probably the best to have less recreation of PKCS#10 requests > 1B) do this virtually via TLS session resumption ticket Possible but requires to recreate the PKCS#10 request with the new tls_unique value > 2) if it closes it, should it keep track of the Registrar certificate? Definitely to ensure it is taking to the same registrar afterwards. Other actions like the time synchronization have been done before based on the Registrar certificate. If that changes, what would be the consequences? > 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) If it records the nonce, would that conflict with the statement in BRSKI section 5.2, that the nonce MUST NOT be reused for multiple bootstrapping attempts? Maybe not, as it may not be counted as attempt as the pledge was not generating a new voucher request. Best regards Steffen > > > > {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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 > IoT consulting =- > > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima