Subject: Re: RE: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 8 Aug 2005 17:49:23 +0100

Santosh,

>Denis,

>I agree that the rule of an ancestor may not be sufficient (specially
>theoretically).  An alternative is to permit only the following:

>1.  Indirect CRL is signed using the same trust anchor DN as the certificate
>certification path; or

Your sentence above is not crystal clear to me. 
If you only mean "same TA", then this is insufficient.

>2.  Indirect CRL is signed using an authority that is issued a certificate
>by the same trust anchor DN as the certificate certification path; or

The same applies.

>3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this case,
>depending on the reason for indirect CRL, the revocation status of the
>delegation certificate may need to contain no check or verified using
>partitioned CRL.

I can't understand.

>The implementations I know that use Indirect CRL are consistent with the
>above.  But, it a further constraint/profiling/change to the Standard.

???

>BTW, what are the examples of "locally known constraints" and/or how would
>you articulate these in an RFC?

Quite hard to articulate these in an RFC. The only *example* I have in mind is 
a validation policy that is using a *single* TA, where that TA imposes to 
the CAs it certifies some naming constraints, and where these CA also impose 
naming constraints on subsequent CAs. The naming constraints may be such 
that there cannot be name collisions *if these naming constraints are really 
followed*.

Denis

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Denis Pinkas
>Sent: Friday, August 05, 2005 7:50 AM
>To: 'pkix'; Santosh Chokhani
>Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and delegated
>CRLs
>
>
>
>>Tom,
>
>>That would be fine for indirect CRL.
>
>This is insufficient, unless additional naming constrains are localy known.
>
>> I assume you are not recommending this
>>for a direct CRL (i.e., when Cert Issuer = CRL issuer)
>
>>-----Original Message-----
>>From: Tom Gindin [mailto:[email-masked]]
>>Sent: Thursday, August 04, 2005 9:38 AM
>>To: Santosh Chokhani
>>Cc: 'pkix'
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>        Santosh:
>>
>>        Actually, I have been arguing for requiring the CRL issuer's
>>certification path to be a subset of the subject certificate's path.  I 
>
>Unless additional naming constrains are localy known, this may be insecure.
>
>Denis
>
>>don't see any major issue if the hierarchical superior of a CA issues a
>>CRL signing certificate which can issue CRL's for the subordinate CA's. 
>>However, I don't see how to go beyond that.
>>
>>Tom Gindin
>
>>"Santosh Chokhani" <[email-masked]>
>>Sent by: [email-masked]
>>08/03/2005 10:17 AM
>> 
>>        To:     "'pkix'" <[email-masked]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>>delegated CRLs
>>
>>
>>
>>Tom Gindin,
>>
>>You seem to be arguing for matching CRL certification path with that of
>>the
>>certificate.
>>
>>If so, you will not get an argument from me.
>>
>>-----Original Message-----
>>From: [email-masked] 
>>[mailto:[email-masked]]
>>On
>>Behalf Of Tom Gindin
>>Sent: Tuesday, August 02, 2005 11:17 PM
>>To: Manger, James H; [email-masked]
>>Cc: pkix
>>Subject: RE: 3280bis: suggested words for ambiguous DNs and delegated CRLs
>>
>>
>>
>>        James, Santosh:
>>
>>        You certainly can construct unambiguous names for CA's, and I
>>think that Denis already knows that (Permanent Identifier is certainly a 
>>way of constructing unambiguous names, for example).  The difficulty we 
>>have is when one issuer issues a certificate to an organizational CA with 
>>a subject name which is convenient and in common use for its organization, 
>>
>>but ambiguous, and then a different issuer issues a certificate to an
>>organizational CA with the same subject name which is also in common use 
>>for its organization.  This case is most common when both organizations 
>>use an acronym.  I do not see why the issuers of the two organizational CA 
>>
>>certificates should be assumed to originate at different trust anchors,
>>although they will be different issuers.  In fact, I don't understand why 
>>organizational name collisions are thought to be much rarer with a "common 
>>
>>trust anchor" than with "different trust anchors" if the actual issuers 
>>of
>>
>>the colliding certificates are both public CA's.
>>        Such collisions will have negative effects in other parts of 
>>the
>>global PKI, of course.  However, unless we are prepared to issue guidance 
>>to deprecate the assignment of DN's for organizations with geographical 
>>scopes wider than the one for which they are registered and guaranteed to 
>>be unique (and many existing CA certificates have such DN's), I don't see 
>>how we can be certain or nearly certain that such collisions won't occur. 
>>A typical example of what I mean by an organization having a DN with a 
>>geographical scope wider than the one for which it's registered is a 
>>corporation registered in a single American state and operating in several 
>>
>>states while having a DN without the stateOrProvinceName attribute.
>>
>>                Tom Gindin
>>
>>
>>
>>
>>
>>
>>"Manger, James H" <[email-masked]>
>>Sent by: [email-masked]
>>08/01/2005 11:05 PM
>> 
>>        To:     "pkix" <[email-masked]>
>>        cc: 
>>        Subject:        RE: 3280bis: suggested words for ambiguous DNs and 
>>
>>delegated CRLs
>>
>>
>>[Santosh: Requiring a unique DNS may be fine.  But, CA does not know 
>>the
>>trust anchors environment of the relying parties to know if the CRL issuer 
>>
>>DN will be unambiguous.]
>>You can construct unambiguous DNs regardless of trust anchors.  For
>>instance, including DC components can make a DN as unambiguous as a DNS 
>>name.  As another example, the following DN
>>  o=?Qantas Airways Limited, ABN 16 009 661 901?, c=?AU?
>>is unambiguous as it lists a registered business name, its Australian 
>>Business Number (ABN) and the jurisdiction where those are unambiguous 
>>(Australia).  It is inconceivable that any CA could issue such a DN to 
>>another entity in good faith.
>>The DN cn=?John Smith?, c=?US? may be unambiguous in the context of an 
>>issuing CA, but would be ambiguous in a wider context so it should not be 
>>used in cRLIssuer ? use rfc822Name=?[email-masked]? instead, for 
>>instance.
>>
>>
>>
>>
>>
>
>Regards,
>
>Denis Pinkas
>
>
>

Regards,

Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 8 Aug 2005 14:26:59 -0400

Denis,

See the responses in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Monday, August 08, 2005 12:49 PM
To: 'pkix'; Santosh Chokhani
Subject: Re: RE: RE: 3280bis: suggested words for ambiguous DNs and
delegated CRLs

Santosh,

>1.  Indirect CRL is signed using the same trust anchor DN as the 
>certificate certification path; or

[Santosh: Let us say that the certification path for the certificate begins
with a trust anchor whose subject DN is X, then an indirect CRL can be
signed by a trust anchor whose subject DN is X.  Please note that the keys
need not be the same due to the trust anchor re-key.]

>2.  Indirect CRL is signed using an authority that is issued a 
>certificate by the same trust anchor DN as the certificate 
>certification path; or

The same applies.

[Santosh: Let us say that the certification path for the certificate begins
with a trust anchor whose subject DN is X, then an indirect CRL can be
signed by an authority which is issued a certificate by a trust anchor where
trust anchor subject DN = X.]

>3.  Certificate issuer CA delegates the Indirect CRL issuer.  In this 
>case, depending on the reason for indirect CRL, the revocation status 
>of the delegation certificate may need to contain no check or verified 
>using partitioned CRL.

I can't understand.

[Santosh: What part you do not understand?  Delegation or revocation status
checking of the indirect CRL issuer certificate?]

>The implementations I know that use Indirect CRL are consistent with 
>the above.  But, it a further constraint/profiling/change to the 
>Standard.

???

>BTW, what are the examples of "locally known constraints" and/or how 
>would you articulate these in an RFC?

Quite hard to articulate these in an RFC. The only *example* I have in mind
is 
a validation policy that is using a *single* TA, where that TA imposes to 
the CAs it certifies some naming constraints, and where these CA also impose

followed*.

Denis

>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Subject: Re: RE: 3280bis: suggested words for ambiguous DNs and 
>delegated CRLs
>
>
>
>>Tom,
>
>>don't see any major issue if the hierarchical superior of a CA issues 
>>a CRL signing certificate which can issue CRL's for the subordinate 
>>CA's. However, I don't see how to go beyond that.
>>
>>Tom Gindin
>

>>delegated CRLs
>>
>>
>>
>>Tom Gindin,
>>
>>You seem to be arguing for matching CRL certification path with that 
>>of the certificate.
>>
>>think that Denis already knows that (Permanent Identifier is certainly 
>>a way of constructing unambiguous names, for example).  The difficulty 
>>we have is when one issuer issues a certificate to an organizational 
>>CA with a subject name which is convenient and in common use for its 
>>organization,
>>
>>organizational CA with the same subject name which is also in common 
>>use for its organization.  This case is most common when both 
>>organizations use an acronym.  I do not see why the issuers of the two 
>>organizational CA
>>
>>certificates should be assumed to originate at different trust 
>>anchors, although they will be different issuers.  In fact, I don't 
>>understand why organizational name collisions are thought to be much 
>>rarer with a "common
>>

>>instance, including DC components can make a DN as unambiguous as a 
>>DNS name.  As another example, the following DN

Regards,

Denis Pinkas