[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Denis,
Thanks for spending considerable time to comment on this draft.
The typo is noted and will be fixed.
Some generic comments before we go into the specific text proposals:
You point out some well known issues related to the lack of absolute
cryptographic binding between CRL and certificates where the certificate
and CRL is not signed by the same key.
A certificate is always authoritative to identify the correct CRL for
its validation. But since the certificate is signed before the latest
CRL that validates it, the certificate can't cryptographically bind
(e.g. hash) the CRL but needs to identify it by verifiable attributes
such as issuer name and storage location.
This issue is however NOT introduced by this draft. It is simply a
generic issue with RFC 3280/X.509, especially for indirect CRLs
In this context I really can't see the difference between scenario A and
scenario B. It seems to me that the same validation principles apply to
both scenarios.
Section 6.3 of RFC 3280 is dealing with CRL validation and the
requirement to validate the CRL through a valid certificate path.
This draft only introduces a new way to point to locate certificates
that can be helpful in building this path. It seems to me from that
perspective that specific requirements on CRL path building are outside
the scope of this draft.
>Stefan Santesson
>Program Manager - Standards Liaison
>Windows Security
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Denis Pinkas
> Sent: den 11 april 2005 00:59
> To: Stefan Santesson; Russ Housley
> Cc: pkix
> Subject: Comments on <draft-ietf-pkix-crlaia-00.txt>
>
>
> Stefan and Russ,
>
> It took me several hours to write this long e-mail, hence for the
delay
> (in addition to the time for shooting a few "big five" with my
camera).
>
> This e-mail identifies several security issues, which are not
currently
> mentionned in the security considerations section. It finally proposes
a
> rewritting of the introduction and provides a strawman for a new
security
> considerations section (see the proposal at the end of this e-mail).
>
> Let us consider two different scenarios where this new extension would
be
> considered.
>
> Scenario A: The relying party does not trust any CRL issuer in
particular
> and will simply use the CRL Issuer designated by the Certificate
Issuer by
> means of the CRL DP extension.
>
> Scenario B: The relying party trusts at least a specific CRL issuer
and
> will
> get the CRLs from that CRL Issuer and then will make sure that the
> information contained in them matches with the designation of the
> Certificate Issuer.
>
> SCENARIO A
>
> In scenario A, the relying party will use the CRL DP from the target
> certificate to get the CRL and then will make sure that the CRL that
has
> been retrieved from that location is signed by the right CRL Issuer.
>
> The CRL DP extension is defined as:
>
> DistributionPoint ::= SEQUENCE {
> distributionPoint [0] DistributionPointName
OPTIONAL,
> reasons [1] ReasonFlags OPTIONAL,
> cRLIssuer [2] GeneralNames OPTIONAL }
>
> At least the distributionPoint field shall be present. It is supposed
it
> contains a general name of type URI, which is a pointer to the current
CRL
> for the associated reasons and will be issued by the associated
cRLIssuer.
>
> The CRL itself shall contain an IDP (Issuing Distribution Point).
>
> The IDP extension is defined as:
>
> issuingDistributionPoint ::= SEQUENCE {
> distributionPoint [0] DistributionPointName
OPTIONAL,
> onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
> onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
> onlySomeReasons [3] ReasonFlags OPTIONAL,
> indirectCRL [4] BOOLEAN DEFAULT FALSE,
> onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
>
> A necessary but insufficient condition is that the distributionPoint
field
> from the IDP extension shall be equal to the distributionPoint field
from
> the CRL DP extension.
>
> This is insufficient since a URL like
URL=http://corppki/crl/extranet.crl
> could be used by accident by two different CAs, or a CA under the same
> root
> key could maliciously use that URL or a different and re-route all
packets
> to an address where that CRL is made available.
>
> This means that the tupple CRL DP extension from certificates and the
IDP
> extension from CRLs even if then match are insufficient to make sure
that
> it
> is the right CRL that has been retrieved. This is "normal" until some
> cryptographic checksums are used to make sure that this is the right
> information.
>
> Any CA, trusted under a root key, could use an IDP extension in a CRL
> matching the IDP extension from another true CRL and unless other
tests
> are
> performed, would fool relying parties.
>
> This is the major reason why the current document in its current form
is
> dangerous to be published. It incorporates verification concepts which
are
> missing major security issues. The security consideration section
attempts
> to tackle the issue but it misses the point.
>
> The major problem is not the definition of this new extension that
could
> provide untrusted but "useful" information, but the concepts behind
path
> construction.
>
> SCENARIO B
>
> In scenario B, the relying party contacts the location of a trusted
CRL
> Issuer and wants to verify that the retrieved CRL is correctly signed.
>
> Suppose that the retrieved CRL contains the newly defined extension
which
> specifies one or more accessLocation fields that contains references
to CA
> certificates superior to the CRL containing this extension.
>
> Let us consider that one accessLocation field contains the following
URL:
> http://corppki/aia/certificates.crt
>
> The relying party will access this URL to retrieve some CA
certificates.
> Nothing at this point would prevent a network attack so that access to
> this
> URL is re-routed to another location. The question is how the relying
> party
> can figure out and what kind of tests it should make. The draft is
silent
> about this.
>
> It does not help the end-user to define new extensions if at the same
time
> there are no explanations or guidance to tell how are they should be
used
> in
> order to build a secure system.
>
> Let us suppose that the information retrieved is just "useful"
> certificates
> at this time (i.e. untrusted).
>
> In order to build a path, a relying party needs to make sure of the
name
> of
> the CRL Issuer, which means not simply knowing the DN of the CRL
issuer
> but
> also all the other DNs from the upper CAs up to a root key. This kind
of
> assumption or explanations is currently missing in the draft.
>
> Scenario B would be correctly supported if the text would mention two
> points:
>
> 1) the location of the "trusted CRL Issuer" must be locally known,
> 2) the name of the "trusted CRL Issuer" must be locally known,
> which means not simply knowing the DN of the CRL issuer,
> but also all the other DNs from the upper CAs up to a root key.
>
> Using the "useful" certificates that would be retrieved using that new
> extension, the relying party would then build a certification path to
> validate the retrieved CRL. Additional details, described nowhere,
should
> be
> given so that it can be sure that it is a CRL Issuer and not a CA, etc
...
>
> Then the relying party knows that he got a correct indirect CRL and
has to
> make sure that the name of the CA is present. Additional details would
be
> needed to explain name matching taking into account that two CAs could
be
> given the same DN by two different CAs.
>
>
> CONCLUSION:
>
> I see two ways to progress:
>
> a) "avoid" the problem *now* and leave it for later. This means
> saying that this extension may provide useful information that
> still needs to be verified to be trusted. The security
> considerations section would tackle the issue but not provide
> the full answer.
>
> b) address the issue and say how to handle CRLs when they are not
> signed
> by the CA.
>
> In case of a), that is the easiest *temporary* solution, I would
propose
> to
> rewrite the introduction in the following way :
>
> RFC 3280 [PKIX1] specifies the validation of certification paths.
> One aspect involves the determination that a certificate has not
been
> revoked, and one revocation checking mechanism is the Certificate
> Revocation List (CRL). Checking a CRL when the CRL is signed by
the
> key of the Issuing CA is straightforward, but not necessarily
> otherwise.
>
> There are several legitimate scenarios where the certificate of
the
> CRL issuer is not present, or easily discovered.
>
> Standardized methods of finding the certificate of the CRL issuer
are
> currently available either though an accessible directory location
or
> through use of the Subject Information Access extension in
> intermediary CA certificates.
>
> Directory lookup requires presence and access to a directory. The
> Subject Information Access extension supports building
certification
> paths top-down (in the direction from the trust anchor to the CRL
> issuer), which will succeed if certificates include an appropriate
> Subject Information Access extension. Additional methods allowing
> the building of certification paths bottom-up to validate CRLs
> may be useful as well. This is the topic of this document.
>
> RFC 3280 [PKIX1] has provided for bottom-up discovery of
> certification paths through the Authority Information Access
> extension, where the id-ad-caIssuers access method may specify one
or
> more accessLocation fields that contain references to CA
certificates
> superior to the certificate containing this extension.
>
> This document permits use of the Authority Information Access
> extension in CRLs, enabling a CRL checking application to use the
> same access method (id-ad-caIssuers) to locate the certificate of
> the CRL issuer and complete the certification path building to an
> appropriate trust anchor.
>
> This extension may be used in the case when indirect CRLs are
used,
> when the certification Authority (CA) that issued the CRL
certificate
> changes its certificate signing key, or when the CA employs
separate
> keys for certificate signing and CRL signing.
>
> A typo would need to be corrected in section 2: change
> AuthotiyInfoAccessSyntax into AuthorityInfoAccessSyntax.
>
> Section 3 about Security Considerations would need to be changed.
> Hereafter is a proposal:
>
> 3 Security Considerations
>
> Implementers should take into account the possible existence of
> multiple unrelated CAs and CRL issuers with the same DN, as well
> as the possibility for some trusted CAs (i.e. trusted to issue
> their own certificates and associated revocation status
information
> but not trusted not handle revocation information from other
CAs)
> to purposely use URLs or CRL DPs identical to some CRL DPs from
> other CAs and at the same time mounting a re-routing attack.
>
> This means that finding a CA certificate at the location
indicated
> by this new extension is insufficient to make sure that it is
the
> right one, and by consequence that the CRL where this extension
> has been found is also the right one.
>
> When the CRL contains the indirectCRL boolean set to TRUE, then
the
> relying party should locally know the URL of the CRL issuer(s)
that
> it directly trusts and also the associated name of the trusted
CRL
> issuer, which means not simply knowing the DN of the CRL issuer,
> but also all the other DNs of the upper CAs up to a root key
(since
> two CAs might be given the same DN by two different CAs).
>
> When the CRL is a direct CRL, then relying parties shall make
sure
> that the certificate of the CRL issuer has been issued by the
same
> CA that has issued the target certificate.
>
> Implementers should always take the steps of validating the
> retrieved data to ensure that the data is properly formed.
>
> Of course, much more could be said and an informative annex would be
quite
> useful.
>
> In case of b), more work would need to be done.
>
> Denis
>