[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
David,
Since Tim has now made the call at the WG level, please consider this
message as an answer to the call.
> Denis:
> I have to disagree on removal of the text. I have not seen any
> objections from the list or working group to this inclusion. I have to
> disagree with your assertion that removing the text is a more secure
> recommendation. The below text (slightly edited to my taste) is an
> excellent recommendation from an implementation standoint and a security
> consideration.
You are using the wording "excellent" but as it will be demonstrated this is
far from excellent.
> I would personally concede that using MUST *may* be
> incorrect here and a SHOULD *may* be more appropriate.
Fine.
> As a means of mitigating implementation challenges and security
> issues related to issuer name collisions, CA names SHOULD be
> formed in such a way that reduce the likelihood of name collisions.
The word "mitigating" is used: it already indicates that it is not a secure
solution. While this recommendation is wise, nothing forces CA to follow
it. So the question is : what would happen if a CA name is formed in such
a way that there is a name collision ? Relying parties cannot base their
security on this "SHOULD requirement".
So this does not suppress the issue: this should clearly be said that this
is not a solution.
> Implementations validating CRLs SHOULD ensure that the certification
> path of the target certificate and the CRL issuer certification path
> used to validate the target certificate, terminate at a common trust
> anchor.
This does not solve the issue either. Under the same trust anchor there may
be a tree with many branches and leaves, nothing prevents two CRL Issuers to
have the same name.
For this reason the proposed text is inappropriate.
Denis
> David B. Cross
>
>
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Denis Pinkas
> Sent: Tuesday, May 10, 2005 12:01 AM
> To: Russ Housley
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>
>
> Russ,
>
>
>>Denis:
>>
>>Yes, it is OBVIOUS that the CRL issuer certificate needs to be
>
> validated.
>
>>You say that it is not clear what validation policy needs to be used,
>>but this is completely irrelevant to the discussion of the CRL AIA
>>extension. This extension aid in certification path construction, not
>
>
>>the validation of the path once it is constructed.
>
>
> Not exactly, it could "help" finding a wrong path !
>
>
>>There are many factors which need to be considered in the validation
>>of the CRL issue certificate. The values of the key usage extension
>>and the certificate policies extension are two that jump to mind.
>>There are probably more if I spend the time to consider each possible
>
> scenario.
>
> One simple rule would allow no security problem at all and I wonder why
> you have so much resistance to mention it.
>
>
>>In my opinion, this document is ready for WG Last Call.
>
>
> As an editor of the draft, I may understand your position; but it is up
> the the PKIX chairs to decide whether or not the document is ready for
> WG last call.
>
> Once again the current Security Considerations section is not
> acceptable.
> In particular it contains a "MUST" statement that cannot be placed in
> such a section and which is in addition fully wrong.
>
> Hereabove is the last one from draft 01:
>
> 3 Security Considerations
>
> Implementers should take into account the possible existence of
> multiple unrelated CAs and CRL issuers with the same name. As
> means of reducing problems and security issues related to issuer
> name collisions, CA names SHOULD be formed in a way that reduce
> the
> likelihood of name collisions. Implementations validating CRLs
> MUST ensure that the certification path of the target certificate
> and the CRL issuer certification path used to validate the target
> certificate, terminate at the same trust anchor.
>
> Implementers should be aware of risks involved if the Authority
> Information Access extensions of corrupted CRLs contain links to
> malicious code. Implementers should always take the steps of
> validating the retrieved data to ensure that the data is properly
> formed.
>
> Hereafter is a "minimalist" rewriting of this section, if we take the
> choice to mention the issue, but not to provide any secure solution
> (mentioning insecure or insufficient solutions is not appropriate). Two
> sentences have thus been deleted.
>
> 3 Security Considerations
>
> Implementers should take into account the possible existence of
> multiple unrelated CAs and CRL issuers with the same name.
>
> Implementers should be aware of risks involved if the Authority
> Information Access extensions of corrupted CRLs contain links to
> malicious code. Implementers should always take the steps of
> validating the retrieved data to ensure that the data is properly
> formed.
>
> Denis
>
>
>
>>Russ
>>
>>
>>At 09:07 AM 5/9/2005, Denis Pinkas wrote:
>>
>>
>>>Russ,
>>>
>>>
>>>>Here is a quote from RFC 3280. To me, it is clear that a CRL
>>>>issuer
>>>
>>>has
>>>
>>>>a certificate.
>>>
>>>True, a CRL issuer (that is different from the CA that has issued the
>>
>
>>>target
>>>certificate) has a certificate. So we both strongly agree on this
>>>this. :-)
>>>
>>>
>>>>Obviously, all certificates need to be validated, which includes
>>>>certification path construction and certification path
>>>
>>>validation.
>>>
>>>When a sentence starts with "Obviously", it means that it is not so
>>>obvious.
>>>:-|
>>>
>>>The real question is whether the CRL issuer certificate has to be
>>>verified using rules (i.e. a validation policy) which are independent
>>
>
>>>from the certification path construction of the target certificate.
>>>RFC 3280 does not provide a crystal clear answer to that question.
>>>
>>>If the rules are different, then you MAY end up with a security issue
>>
>
>>>(see my previous explanations). The current "recommendations" that
>>>are in the security considerations section do NOT solve this issue in
>>
>
>>>the general case.
>>>
>>>If the rules are the same, i.e. the path used to validate the
>>>certification path from the certificate are also used, then there is
>>>no security issue.
>>>
>>>I do not think it would be good to hide this issue in the proposed
>>
> draft.
>
>>>Anyway, the current "recommendations" do NOT solve the issue and are
>>>thus not acceptable and so this section cannot stand as it is.
>>>
>>>Denis
>>>
>>>
>>>>5.1.1.3 signatureValue
>>>>
>>>> The signatureValue field contains a digital signature computed
>>>
> upon
>
>>>> the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded
>>>
>>>tbsCertList
>>>
>>>> is used as the input to the signature function. This signature
>>>
>>>value
>>>
>>>> is encoded as a BIT STRING and included in the CRL
>>>
> signatureValue
>
>>>> field. The details of this process are specified for each of
>>>
> the
>
>>>> supported algorithms in [PKIXALGS].
>>>>
>>>> CAs that are also CRL issuers MAY use one private key to
>>>
> digitally
>
>>>> sign certificates and CRLs, or MAY use separate private keys to
>>>> digitally sign certificates and CRLs. When separate private
>>>>keys
>>>
>>>are
>>>
>>>> employed, each of the public keys associated with these private
>>>
> keys
>
>>>> is placed in a separate certificate, one with the keyCertSign
>>>>bit
>>>
>>>set
>>>
>>>> in the key usage extension, and one with the cRLSign bit set in
>>>
> the
>
>>>> key usage extension (section 4.2.1.3). When separate private
>>>
> keys
>
>>>> are employed, certificates issued by the CA contain one
>>>>authority
>>>
>>>key
>>>
>>>> identifier, and the corresponding CRLs contain a different
>>>
> authority
>
>>>> key identifier. The use of separate CA certificates for
>>>
> validation
>
>>>> of certificate signatures and CRL signatures can offer improved
>>>> security characteristics; however, it imposes a burden on
>>>> applications, and it might limit interoperability. Many
>>>
>>>applications
>>>
>>>> construct a certification path, and then validate the
>>>
> certification
>
>>>> path (section 6). CRL checking in turn requires a separate
>>>> certification path to be constructed and validated for the CA's
>>>
> CRL
>
>>>> signature validation certificate. Applications that perform CRL
>>>> checking MUST support certification path validation when
>>>
>>>certificates
>>>
>>>> and CRLs are digitally signed with the same CA private key.
>>>
> These
>
>>>> applications SHOULD support certification path validation when
>>>> certificates and CRLs are digitally signed with different CA
>>>
> private
>
>>>> keys.
>>>>
>>>>Russ
>>>>
>>>>At 01:12 PM 4/28/2005, Denis Pinkas wrote:
>>>>
>>>>
>>>>>Stefan and Russ,
>>>>>
>>>>>
>>>>>>Denis,
>>>>>
>>>>>
>>>>>>Russ and I have taken a thorough look at your text proposal and
>>>>>>we
>>>>>
>>>have
>>>
>>>>>>edited a counter proposal where we try to meet your needs as much
>>>>>
>
>>>>>>as possible without compromising what we think is the core
>>>>>>purpose of
>>>>>
>>>the
>>>
>>>>>>draft (to enable certificate discovery bottom-up).
>>>>>
>>>>>
>>>>>>The conclusion is that we suggest changes to the introduction
>>>>>>section but we keep the old security considerations intact.
>>>>>
>>>>>
>>>>>I would suggest that a merge would need to be done between the
>>>>
> "old"
>
>>>>>security considerations section and the "new" one.
>>>>>
>>>>>The "old" security considerations section is mentionning a
>>>>>solution which does NOT suppress the problem, but minimize the
>>>>>risk only in case the CAs are really "honest".
>>>>>
>>>>>The old" security considerations section does not provide a
>>>>>solution in case the name collsion between two CRL issuer name is
>>>>>deliberate, whereas the "new" security considerations section
>>>>>provides a secure solution in one case and clearly mentions that
>>>>>all other cases are dependant about "zillions" of *local* trust
>>>>>conditions which cannot all be standardized.
>>>>>
>>>>>The main purpose of a security considerations section is to
>>>>>provide the adequate warnings and solutions when they exist and
>>>>>not to hide the problems.
>>>>>
>>>>>
>>>>>>That is not because
>>>>>>we necessarily disagree with all of the statements in your
>>>>>
>>>proposal, but
>>>
>>>>>>in the cases we don't, we still think it is out of scope for this
>>>>>
>>>work.
>>>
>>>>>
>>>>>This is clearly within the scope of a security considerations
>>>>
> section.
>
>>>>>>The new introduction proposal based on your input is:
>>>>>>--------------------------------------------------------------
>>>>>>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). CRL validation is also specified in RFC
>>>>>>3280,
>>>>>
>>>>>
>>>>>I would love this last sentence to be true but the reality is
>>>>
> that:
>
>>>>>"CRL validation is NOT specified in RFC 3280". :-(
>>>>>
>>>>>
>>>>>>which involves the constructions of a valid certification path
>>>>>>for
>>>>>
>>>the
>>>
>>>>>>CRL issuer.
>>>>>
>>>>>
>>>>>There is no such a statement in RFC 3280.
>>>>>
>>>>>
>>>>>>Building a CRL issuer certification path from the signer of
>>>>>
>>>>>
>>>>>There is no notion of "CRL issuer certification path" in RFC 3280.
>>>>>The primary requirement is to make sure that the CRL issuer
>>>>>designated by the CA is indeed the right one. In some (but not
>>>>>all) cases, I mean among the zillion of cases, there MAY be a need
>>>>
>
>>>>>to construct a CRL issuer certification path.
>>>>>
>>>>>
>>>>>>the CRL to a trust anchor is straightforward when the certificate
>>>>>
>>>of the
>>>
>>>>>>CRL issuer is present in the certification path associated with
>>>>>>the target certificate, but it can be complex in other
>>>>>
> situations.
>
>>>>>
>>>>>From the comments above, you can see that I cannot agree with the
>>>>>above revised text. The remaining of the text is acceptable in
>>>>>general, but could possibly be slightly revised to be more in
>>>>>continuation with the changes there are needed above (i.e. it is
>>>>>not cast in concrete).
>>>>>
>>>>>Denis
>>>>>
>>>>>
>>>>>>There are several legitimate scenarios where the certificate of
>>>>>
>>>the CRL
>>>
>>>>>>issuer is not present, or easily discovered, from the target
>>>>>>certification path. This can be the case when indirect CRLs are
>>>>>
>>>used,
>>>
>>>>>>when the certification Authority (CA) that issued the target
>>>>>
>>>certificate
>>>
>>>>>>changes its certificate signing key, or when the CA employs
>>>>>>separate keys for certificate signing and CRL signing.
>>>>>>Methods of finding the certificate of the CRL issuer are
>>>>>>currently available, such as though an accessible directory
>>>>>>location or through use of the Subject Information Access
>>>>>>extension in intermediary CA certificates.
>>>>>>Directory lookup requires existence and access to a directory
>>>>>>that
>>>>>
>>>has
>>>
>>>>>>been populated with all of the necessary certificates. The
>>>>>>Subject Information Access extension, which supports building the
>>>>>
>
>>>>>>CRL issuer certification path top-down (in the direction from the
>>>>>
>
>>>>>>trust
>>>>>
>>>anchor to
>>>
>>>>>>the CRL issuer), requires that some certificates in the CRL
>>>>>>issuer certification path includes an appropriate Subject
>>>>>>Information Access extension.
>>>>>>RFC 3280 [PKIX1] provides 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 reference CA certificates associated
>>>>>>with the certificate containing this extension.
>>>>>>This document enables the use of the Authority Information Access
>>>>>
>
>>>>>>extension in CRLs, enabling a CRL checking application to use the
>>>>>
>>>access
>>>
>>>>>>method (id-ad-caIssuers) to locate certificates that may be
>>>>>>useful in the construction of a valid CRL issuer certification
>>>>>>path to an appropriate trust anchor.
>>>>>>
>>>>>>Stefan Santesson
>>>>>>Program Manager, Standards Liaison Windows Security
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Original Message-----
>>>>>>>From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
>>>>>>>Sent: den 18 april 2005 13:41
>>>>>>>To: Stefan Santesson
>>>>>>>Cc: Russ Housley; pkix
>>>>>>>Subject: Re: Comments on <draft-ietf-pkix-crlaia-00.txt>
>>>>>>>
>>>>>>>Stefan,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>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?
>>>>>>>
>>>>>>>
>>>>>>>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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>><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.
>>>>>>>
>>>>>>>
>>>>>>>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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Stefan Santesson
>>>>>>>>Program Manager - Standards Liaison
>>>>>>>>Windows Security
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
>