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