Indirect CRL CLI and support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

I have the following PKI:

        root_ca
         /   \
 localhost   signing_ca -
             /    |      \
         admin   friend   referrer -
                             |      \
                          referred   referred_bad_indirect (R)

'admin', 'friend', 'referred', and 'referred_bad_indirect' are all client
certificates while the others are CAs ('referrer' has a 'pathlen' of '0').
My goal is to revoke the 'referred_bad_indirect' certificate via the
'signing_ca' using an indirect CRL.

>From what I've read on an old forum post about Indirect CRLs [1] it seems
possible to add the "CRL Distribution Points" extension [2] to the
'referred_bad_indirect' certificate and to add the "Issuing Distribution
Point" extension [3] to the issued CRL; however, it seems that the CRL
also needs to have at least one "Certificate Issuer" extension [4] for each
certificate that is not revoked by the CRL issuer.  This does not appear to
be possible with the current `crl` tool provided by OpenSSL as the CRL is
generated from the plaintext database which does not appear to have support
for certificates issued by other CAs.

For completeness, I tried out [5] a set-up similar to the one mentioned in the
old Indirect CRL forum post mentioned earlier [1]:

        root_ca -----------------------
         /   \                         \
 localhost   signing_ca_indirectcrl     crl_ca
             /           \
        friend_indirect   friend_bad_indirect (R)

I was able to get the "CRL Distribution Points" extension added to
'friend_indirect' and 'friend_bad_indirect' and also the "Issuing Distribution
Point" to the CRL generated by 'crl_ca', but was not able to verify that
'friend_bad_indirect' was actually revoked, which I expect is due to the fact
that the CRL does not have a "Certificate Issuer" extension and the CRL
issuer does not match the issuer of the 'friend_bad_indirect' certificate,
which is how I interpet [1]:

 As written, both user credentials successfully validate because the CRL
 generated does not include the issuer extension on each of its entries.  If
 you choose common names such that the CA credential, CRL issuer credential, and
 CRL issuer named in the user certificates are all the same, the verify command
 will successfully recognize that one of the user credentials has been revoked.

So at this point it seems to be that the problem is a lack of the "Certificate
Issuer" extension on the generated CRL.  My questions are thus:

 1) Is it possible to generate an indirect CRL with appropriate
    "Certificate Issuer" extensions via the OpenSSL CLI tools?
 2) If not, is this supported via the library API?
 3) Does OpenSSL fully support verifying an indirect CRL if one is
    provided?
 4) Lastly, referring to the first PKI, what would happen if
    'referred_bad_indirect' left out its "CRL Distribution Points"
    extension (perhaps a lazy or malevolent 'referrer' CA), but the
    'signing_ca' issued an indirect CRL with 'referred_bad_indirect'
    revoked?  Would the revocation be ignored because
    'referred_bad_indirect' lacked a "CRL Distribution Points" extension
    or would it the revocation be accepted regardless because it's in
    the CRL?

My version of OpenSSL is 'OpenSSL 1.1.1g  21 Apr 2020', provided by the Gentoo
system distribution.

Thanks,
Wade

[1] http://openssl.6102.n7.nabble.com/Re-openssl-org-3097-Incorrect-revocation-status-with-indirect-CRL-td47482.html

[2] https://tools.ietf.org/html/rfc5280#section-4.2.1.13

[3] https://tools.ietf.org/html/rfc5280#section-5.2.5

[4] https://tools.ietf.org/html/rfc5280#section-5.3.3

[5] https://github.com/clinew/inspircdtests/blob/indirect_crl/afr.sh#L437



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux