1

According to this explanation:

Manually walking through the signature validation of a certificate

I'd like to know how is the validation process of an RFC 5755 attribute certificates, because it does not carry the public key from it's issuer. I still did not find a good and clear explanation.

Fellipe Theophilo Barata
  • 61
  • 3

1 Answers1

1

because it does not carry the public key from it's issuer

A Public Key Certificate (PKC) doesn't contain the public key from it's issuer neither. A PKC contains the name of the issuer and is digitally signed by that issuer.

Similarly, an Attribute Certificate (AC) also contains an Issuer field (section 4.2.3 of RFC 5755, compared to section 4.1.2.4 of RFC 5280), and an Signature Algorithm (section 4.2.4 of RFC 5755, compared to section 4.1.2.3 of RFC 5280).

Section 5 of RFC 5755 describes the validation process and includes:

  1. The AC signature must be cryptographically correct, and the AC issuer's entire PKC certification path MUST be verified in accordance with [PKIXPROF].

[PKIXPROF] here refers to RFC5280 (section 6). Therefore, an AC is verified the same way as a PKC.

Community
  • 1
garethTheRed
  • 1,392
  • 7
  • 12
  • Thanks for explanation. But the PKC has a public key and you said there is not. I didn't understand. The public key is used to check it's signature(which was made by it's issuer), and for the SSL/TLS traffic, in which a browser, when accessing a https address, gets the certificate from the website, checks it's signature and, from this point forward, encrypts the data before sending to the site. Correct? – Fellipe Theophilo Barata Feb 21 '19 at 20:18
  • 1
    The PKC does not have the issuer's public key. Instead, it has its (the subject) public key. The certificate is signed by the issuer's private key and this can be checked using the issuer's public key, which can be accessed from the issuer's certificate. – garethTheRed Feb 21 '19 at 21:06
  • I'd like do understand the CRL validation. From: https://tools.ietf.org/html/rfc5280#page-94 : " (f) Obtain and validate the certification path for the issuer of the complete CRL. The trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set. (g) Validate the signature on the complete CRL using the public key validated in step (f)." – Fellipe Theophilo Barata Feb 26 '19 at 14:11
  • I have a problem in that I cannot sign the CRL with the same RsaPrivateKey as I'm signing the certificates, because I'm using a pkcs11 device, and the CertificateListBuilder build function constructor receives the private key as argument. So, I'd like to understand this validation process in order to know if I use other certificate (from the same issuer) to sign the CRL will be in discordance of this RFC. – Fellipe Theophilo Barata Feb 26 '19 at 14:15
  • Does https://security.stackexchange.com/questions/91680/how-to-trust-a-ca-to-sign-a-crl-but-not-a-cert help? – garethTheRed Feb 26 '19 at 16:09