%% You should probably cite draft-ietf-anima-brski-async-enroll instead of this I-D.
@techreport{fries-anima-brski-async-enroll-03,
    number =    {draft-fries-anima-brski-async-enroll-03},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/03/},
    author =    {Steffen Fries and Hendrik Brockhaus and Eliot Lear},
    title =     {{Support of asynchronous Enrollment in BRSKI}},
    pagetotal = 33,
    year =      2020,
    month =     mar,
    day =       6,
    abstract =  {This document discusses enhancements of bootstrapping of a remote secure key infrastructure (BRSKI) to also operate in domains featuring no or only timely limited connectivity to backend services offering enrollment functionality, specifically a Public Key Infrastructure (PKI). The enhancements proposed to enable this are also applied to further set of use cases in which a pledge may not have a direct connection to the registrar and is served by for instance by a commissioning tool as an agent providing registrar connectivity. In the context of deploying new devices the design of BRSKI allows for online (synchronous object exchange) and offline interactions (asynchronous object exchange) with a manufacturer's authorization service. For this it utilizes an authenticated self- contained voucher to transport the domain credentials as a signed object to establish an initial trust between a pledge and the target deployment domain. The currently supported enrollment protocol for request and distribution of deployment domain specific device certificates provides only limited support for asynchronous PKI interactions. This memo motivates the enhancement of supporting authenticated self-contained objects for certificate management by using an abstract notation. The enhancement allows on one hand off- site operation of PKI services outside the deployment domain of the pledge. This addresses specifically scenarios, in which the final authorization of a certification request of a pledge cannot be made in the deployment domain and is therefore delegated to a operator backend. On the other hand, this enhancement also facilitates the exchange of certificate management information via a pledge agent. The goal is to enable the usage of existing and potentially new PKI protocols supporting authenticated self-containment for certificate management exchanges.},
}