Michael Richardson <[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).
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 <[email protected]>, Sandelman Software Works -= IPv6
> IoT consulting =-
>
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
