Expected cert-path validation behavior - Openssl

This is a discussion on Expected cert-path validation behavior - Openssl ; I was browsing through NIST's "Conformance Testing of Relying Party Client Certificate Path Processing Logic" document where I am not sure whether "Test 19" has the correct conformance expectation: --- Test 19-- The following path should not be successfully validated; ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Expected cert-path validation behavior

  1. Expected cert-path validation behavior

    I was browsing through NIST's "Conformance Testing of Relying Party
    Client Certificate Path Processing Logic" document where I am not
    sure whether "Test 19" has the correct conformance expectation:
    --- Test 19--
    The following path should not be successfully validated; it contains a
    path without
    revocation data:
    Trust Anchor CP.01.01, Trust Anchor CRL CP.01.01, Intermediate
    Certificate CP.05.01,
    End Certificate CP.05.01
    ----

    What the above test-case says is the following:
    1. There is a 3 level cert-chain:
    TrustAnchor(root)-->IntermediateCert#37-->EndCert#38
    2. There is a CRL signed by the same root as above and having only one
    entry: that of an intermediate CA Ca1-06.01(#39) not part of the above
    chain.

    But then this is what RFC3280(Certs & CRL Policies) says:
    6.3.2 Initialization and Revocation State Variables .......
    (b) cert_status: ..... This variable is initialized to the
    special value UNREVOKED.

    6.3.3 CRL Processing

    This algorithm begins by assuming the certificate is not revoked.
    The algorithm checks one or more CRLs until either the certificate
    status is determined to be revoked or sufficient CRLs have been
    checked to cover all reason codes.


    Taking the snips from sections 6.3.2 and 6.3.3 above, it is evident
    that absence of a cert's entry from the CRL means accept the cert. But
    the doc says reject it because "it contains a path without
    revocation data". What am I missing?

    Thanks in advance,
    Vineet
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  2. Re: Expected cert-path validation behavior

    Hello Vineet:

    On October 15, 2008 02:40:52 pm Vineet Kumar wrote:
    > I was browsing through NIST's "Conformance Testing of Relying Party
    > Client Certificate Path Processing Logic" document where I am not
    > sure whether "Test 19" has the correct conformance expectation:
    > --- Test 19--
    > The following path should not be successfully validated; it contains a
    > path without
    > revocation data:
    > Trust Anchor CP.01.01, Trust Anchor CRL CP.01.01, Intermediate
    > Certificate CP.05.01,
    > End Certificate CP.05.01
    > ----
    >

    So - what the chain is is:

    Trust Anchor (with a CRL that could have the Intermediate Cert in it)
    Intermediate Cert (with *no* CRL that could have the end certificate in it)
    End Certificate.

    > What the above test-case says is the following:
    > 1. There is a 3 level cert-chain:
    > TrustAnchor(root)-->IntermediateCert#37-->EndCert#38
    > 2. There is a CRL signed by the same root as above and having only one
    > entry: that of an intermediate CA Ca1-06.01(#39) not part of the above
    > chain.
    >
    > But then this is what RFC3280(Certs & CRL Policies) says:
    > 6.3.2 Initialization and Revocation State Variables .......
    > (b) cert_status: ..... This variable is initialized to the
    > special value UNREVOKED.
    >
    > 6.3.3 CRL Processing
    >
    > This algorithm begins by assuming the certificate is not revoked.
    > The algorithm checks one or more CRLs until either the certificate
    > status is determined to be revoked or sufficient CRLs have been
    > checked to cover all reason codes.
    >
    >
    > Taking the snips from sections 6.3.2 and 6.3.3 above, it is evident
    > that absence of a cert's entry from the CRL means accept the cert. But
    > the doc says reject it because "it contains a path without
    > revocation data". What am I missing?
    >

    Well, as I hinted at above, there is no revocation information available for
    the end certificate itself (the Intermediate Certificate is not publishing a
    CRL). Thus, if you are using strict revocation information checking, the
    above chain should fail, because you can't look up the status of the end
    certificate.

    If you want a good example of code for a PDVal tool that implements all of the
    tests in the NIST suite, please take a look at Pathfinder - it's available
    at:

    http://www.carillon.ca/tools.php

    Have fun.

    --
    Patrick Patterson
    President and Chief PKI Architect,
    Carillon Information Security Inc.
    http://www.carillon.ca
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  3. Re: Expected cert-path validation behavior

    It doesn't look like cert_crl() in openssl code follows what you refer
    to as "strict" revocation check. Neither does the RFC. Is there a
    doc/RFC that outlines strict revocation criteria? Am I right in saying
    that openssl does not do that?

    Thanks,

    Vineet
    On Wed, Oct 15, 2008 at 11:48 AM, Patrick Patterson
    wrote:
    > Hello Vineet:
    >
    > On October 15, 2008 02:40:52 pm Vineet Kumar wrote:
    >> I was browsing through NIST's "Conformance Testing of Relying Party
    >> Client Certificate Path Processing Logic" document where I am not
    >> sure whether "Test 19" has the correct conformance expectation:
    >> --- Test 19--
    >> The following path should not be successfully validated; it contains a
    >> path without
    >> revocation data:
    >> Trust Anchor CP.01.01, Trust Anchor CRL CP.01.01, Intermediate
    >> Certificate CP.05.01,
    >> End Certificate CP.05.01
    >> ----
    >>

    > So - what the chain is is:
    >
    > Trust Anchor (with a CRL that could have the Intermediate Cert in it)
    > Intermediate Cert (with *no* CRL that could have the end certificate in it)
    > End Certificate.
    >
    >> What the above test-case says is the following:
    >> 1. There is a 3 level cert-chain:
    >> TrustAnchor(root)-->IntermediateCert#37-->EndCert#38
    >> 2. There is a CRL signed by the same root as above and having only one
    >> entry: that of an intermediate CA Ca1-06.01(#39) not part of the above
    >> chain.
    >>
    >> But then this is what RFC3280(Certs & CRL Policies) says:
    >> 6.3.2 Initialization and Revocation State Variables .......
    >> (b) cert_status: ..... This variable is initialized to the
    >> special value UNREVOKED.
    >>
    >> 6.3.3 CRL Processing
    >>
    >> This algorithm begins by assuming the certificate is not revoked.
    >> The algorithm checks one or more CRLs until either the certificate
    >> status is determined to be revoked or sufficient CRLs have been
    >> checked to cover all reason codes.
    >>
    >>
    >> Taking the snips from sections 6.3.2 and 6.3.3 above, it is evident
    >> that absence of a cert's entry from the CRL means accept the cert. But
    >> the doc says reject it because "it contains a path without
    >> revocation data". What am I missing?
    >>

    > Well, as I hinted at above, there is no revocation information available for
    > the end certificate itself (the Intermediate Certificate is not publishing a
    > CRL). Thus, if you are using strict revocation information checking, the
    > above chain should fail, because you can't look up the status of the end
    > certificate.
    >
    > If you want a good example of code for a PDVal tool that implements all of the
    > tests in the NIST suite, please take a look at Pathfinder - it's available
    > at:
    >
    > http://www.carillon.ca/tools.php
    >
    > Have fun.
    >
    > --
    > Patrick Patterson
    > President and Chief PKI Architect,
    > Carillon Information Security Inc.
    > http://www.carillon.ca
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  4. Re: Expected cert-path validation behavior

    On Wed, Oct 15, 2008, Vineet Kumar wrote:

    > It doesn't look like cert_crl() in openssl code follows what you refer
    > to as "strict" revocation check. Neither does the RFC. Is there a
    > doc/RFC that outlines strict revocation criteria? Am I right in saying
    > that openssl does not do that?
    >


    OpenSSL has several options relating to CRL checking. It can perform no
    checking, checking of just the EE cert and the whole chain.

    The RFC3280 behaviour in the absence of a CRL is determined by the last
    paragraph of 6.3.3 where the status is UNDETERMINED.

    It has to be this way or an attacker could block the downloading of a CRL and
    allow a revoked certificate to be used.

    Steve.
    --
    Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
    OpenSSL project core developer and freelance consultant.
    Homepage: http://www.drh-consultancy.demon.co.uk
    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  5. Re: Expected cert-path validation behavior

    Yes, but it looks like if openssl has to conform to JITC tests then in
    order to accept an EE, a CRL **signed by EE's CA** better be present.
    It doesn't matter if a CRL is present but signed by some other CA in
    the cert-chain, no? This strictness of who the CRL's signer should be
    can make sense in real world but it doesn't look like openssl has any
    flag to conform to such rules. Pl. correct me if I am wrong.

    Vineet

    On Wed, Oct 15, 2008 at 1:26 PM, Dr. Stephen Henson wrote:
    > On Wed, Oct 15, 2008, Vineet Kumar wrote:
    >
    >> It doesn't look like cert_crl() in openssl code follows what you refer
    >> to as "strict" revocation check. Neither does the RFC. Is there a
    >> doc/RFC that outlines strict revocation criteria? Am I right in saying
    >> that openssl does not do that?
    >>

    >
    > OpenSSL has several options relating to CRL checking. It can perform no
    > checking, checking of just the EE cert and the whole chain.
    >
    > The RFC3280 behaviour in the absence of a CRL is determined by the last
    > paragraph of 6.3.3 where the status is UNDETERMINED.
    >
    > It has to be this way or an attacker could block the downloading of a CRL and
    > allow a revoked certificate to be used.
    >
    > Steve.
    > --
    > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
    > OpenSSL project core developer and freelance consultant.
    > Homepage: http://www.drh-consultancy.demon.co.uk
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  6. Re: Expected cert-path validation behavior

    Vineet Kumar wrote:
    > Yes, but it looks like if openssl has to conform to JITC tests then in
    > order to accept an EE, a CRL **signed by EE's CA** better be present.
    > It doesn't matter if a CRL is present but signed by some other CA in
    > the cert-chain, no? This strictness of who the CRL's signer should be
    > can make sense in real world but it doesn't look like openssl has any
    > flag to conform to such rules. Pl. correct me if I am wrong.
    >

    The case where the CRL is signed by someone other than the certificate's
    signer is the reason that the CRL Issuer field of the CRL Distribution
    point is available.

    From RFC3280:

    "If the certificate issuer is not the CRL issuer, then the cRLIssuer
    field MUST be present and contain the Name of the CRL issuer."


    This makes it VERY unambiguous - the CRL for a given certificate must be
    signed by it's immediate issuer.

    Consequently, that is why the NIST test that you mentioned before fails.
    It is not good enough to have some "CRL signed by some other CA in the
    Cert Chain". Absent the CRLIssuer field, the CRL *MUST* be signed by the
    same CA as that which signed the End Certificate.

    Have fun.

    Patrick.


    > Vineet
    >
    > On Wed, Oct 15, 2008 at 1:26 PM, Dr. Stephen Henson wrote:
    >> On Wed, Oct 15, 2008, Vineet Kumar wrote:
    >>
    >>> It doesn't look like cert_crl() in openssl code follows what you refer
    >>> to as "strict" revocation check. Neither does the RFC. Is there a
    >>> doc/RFC that outlines strict revocation criteria? Am I right in saying
    >>> that openssl does not do that?
    >>>

    >> OpenSSL has several options relating to CRL checking. It can perform no
    >> checking, checking of just the EE cert and the whole chain.
    >>
    >> The RFC3280 behaviour in the absence of a CRL is determined by the last
    >> paragraph of 6.3.3 where the status is UNDETERMINED.
    >>
    >> It has to be this way or an attacker could block the downloading of a CRL and
    >> allow a revoked certificate to be used.
    >>
    >> Steve.
    >> --
    >> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
    >> OpenSSL project core developer and freelance consultant.
    >> Homepage: http://www.drh-consultancy.demon.co.uk
    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> Development Mailing List openssl-dev@openssl.org
    >> Automated List Manager majordomo@openssl.org
    >>

    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org


    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


  7. Re: Expected cert-path validation behavior

    Thanks, I am convinced now and also reconciled what you said with the
    code in the subroutine: check_crl().

    Thanks once again,

    Vineet

    On Wed, Oct 15, 2008 at 2:51 PM, Patrick Patterson
    wrote:
    > Vineet Kumar wrote:
    >> Yes, but it looks like if openssl has to conform to JITC tests then in
    >> order to accept an EE, a CRL **signed by EE's CA** better be present.
    >> It doesn't matter if a CRL is present but signed by some other CA in
    >> the cert-chain, no? This strictness of who the CRL's signer should be
    >> can make sense in real world but it doesn't look like openssl has any
    >> flag to conform to such rules. Pl. correct me if I am wrong.
    >>

    > The case where the CRL is signed by someone other than the certificate's
    > signer is the reason that the CRL Issuer field of the CRL Distribution
    > point is available.
    >
    > From RFC3280:
    >
    > "If the certificate issuer is not the CRL issuer, then the cRLIssuer
    > field MUST be present and contain the Name of the CRL issuer."
    >
    >
    > This makes it VERY unambiguous - the CRL for a given certificate must be
    > signed by it's immediate issuer.
    >
    > Consequently, that is why the NIST test that you mentioned before fails.
    > It is not good enough to have some "CRL signed by some other CA in the
    > Cert Chain". Absent the CRLIssuer field, the CRL *MUST* be signed by the
    > same CA as that which signed the End Certificate.
    >
    > Have fun.
    >
    > Patrick.
    >
    >
    >> Vineet
    >>
    >> On Wed, Oct 15, 2008 at 1:26 PM, Dr. Stephen Henson wrote:
    >>> On Wed, Oct 15, 2008, Vineet Kumar wrote:
    >>>
    >>>> It doesn't look like cert_crl() in openssl code follows what you refer
    >>>> to as "strict" revocation check. Neither does the RFC. Is there a
    >>>> doc/RFC that outlines strict revocation criteria? Am I right in saying
    >>>> that openssl does not do that?
    >>>>
    >>> OpenSSL has several options relating to CRL checking. It can perform no
    >>> checking, checking of just the EE cert and the whole chain.
    >>>
    >>> The RFC3280 behaviour in the absence of a CRL is determined by the last
    >>> paragraph of 6.3.3 where the status is UNDETERMINED.
    >>>
    >>> It has to be this way or an attacker could block the downloading of a CRL and
    >>> allow a revoked certificate to be used.
    >>>
    >>> Steve.
    >>> --
    >>> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
    >>> OpenSSL project core developer and freelance consultant.
    >>> Homepage: http://www.drh-consultancy.demon.co.uk
    >>> __________________________________________________ ____________________
    >>> OpenSSL Project http://www.openssl.org
    >>> Development Mailing List openssl-dev@openssl.org
    >>> Automated List Manager majordomo@openssl.org
    >>>

    >> __________________________________________________ ____________________
    >> OpenSSL Project http://www.openssl.org
    >> Development Mailing List openssl-dev@openssl.org
    >> Automated List Manager majordomo@openssl.org

    >
    > __________________________________________________ ____________________
    > OpenSSL Project http://www.openssl.org
    > Development Mailing List openssl-dev@openssl.org
    > Automated List Manager majordomo@openssl.org
    >

    __________________________________________________ ____________________
    OpenSSL Project http://www.openssl.org
    Development Mailing List openssl-dev@openssl.org
    Automated List Manager majordomo@openssl.org


+ Reply to Thread