Various roles

[gknocke]

The protocol defines three roles, Client, CA, RA. RA certificate is signed by the CA certificate. Hard to say how this is handled when using intermediate CAs. In my understanding the RA needs to be signed by the CA which means the client and RA have the exact same issuer. The data in the response depends also on the role (CA/CA). Verification whether input data is conform with the SCEP standard is hardly feasible. It will be assumed that input data is compliant to the scep standard.

Example: The user provides libscep with a certificate store which consist of all certificates to include in the answer (RA/CA). The libscep will include them without verifying their correctness or whether they match the cert used for signing the answer. The user is assumed to stay compliant and is also expected to do the compliance check by himself.

[Javex]

Why wontfix? It seems to me that this is an important issue. I have done some reading in the standard and the distinction gets pretty clear. However it also seems that the GetCACert operation is only allowed to return more than one certificate if has an RA. Is it possible that openca-scep / sscep / OXI currently may handle multiple CA certs? Need more investigation...

[gknocke]

The distinction in the draft is pretty clear. However, it says nothing about intermediate CAs and so on. E.g. the CA must be the signer of the PKCSreq csr and the signer of the RA cert as well. But what if intermediate CAs are used? Probably the CSR will be signed from a different entity than the RA certificate which would be not possible according to SCEP spec. This can get ugly: Imagine the user wants to use a different CA for signing encryption certs and signature certs. The RA may have a different certificate than the encryption cert, than the signing cert, than the client cert. There may be multiple valid certs for all envolved entities for lecacy reasons. Since only the user knows the underlying PKI structure it should be expected that he knows which certificate(chain) he needs to provide for every possible usage within the cope of SCEP. Also he has to validate them by himself. SCEP should only verify PKiMessage against a store of certificates provided by the user, in my opinion. What is your suggestion?

[Javex]

Yes the standard is pretty clear:

An SCEP Certification Authority (CA) is the entity that signs client certificates.

But also it only ever talks about retrieving a single CA certificate (in the case where no RA is in use). This should then be verified out-of-band, e.g. using a fingerprint mechanism, before continuing. But what if I have a valid root certificate and just need the rest of them to complete the chain? Should I now look around somewhere else? No. In my opinion the SCEP server should deliver all certificates necessary to complete the chain. But that would not be standard compliant it seems: A single certificate is expected for GetCACert with no RA.

Why should it not be possible to use a different CA for creating a new cert than the one that issued the cert for the RA? Where is the problem?

I have a hard problem following the thoughts in the rest of your comment. Could you clarify?

[gknocke]

SCEP is assuming 3 drifferent roles: Client, CA, RA. This is insufficient when dealing with a PKI. I'll clarify the first thought. SCEP states:

RA certificates, if any, are signed by the CA so there is no need to authenticate them against the out->of-band data.

I conclude. RA provides the client with 2 certificates, RA + CA. RA MUST be signed by CA. No further data, no certificate chains. It follows: CA must be a self-signed CA and trusted. RA must be signed by this certificate. CA is expected to sign the client certificate. This is okay iff there is exactly one CA, one RA and no intermediate CAs.

[Javex]

Running sscep against OXI on GetCACert: It returns three certificates: The SCEP cert (could be said to be RA), the Root CA (which has signed the SCEP cert) and a CA ONE cert (which is not required here but could be the signer of the SCEP cert as it is signed by the Root CA).

The content type is "application/x-x509-ca-ra-cert", which is okay since this allows multiple certificates. So it is correct that we don't need to authenticate the SCEP cert or the CA ONE cert, just the Root CA cert.

Now what if the SCEP cert were signed by CA ONE? We could also provide CA TWO and have both anchored at the Root CA. Then CA TWO can be used for a different purpose, e.g. the signer of the new certificate as requested by CSR.

This should be transparent: We communicated just with the RA, do not worry about the actual CA at all. We submit a CSR to the RA, encrypt all stuff to it and verify signatures from it. The resulting cert can be signed by ANY CA that anchors in our Root CA (actually, does the standard say it needs to be the SAME Root CA? Not sure, but would make sense...).

Only problem is how to find the Root CA from a stack of certificates so that we can verify it? Maybe OpenSSL has a convenience function for that?

On 18.03.2015 11:19, Gideon Knocke wrote:

SCEP is assuming 3 drifferent roles: Client, CA, RA. This is insufficient when dealing with a PKI. I'll clarify the first thought. SCEP states:

RA certificates, if any, are signed by the CA so there is no need
to authenticate them against the out->of-band data.

I conclude. RA provides the client with 2 certificates, RA + CA. RA MUST be signed by CA. No further data, no certificate chains. It follows: CA must be a self-signed CA and trusted. RA must be signed by this certificate. CA is expected to sign the client certificate. This is okay iff there is exactly one CA, one RA and no intermediate CAs.

— Reply to this email directly or view it on GitHub https://github.com/Javex/libscep/issues/18#issuecomment-82877481.

[Javex]

Okay so its disallowed by the standard but not necessarily required. Maybe add an additional flag that verifies the standard. Not important right now.