Can the RA certificate also be the self-signed CA?

[mcr]

We think that this degenerate model is too simple, and there should always be a CA signing the RA certificate, even if they are all hosted in the same machine.

Would it be acceptable for the Registrar to present a self-signed CA=true certificate, but it would not also have cmcRA (extension).

[csosto-pk]

I would say no. I don't see a reason why. Even if the Registrar was the CA itself, it should issue a leaf cert for the RA service.

[EskoDijk]

It would be easiest if we honor the requirement of BRSKI that a Registrar is "RA" (i.e. has the cmcRA extended key usage set). So, a Registrar having a CA certificate is not sufficient in that case; MASA will not accept this per BRSKI.

We can mandate that a Registrar that is also the CA should have two separate certs, one RA (leaf cert) and one CA; just as good security practice.

Nevertheless, it is possible to create a cert that is both CA and RA using OpenSSL - it works; example output snippet below:

X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:92:EA:76:40:40:4A:8F:AB:4F:27:0B:F3:BC:37:9D:86:CD:72:80:F8
            X509v3 Subject Key Identifier:
                C9:08:0B:38:7D:8D:D8:5B:3A:59:E7:EC:10:0B:86:63:93:A9:CA:4C
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Certificate Sign, CRL Sign
            X509v3 Extended Key Usage:
                CMC Registration Authority, TLS Web Server Authentication, TLS Web Client Authentication

[mcr]

I agree with Esko: I think that the CA + cmcRA bit is possible, and pledges shouldn't decline that. Should it encouraged or not, I'm open to discussion.

[csosto-pk]

We can mandate that a Registrar that is also the CA should have two separate certs, one RA (leaf cert) and one CA; just as good security practice.

Agreed.

To be honest I don't see why the draft needs to deal with that in detail. RA needs cmcRA, now there could be many other scenarios of the Registrar being a web server, an Intermediate CA, a Root CA/ I do't think we need to deal with all cases in the draft.

[petervanderstok]

Fully agree

⁣Peter van der Stok consultancy@vanderstok.org

BlueMail voor Android downloaden ​

Op 25 feb. 2021 04:49, om 04:49, "Panos K." notifications@github.com schreef:

We can mandate that a Registrar that is also the CA should have two separate certs, one RA (leaf cert) and one CA; just as good security practice.

Agreed.

To be honest I don't see why the draft needs to deal with that in detail. RA needs cmcRA, now there could be many other scenarios of the Registrar being a web server, an Intermediate CA, a Root CA/ I do't think we need to deal with all cases in the draft.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/anima-wg/constrained-voucher/issues/89#issuecomment-785556276

[EskoDijk]

@csosto-pk @petervanderstok Agree to not go into detail on this topic. To avoid potential confusion I propose to add just a single paragraph in the Section 5.2 Extensions to BRSKI:

A Registrar MAY use as its identity a single certificate that is both CA and RA (with id-kp-cmcRA set), in order to reduce the size of the DTLS "certificate" handshake message sent to the Pledge, although this is not encouraged for security reasons.

[petervanderstok]

Isn't this more a topic for security considerations?

Peter Esko Dijk schreef op 2021-04-11 22:27:

@csosto-pk [1] @petervanderstok [2] Agree to not go into detail on this topic. To avoid potential confusion I propose to add just a single paragraph in the Section 5.2 Extensions to BRSKI:

A Registrar MAY use as its identity a single certificate that is both CA and RA (with id-kp-cmcRA set), in order to reduce the size of the DTLS "certificate" handshake message sent to the Pledge, although this is not encouraged for security reasons.

-- You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [3], or unsubscribe [4].

Links:

[1] https://github.com/csosto-pk [2] https://github.com/petervanderstok [3] https://github.com/anima-wg/constrained-voucher/issues/89#issuecomment-817367579 [4] https://github.com/notifications/unsubscribe-auth/ADCZGQOHBSKFKSJPLGR7NCTTIIAZPANCNFSM4XOZGCEQ

[EskoDijk]

@petervanderstok Indeed, that could fit also well - we can include a new section 11.4 "Domain Certificate Hierarchy" or "Domain Identities" or so. The normative text "MAY" was included also to force a Pledge to accept such an optional case if it occurs, in other words for the Pledge it MUST accept a Registrar RA certificate that is at the same time CA. As discussed earlier, this requirement is already implicit in BRSKI so possibly no need to repeat that.

[csosto-pk]

I am ok with the normative text being in the Sec Considerations.