[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on <draft-ietf-pkix-crlaia-00.txt>
Denis,
I will come back and comment on your text proposals, but before that, a
few questions/comments:
<snip>
> > 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.
>
> Not really. It is indeed possible to have an absolute cryptographic
> binding
> between CRL and certificates where the certificate and CRL is not
signed
> by
> the same key, but the key point is that proposed extension is *not*
the
> means to provide such a binding (and you agree with this further down
in
> this e-mail).
We agree that this extension does not add to the concept of
cryptographic binding. But how do you mean it can be done?
<snip>
> > This draft only introduces a new way to locate certificates
> > that can be helpful in building this path.
>
> At least one sentence of which we both agree !
> It should be copied and pasted in the abstract.
Good, then I suggest that we leave unrelated topics out of this draft
and focus on the issues that are related to this limited scope.
Stefan Santesson
Program Manager - Standards Liaison
Windows Security
> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> Sent: den 14 april 2005 10:10
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>
> Stefan,
>
> > Denis,
>
> > Thanks for spending considerable time to comment on this draft.
>
> > The typo is noted and will be fixed.
>
> Thank you so much, for accepting to correct the typo. :-|
>
> > 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.
>
> Not really. It is indeed possible to have an absolute cryptographic
> binding
> between CRL and certificates where the certificate and CRL is not
signed
> by
> the same key, but the key point is that proposed extension is *not*
the
> means to provide such a binding (and you agree with this further down
in
> this e-mail).
>
> The proposed extension is simply a means to find a possible
certificate
> candidates, but not a means to make sure that the candidate is
acceptable.
>
> > A certificate is always authoritative to identify the correct CRL
for
> > its validation.
>
> While this is true in general, this is not always true. When indirect
CRLs
> are used, a directly trusted CRL Issuer may be used. For other cases,
your
> statement is correct.
>
> > 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.
>
> As you say, only issuer name or location may be used. Location cannot
be
> used as this has been demonstrated in the previous e-mail, since a
network
> attack could be performed. So only the issuer name can be used. Let us
> look,
> how:
>
> The CRL DP extension is defined as:
>
> DistributionPoint ::= SEQUENCE {
> distributionPoint [0] DistributionPointName
OPTIONAL,
> reasons [1] ReasonFlags OPTIONAL,
> cRLIssuer [2] GeneralNames OPTIONAL }
>
> Secure binding may be obtained using cRLIssuer where
>
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>
> with
>
> GeneralName ::= CHOICE {
> otherName [0] AnotherName,
> rfc822Name [1] IA5String,
> dNSName [2] IA5String,
> x400Address [3] ORAddress,
> directoryName [4] Name,
> ediPartyName [5] EDIPartyName,
> uniformResourceIdentifier [6] IA5String,
> iPAddress [7] OCTET STRING,
> registeredID [8] OBJECT IDENTIFIER }
>
> where Name ::= CHOICE {
> RDNSequence }
>
> RFC 3280 states:
>
> " If the certificate issuer is not the CRL Issuer, then the
cRLIssuer
> field MUST be present and contain the Name of the CRL issuer".
>
> A name is uniquely assigned to an entity, only if the name of the CA
which
> has allocated it is known. Recursively, the DN of that CA is uniquely
> assigned to an entity, only if the DN of the CA which has allocated
that
> DN
> it is known. This process ends up until the trust anchor that has
issued
> the
> first CA certificate of the certification path is known.
>
> > 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.
>
> Not exactly. From what is said above, it can be said that cRLIssuer DN
has
> been uniquely assigned to that entity, if it is known that this DN has
> been
> issued by the CA that has issued the target certificate. This is
scenario
> A
> which means that the trust conditions from the relying party are
simple
> and
> well known.
>
> The problem is that with scenario B, no document provides the trust
> conditions to be used by the relying party and that there can be many
> different trust conditions, some of them may be secure, while some of
them
> may be insecure depending upon the context.
>
> This is why it is important to make a difference between scenario A
and B.
>
> > Section 6.3 of RFC 3280 is dealing with CRL validation and the
> > requirement to validate the CRL through a valid certificate path.
>
> ... but that section is lacking of further details that would allow
two
> different imlplementations to end up with the same result.
>
> > This draft only introduces a new way to point to locate certificates
> > that can be helpful in building this path.
>
> At least one sentence of which we both agree !
> It should be copied and pasted in the abstract.
>
> > It seems to me from that
> > perspective that specific requirements on CRL path building are
outside
> > the scope of this draft.
>
> Since scenario B has so many possible options, it is not possible to
cover
> all of them and the intent is not to describe and prescribe all of
them.
> However, scenarion A is much simpler and may be described.
>
> I have many problems with the current introduction. I am restating my
> previous proposal for a revised introduction along the lines that
"this
> draft only introduces a new way to point to locate certificates that
can
> be
> helpful in building this path". If you have problems with that text,
> please
> propose revisions to it. If you can live with it, then we are solved
with
> the introduction.
>
>
> 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.
>
>
> Now the security considerations section still contains incorrect text.
> I have revised my previous proposal. If you have problems with that
text,
> please propose revisions to it. If you can live with it, then we are
> solved with section 3.
>
> 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 is a direct CRL, 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.
>
> When the CRL contains the indirectCRL boolean set to TRUE,
> relying parties should locally know the URL of the CRL issuer(s)
> that they directly trust and use local trust conditions to make
> sure that the CRL that has been retrieved has indeed be issued
> by a directly trusted CRL Issuer. In particular, care should be
> taken
> in case two CAs would be using the same DN for two different
CAs.
>
> Implementers should always take the steps of validating the
> retrieved data to ensure that the data is properly formed.
>
>
> Indeed, more could be said about indirect CRLs, so if you want to add
some
> more text, please do it.
>
> Denis
>
> >>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
> >>
> >
> >
> >
>