Subject: RE: Comments on <draft-ietf-pkix-crlaia-00.txt>

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 15 Apr 2005 11:53:55 +0100

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:[email-masked]]
> 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: [email-masked]
> >
> > [mailto:[email-masked]]
> >
> >>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
> >>
> >
> >
> >
>

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 18 Apr 2005 13:41:22 +0200

Stefan,

> I will come back and comment on your text proposals, but before that, 
 > a few questions/comments:

>>> certificate and CRL is not signed by the same key.

>> 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).

> cryptographic binding. But how do you mean it can be done?

Would this mean that you believed this could not be done ? :-)

I already provided the information, but since at that time you were 
focussing on another issue, you probably missed the point.

I would encourage you to read again that thread, but I will provide a short 
reply here to your question.

This can be done using cRLIssuer from the CRL DP. cRLIssuer contains the DN 
of the CRL Issuer and we all know that CAs are free to assign the DNs they 
wish. The next point is for a verifier to make sure that the DN which 
identifies the CRL Issuer (in the CRL DP) is indeed the one that was meant 
by the CA. The CRL must be issued by a CRL Issuer that has the same DN. The 
CRL Issuer will have a certificate issued by a CA.

Case a): the CA that has issued that certificate is the same as the CA that 
has issued the target certificate (which contains the hereabove mentionned 
CRL DP). This is easy to check for a verifier since the verifier must first 
build the certification path and then test the revocation status of every 
element of the path. So the verifier knows the validated sequence of DNs 
starting from a self-signed certificate. It must then use the same sequence 
of DNs to validate the CRL Issuer certificate.

This is a general rule which does not require any extra local trust information.

Case b) : the CA that has issued that certificate is NOT the same as the CA 
that has issued the target certificate. This case requires extra *0local* 
trust information. There are many such trust conditions possible and thus 
this cannot be defined in general. Cases a) and b) are thus not equivalent 
and have to be distinguished.

> and focus on the issues that are related to this limited scope.

This is what I did in my proposal, except that we need to have a security 
considerations section and the goal of that section is not to hide problems 
but to correctly warn users. Thus why an informatiove annex on the topics 
mentionned in the security considerations section would be quite useful.

In fact, its content would be along the lines of the explanations which are 
just above.

I hope this e-mail will help us to progress.

Denis