Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 22 Oct 2007 13:57:33 +0200

Russ said:

>It seems to me that this is a trust anchor configuration concern.  

Not only.

> If two CAs adopt the same name and a user accepts both of these CAs as 
>trust anchors, then there could be a problem.  Just don't do it.

This is correct, but insufficient. This does not prevent two CAs somewhere 
under this trust anchor to use the same name in different branches.

>RFC 3280bis says:

>    While X.509 mandates that names be unambiguous, there is a risk that
>    two unrelated authorities will issue certificates and/or CRLs under
>    the same issuer name.  

This is correct. This sentence contradicts the response to DR 320.

>    As a means of reducing problems and security
>    issues related to issuer name collisions, CA and CRL issuer names
>    SHOULD be formed in a way that reduces the likelihood of name
>    collisions.  

This recommandation does not *prevent* "problems and security issues".
This sentence should be deleted or changed. 

>    Implementers should take into account the possible
>    existence of multiple unrelated CAs and CRL issuers with the same
>    name.  

This is fully correct.

>    At a minimum, implementations validating CRLs MUST ensure that
>    the certification path of a certificate and the CRL issuer
>    certification path used to validate the certificate terminate at the
>    same trust anchor.

This "minimum" clause is both insufficient and insecure. 
This sentence gives a false sense of security.

This means that RFC3280bis currently provides no coorect guidance 
on how implementers should address this issue. 

The following text is an attempt to address this issue:

"Implementations validating indirect CRLs MUST make sure that the 
certificate of the CRL Issuer is indeed issued by the CA that issued 
the certificate to be verified, which means that the sequence of DNs 
of the certification path of the CRL issuer, up to the DN of a trust anchor, 
must be identical to the the sequence of DNs of the certification path 
of the certificate to be verified, up to the DN of the same trust anchor".

Denis

>Russ
>
>At 08:12 AM 10/5/2007, ITU-T SG 17 wrote:
>
>>Title: Liaison to IETF on the resolution of DR320
>>Submission Date: 2007-10-05
>>URL of the IETF Web page: 
>>https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=375
>>Please reply by 2008-03-01
>>
>>From: Xiaoya Yang(ITU-T SG 17) <[email-masked]>
>>To: IETF/PKIX(Russ Housley <[email-masked]>, Stefan Santesson 
>><[email-masked]>)
>>Cc: Herbert Bertine <[email-masked]>
>><[email-masked]>
>><[email-masked]>
>><[email-masked]>
>>Reponse Contact: Xiaoya YANG <[email-masked]>
>><[email-masked]>
>>Technical Contact: <[email-masked]>
>><[email-masked]>
>>Purpose: For action
>>Body: At our recent ITU-T SG17 meeting in Geneva we discussed and 
>>rejected Defect Report 320 
>>(http://www.x500standard.com/uploads/Defects/DR_320.pdf) from 
>>AFNOR.  This DR advanced an argument that Distinguished Names may 
>>not be unique and as such, the DN of the Certificate User may not be unique.
>>The directory group believes that Distinguished Name values must be 
>>unique and unambiguously identify a single entity, hence the use of 
>>the term Distinguished.
>>The DR states “the DN of the issuer name cannot be guaranteed to 
>>be unique”.  X.509 takes its definition of DN from X.501.  Clause 
>>9.2 of X.501 specifies the definition of DistinguishedName.  This 
>>clause states A name shall be unambiguous, that is, denotes just one object.
>>Clause 9 goes on to state: It is the responsibility of the relevant 
>>naming authority for an entry to ensure that this is so by 
>>appropriately assigning distinguished attribute values.  Allocation 
>>of RDNs is considered an administrative undertaking that may or may 
>>not require some negotiation between involved organizations or 
>>administrations.  This Directory Specification does not provide such 
>>a negotiation mechanism, and makes no assumption as to how it is performed.
>>The standard takes an axiomatic view of the concept that a 
>>distinguished name unambiguously identifies a single entity.  Things 
>>break if two entities identify themselves using the same name.  We 
>>don't let two entities have the same domain name or the same email 
>>address.  Why? - because things wouldn't work.
>>The directory group does not accept the DR’s basic argument.  We 
>>believe that if two entities present the same name and a CA issues a 
>>certificate to each, that CA made a mistake - not a naming authority 
>>mistake, since a CA is not an naming authority (although one entity 
>>can be both), but an entity to key binding mistake that leads to 
>>confusion and even worse, a security risk.
>>We believe that if two entities claim the same name as top level 
>>CAs, there is a political/procedural breakdown much like the domain 
>>ownership arguments we have seen.  No one argues that the Internet 
>>protocols should be modified to solve that problem.  The conflict is 
>>resolved and one entity is assigned the name.  The group believes 
>>that this is the only reasonable solution for Distinguished 
>>Naming.  One votes for the CA of choice by configuring it as an anchor.
>>One of the participants in the directory meeting stated that 
>>Certification Authorities are being deployed with names not acquired 
>>from naming authorities but with names arbitrarily chosen assuming 
>>that no other CA is or will be operating under that name.  That 
>>participant further stated that the IETF provides no guidelines on 
>>ensuring that the names of CAs are unambiguous.
>>The directory group requests the IETF PKIX group to comment on this 
>>statement.  If the statement is correct, we ask the IETF to consider 
>>putting a mechanism in place to prevent conflict, e.g. a list of 
>>existing CA names that deployers of new CAs could check for naming conflicts.
>>Attachment(s):
>>No document has been attached
>

Regards,

Denis Pinkas

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 22 Oct 2007 14:53:53 +0200

On Mon, Oct 22, 2007 at 01:57:33PM +0200, Denis Pinkas wrote:
> [snip]

Hi Denis,

> on how implementers should address this issue. 

Agreed. There is a somewhat "matter of local policy-ish" issue here.

> of the certificate to be verified, up to the DN of the same trust anchor".

Forcing the CA to directly issue the CRL issuer certificate is way too
restrictive in my humble opinion. I have an example of a PKI where there
is a single (indirect) CRL issuer for about 20 CAs.

The CRL issuer certificate is issued by the (Root) CA that issued
those 20 CA certificates.

Regards,

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 22 Oct 2007 06:18:22 -0700

We have been down this route before.

See my presentation to PKIX in Fall 2004 IETF meeting in Washington DC.

My understanding from 2004 presentation was that Russ Housley proposed instead of ensuring certificate certification path and CRL certification path matching, we make sure that we ensure that the paths begin at the same trust anchor.  It was felt by the group (not I) that coupled with name constraints in cross certified environment is sufficient to mitigate the risk to an acceptably low level.  Of course, my argument always has been that using the certificate certification path to constrain the CRL certification path provides you both with security and efficiency, something you do not always get.  The primary reason to not adopt my suggestion is that it requires change to client software.

Also see our paper in NIST PKI Research Workshop in 2005 for a discussion of this.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, October 22, 2007 7:58 AM
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution of DR320"

Not only.

This is fully correct.

Denis

>>The DR states â€œthe DN of the issuer name cannot be guaranteed to 
>>be uniqueâ€.  X.509 takes its definition of DN from X.501.  Clause 
>>The directory group does not accept the DRâ€™s basic argument.  We 

Regards,

Denis Pinkas

---

From: "Julien Stern" <[email-masked]>
Date: Mon, 22 Oct 2007 16:33:30 +0200

> We have been down this route before.

Oooooh Yes. Lots of fun and (gentle) arguments...

> My understanding from 2004 presentation was that Russ Housley proposed instead of ensuring certificate certification path and CRL certification path matching, we make sure that we ensure that the p…

I did not feel either that trust anchor matching was sufficient enough.

As you may remember, I also felt that your proposed solution, while
improving the situation, did not close every possible attacks, and I
proposed an alternative that was (in my humble opinion) even more secure
but with even more changes on the client software.

Anyway, my current take on the subject would be roughly the following.
RFC3280bis could include something in the line of:

"The uniqueness of DN of all entities in all the Trust Anchors
hierarchies SHOULD be enforced. If the uniqueness cannot be guaranteed
in some circonstances, client software MAY implement additional checks
in order to lower the risk of outputing an incorrect revocation value during
path validation. [We could give example of additional checks here:
checking the trust anchor matching, check the full path matching,
checking the AuthorityKeyIdentifier hash matching, etc]. Client
implementors should however be aware that these additional checks may
hinder interoperability in the general case."

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 22 Oct 2007 10:41:10 -0700

Julien,

What I recall is that your attack was a CA trusted to issue CA
certificates by the relying party going rogue.  X.509 does not protect
against that.

You also mentioned that you had protection against it, you were
unwilling to share it, and you said that you will share it after you
publish your work.

I have yet to see your proposal.

As a matter of fact on PKIX or X.500 forum within last year again I
asked you to share your proposal and you never replied.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Monday, October 22, 2007 10:34 AM
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
of DR320"

> My understanding from 2004 presentation was that Russ Housley proposed
instead of ensuring certificate certification path and CRL certification
path matching, we make sure that we ensure that the paths begin at the
same trust anchor.  It was felt by the group (not I) that coupled with
name constraints in cross certified environment is sufficient to
mitigate the risk to an acceptably low level.  Of course, my argument
always has been that using the certificate certification path to
constrain the CRL certification path provides you both with security and
efficiency, something you do not always get.  The primary reason to not
adopt my suggestion is that it requires change to client software.

in order to lower the risk of outputing an incorrect revocation value
during

--
Julien

---

From: "Julien Stern" <[email-masked]>
Date: Thu, 25 Oct 2007 10:43:58 +0200

Santosh,

I think you are being a bit unfair, as I did explain on the list
as clearly as I could the attack and the protection (early Nov 2004).

Anyway, I do not feel like boring other readers to death by starting
the whole discussion once again.

Maybe we can sit down at a table and chat if we happen to meet at a
conference someday :)

Regards,

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 25 Oct 2007 05:50:10 -0700

Julien,

It is very simple.  Point to me to the specific post or e-mail me (not
the entire mail list) your protection approach.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Julien Stern
Sent: Thursday, October 25, 2007 4:44 AM
To: [email-masked]
Subject: Re: New Liaison Statement, "Liaison to IETF on the resolution
of DR320"

Santosh,

Regards,

--
Julien