Re: [Anima] unsigned voucher requests in BRSKI
HI Michael, "Also, I still am unclear if the constrained-BRSKI belongs in the constrained-voucher document. I would sure like some clear opinions." I like to react but do not understand the question. What is constrained-BRSKI? Is the proposal to split the constrained voucher document into two documents? - one describing the constrained voucher, - one describing the voucher functionality extension to EST? I am not clear what the advantage is of having two documents. The disadvantage is clear: 2 is more difficult than 1. Peter___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] unsigned voucher requests in BRSKI
With a single signed voucher format, it's clear that if the pledge sends an unsigned voucher request that the Registrar should send a CMS signed voucher request, and ask for a CMS signed voucher. I have used the term "parboiled" for the artifact from Registrar to MASA, and "raw" for the artifact from Pledge to Registar. Not everyone liked those terms, but I used in my code. With the addition of CBOR, and COSE, we have a bunch of possibilities for the (parboiled) artifact from the Registrar to the MASA: 1) CMS signed JSON, containing (prior=CMS signed JSON) 2) CMS signed CBOR, containing (prior=CMS signed CBOR) 3) COSE signed CBOR, containing (prior=COSE signed CBOR) 4) CMS signed JSON, containing unsigned JSON. 5) CMS signed JSON, containing unsigned CBOR. 6) CMS signed CBOR, containing unsigned CBOR. I don't think we ever should be embedding JSON based artifacts inside CBOR, so there are some possibilities that I've ruled out already. Argue the point. I have up to this point assumed that 1) COSE signed CBOR pledge requests result in COSE voucher artifacts. 2) CMS signed JSON pledge requests result in CMS voucher artifacts. 3) CMS signed CBOR pledge requests result in CMS signed CBOR voucher artifacts. When the Pledge request is unsigned JSON... all we know is that it's JSON. I think that this means that the parboiled artifact should be CMS signed JSON, and it should return a CMS signed voucher to the pledge. Of course, the *MASA* knows. The Registrar can set the Accept: header to */*, and see what if understands what is returned. This seems like a poor way to get interoperable systems. Also, I still am unclear if the constrained-BRSKI belongs in the constrained-voucher document. I would sure like some clear opinions. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] BRSKI support for asynchronous processing
On 2018-11-26 02:09, Eliot Lear wrote: > Hi Steffen > > >> On 23 Nov 2018, at 20:27, Fries, Steffen wrote: >> >> Hi Eliot >> We are currently in the process of discussing different scenarios and approaches for the onboarding of (IoT) devices in plants, substations, or cloud-based services. The current BRSKI document provides here a good approach to address the case in which a pledge has an online connection to a domain registrar to request a voucher for enrolling in a target domain including the enrollment at the PKI. For the enrollment there exists the binding between the certification request (as PKCS#10 object) and the communication connection. I would see this as synchronous approach, as the interaction between the pledge and the domain registrar and also the PKI (CA) is based on a “live” communication connection. >>> >>> I think the way to put this is that the Registrar is assumed to be >>> integral/co-resident with the CA. >> >> I assumed it to be collocates with the RA and that the CA is separate. > > Ok, well there we have it ;-) > >>> 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. >>> >>> >>> To be clear, are we concerned about the EST request or the BRSKI request? >>> The CA need not be available for BRSKI, but it does need to be available >>> for EST. >> >> I should have been more specific. I was referring to the EST request. The >> BRSKI request regarding the voucher is assumed to a proxy residing inside >> the plant. I assumed a strong binding of EST and BRSKI. > > > Right. And so with this, I think we do indeed have some questions: > > Does the registrar have to play the role of “store and forward” and retain > state or is it better to say, “Call me back another time”? > If we do want the registrar to retain state, then intermediate states need to > be defined in EST, and perhaps in other mechanisms as well, to say, “Do you > have my credential now?” > If we are assuming that the registrar and the CA are not co-resident, then > there is a question of protecting the credential, as you mention. Should > that credential returned be encrypted? > > And so the real question, to me, is whether or not we are handling the case > where one has something of a roaming CA, where it is only present on > occasion, or has to handle (re)enrolments periodically. Coud you (both of you, because the answers might be different) give a concrete description of the real-world scenarios you are thinking about? Because to me, it isn't clear where these requirements are coming from. In particular, are they part of autonomic networking, or do they fit elsewhere? Brian Brian ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] BRSKI support for asynchronous processing
Hi Steffen > On 23 Nov 2018, at 20:27, Fries, Steffen wrote: > > Hi Eliot > >>> We are currently in the process of discussing different scenarios and >>> approaches for the onboarding of (IoT) devices in plants, substations, or >>> cloud-based services. The current BRSKI document provides here a good >>> approach to address the case in which a pledge has an online connection to >>> a domain registrar to request a voucher for enrolling in a target domain >>> including the enrollment at the PKI. For the enrollment there exists the >>> binding between the certification request (as PKCS#10 object) and the >>> communication connection. I would see this as synchronous approach, as the >>> interaction between the pledge and the domain registrar and also the PKI >>> (CA) is based on a “live” communication connection. >> >> I think the way to put this is that the Registrar is assumed to be >> integral/co-resident with the CA. > > I assumed it to be collocates with the RA and that the CA is separate. Ok, well there we have it ;-) >> >>> >>> 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. >> >> >> To be clear, are we concerned about the EST request or the BRSKI request? >> The CA need not be available for BRSKI, but it does need to be available for >> EST. > > I should have been more specific. I was referring to the EST request. The > BRSKI request regarding the voucher is assumed to a proxy residing inside the > plant. I assumed a strong binding of EST and BRSKI. Right. And so with this, I think we do indeed have some questions: Does the registrar have to play the role of “store and forward” and retain state or is it better to say, “Call me back another time”? If we do want the registrar to retain state, then intermediate states need to be defined in EST, and perhaps in other mechanisms as well, to say, “Do you have my credential now?” If we are assuming that the registrar and the CA are not co-resident, then there is a question of protecting the credential, as you mention. Should that credential returned be encrypted? And so the real question, to me, is whether or not we are handling the case where one has something of a roaming CA, where it is only present on occasion, or has to handle (re)enrolments periodically. Right? Eliot signature.asc Description: Message signed with OpenPGP ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
