Subject: RE: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320

From: Stefan Santesson <[email-masked]>
Date: Tue, 4 Dec 2007 02:58:28 +0000

The issue was discussed on the PKIX meeting and we concluded on a somewhat simpler response along the proposal below.

Claim from the Liaison statement:
 "That participant further stated that the IETF provides no guidelines on ensuring that
the names of CAs are unambiguous."

Liaison request:
"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."

Proposed Response:
Yes, the statement is true. IETF does not provide any guidelines to ensure that CA names are unambiguous.
No, it is not possible for the PKIX work group to maintain a list of CA names or similar mechanism that would prevent conflict of CA names. The PKIX WG does however welcome and encourage those who would like to propose useful mechanisms to present them to the PKIX work group.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: den 23 november 2007 08:52
To: [email-masked]
Subject: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320

Stephan,

Thank you for posting the agenda.

I noticed that 3.1 is about DR 320 :
      Liaison statements received from ITU-T SG17 - 10 min
      Stefan Santesson (WG co-chair)
      https://datatracker.ietf.org/liaison/375/
I have prepared below a draft response to the liaison statement:

Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320

See: https://datatracker.ietf.org/liaison/375/

Neither DNs of entities, nor DNs of CAs, can be unambiguous.

Within RFC 3280, every subject DN (whether it is an entity DN or a CA DN)
is only unique for the CA that has picked that name. A CA is thus free to choose any DN
for naming an entity without the need to find out if that name has already been used by
some other CA in the world.

There is currently no mechanism in place to prevent conflict, e.g. a list of existing CA names

that deployers of new CAs could check for naming conflicts. There is no need to consider

putting mechanisms in place to prevent conflict, e.g. a list of existing CA names that deployers

of new CAs could check for naming conflicts.
The single requirement is the following: within a validation policy or within a signature policy
there shall not be two different root CAs (trust anchors) with the same DN.

This means that within RFC 3280 an ambiguous name is composed of a sequence of DNs,
starting with the DN of a root CA and ending with the DN (or the Subject Alternate Name,
if the DN is empty) of the entity.

This also means that a DN alone associated with a certificate serial number is unable to uniquely identify
a public key certificate.

However, if the DN is the DN from a certificate issuer whose certificate has been verified under a given
validation policy or signature policy, then that DN can be characterized by a chain of upper CA names and
then becomes unique under that validation or signature policy.

The liaison statement states: "Things break if two entities identify themselves using the same name".
No evidence has been provided by ITU-T SG 17 to demonstrate that this statement is true.
If it were, amendments to X.509 would need to be provided to deal with name collisions
which are indeed possible, either intentionally or by accident.

Denis

________________________________
I have updated what I believe to be the final agenda for Vancouver.
We have now an almost full 2 hour program.
 http://www3.ietf.org/proceedings/07dec/agenda/pkix.txt
 Stefan Santesson
Senior Program Manager
Windows Security, Standards
________________________________

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 4 Dec 2007 03:45:38 +0000

You are right that this ending was not based on the consensus of the room, but I still think it is reasonable to welcome proposals to be posted to the WG.
I think that the consensus in the room was that the solution mentioned in the liaison request is totally unreasonable and that we can't see any other solution to the problem worth pursuing.

I practically stole the ending from Sam's proposal on response to the other liaison request.
It sort of takes the position that if they want something done, they have to propose a mechanism rather than asking us to find one.

But I can remove it also.

Stefan Santesson
Senior Program Manager

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: den 3 december 2007 19:38
> To: Stefan Santesson
> Cc: [email-masked]
> Subject: Re: Draft response to the liaison from ITU-T SG 17 to IETF on
> the resolution of DR320
>
>
>
> Stefan Santesson wrote:
> > The
> > PKIX WG does however welcome and encourage those who would like to
> > propose useful mechanisms to present them to the PKIX work group.
>
> I didn't get a sense in the room today that we would actually
> welcome a proposal for how to maintain a list of CA names. In fact,
> I got the opposite impression, i.e. that the people in the room
> would find such a proposal unwelcome. (All modulo WG participants
> who weren't in the room of course.)
>
> Other than that, I think your text is fine.
>
> S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 04 Dec 2007 03:38:22 +0000

S.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Dec 2007 11:24:01 -0500

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> You are right that this ending was not based on the
    Stefan> consensus of the room, but I still think it is reasonable
    Stefan> to welcome proposals to be posted to the WG.  I think that
    Stefan> the consensus in the room was that the solution mentioned
    Stefan> in the liaison request is totally unreasonable and that we
    Stefan> can't see any other solution to the problem worth
    Stefan> pursuing.

I thought there was also strong feeling that this was out of scope for
our charter (both PKIX and IETF) and thus that we should not take on the discussion.

I'd say we encourage anyone who wants to set up such a mechanism to do
so or attempt to do so.

---

From: Russ Housley <[email-masked]>
Date: Tue, 04 Dec 2007 12:42:57 -0500

Stefan:

I have a concern with the past paragraph.  I do not think that we
should encourage someone to propose mechanisms that PKIX could
adopt.  This seem like "bring me a rock", and it will
certainly lead to "that rock doesn't work, please bring me a
different rock".  This gets frustrating on both sides very
quickly.

I'd rather say that we do not see a pragmatic need for such a
mechanism.  PKI technology is being used effectively in the Internet
without CA name registration.

Russ

P.S.  Please consider using plain text for the response.

At 09:58 PM 12/3/2007, Stefan Santesson wrote:

The issue was discussed on the PKIX meeting and we concluded on a
somewhat simpler response along the proposal below.

“That participant further stated that the IETF provides no
guidelines on ensuring that

the names of CAs are unambiguous.”

Liaison request:

“The directory group requests the IETF PKIX group to comment on
this

statement.  If the statement is correct, we ask the IETF to
consider

conflicts.”

Proposed Response:

Yes, the statement is true. IETF does not provide any guidelines to
ensure that CA names are unambiguous.

No, it is not possible for the PKIX work group to maintain a list of CA
names or similar mechanism that would prevent conflict of CA names. The
PKIX WG does however welcome and encourage those who would like to
propose useful mechanisms to present them to the PKIX work group.

Stefan Santesson

Senior Program Manager

From: [email-masked]
[
mailto:[email-masked]] On Behalf Of Denis
Pinkas

To: [email-masked]

Subject: Draft response to the liaison from ITU-T SG 17 to IETF on
the resolution of DR320

Stephan,

Liaison statements received from ITU-T
SG17 - 10 min

Draft response to the liaison from ITU-T SG 17 to IETF on the
resolution of DR320

See:

is only unique for the CA that has picked that name. A CA is thus free to
choose any DN

for naming an entity without the need to find out if that name has
already been used by

There is currently no mechanism in place to prevent conflict, e.g. a
list of existing CA names

that deployers of new CAs could check for naming conflicts. There is no
need to consider

putting mechanisms in place to prevent conflict, e.g. a list of existing
CA names that deployers

of new CAs could check for naming
conflicts.
The single
requirement is the following: within a validation policy or within a
signature policy

there shall not be two different root CAs (trust anchors) with the same
DN.

This means that within RFC 3280 an ambiguous name is composed of a
sequence of DNs,

starting with the DN of a root CA and ending with the DN (or the Subject
Alternate Name,

This also means that a DN alone associated with a certificate serial
number is unable to uniquely identify

However, if the DN is the DN from a certificate issuer whose certificate
has been verified under a given

validation policy or signature policy, then that DN can be characterized
by a chain of upper CA names and

The liaison statement states: "Things break if two entities identify
themselves using the same name".

No evidence has been provided by ITU-T SG 17 to demonstrate that this
statement is true.

If it were, amendments to X.509 would need to be provided to deal with
name collisions

Denis

Stefan Santesson

Senior Program Manager

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 4 Dec 2007 17:56:08 +0000

Russ,

I realize that you may read the last sentence the wrong way.
So the latest proposal is:

"Yes, the statement is true. IETF does not provide any guidelines to ensure that CA names are unambiguous.
No, it is not possible for the PKIX work group to maintain a list of CA names or similar mechanism that would prevent conflict of CA names. The solution mentioned in the liaison request is unreasonable and the PKIX WG does not see any such a solution worth pursuing."

Stefan Santesson
Senior Program Manager

From: Russ Housley [mailto:[email-masked]]
Sent: den 4 december 2007 09:43
To: Stefan Santesson
Cc: Denis Pinkas; [email-masked]
Subject: RE: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320

Stefan:

I have a concern with the past paragraph.  I do not think that we should encourage someone to propose mechanisms that PKIX could adopt.  This seem like "bring me a rock", and it will certainly lead to "that rock doesn't work, please bring me a different rock".  This gets frustrating on both sides very quickly.

I'd rather say that we do not see a pragmatic need for such a mechanism.  PKI technology is being used effectively in the Internet without CA name registration.

Russ

Liaison request:

Proposed Response:

Stefan Santesson
Senior Program Manager

From: [email-masked] [ mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: den 23 november 2007 08:52
To: [email-masked]
Subject: Draft response to the liaison from ITU-T SG 17 to IETF on the resolution of DR320

Stephan,

need to consider

CA names that deployers

conflicts.

Denis

---

From: Russ Housley <[email-masked]>
Date: Tue, 04 Dec 2007 13:07:42 -0500

Much better.

At 12:56 PM 12/4/2007, Stefan Santesson wrote:

Russ,

“Yes, the statement is true. IETF does not provide any guidelines to
ensure that CA names are unambiguous.

No, it is not possible for the PKIX work group to maintain a list of CA
names or similar mechanism that would prevent conflict of CA names. The
solution mentioned in the liaison request is unreasonable and the PKIX WG
does not see any such a solution worth pursuing.”

Stefan Santesson

Senior Program Manager

From: Russ Housley
[
mailto:[email-masked]]

To: Stefan Santesson

Subject: RE: Draft response to the liaison from ITU-T SG 17 to
IETF on the resolution of DR320

Stefan:

Russ

Liaison request:

conflicts.”

Proposed Response:

Stefan Santesson

Senior Program Manager

To: [email-masked]

Stephan,

See:

There is currently no mechanism in place to prevent conflict, e.g.
a

that deployers of new CAs could check for naming conflicts. There is
no

need to consider

putting mechanisms in place to prevent conflict, e.g. a list of
existing

CA names that deployers

of new CAs could check for
naming

conflicts.
The single

Denis

Stefan Santesson

Senior Program Manager