Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

From: Carlisle Adams <[email-masked]>
Date: Fri, 13 Oct 2000 15:17:29 -0400

Hi Polar,

> ----------
> From: 	Polar Humenn[SMTP:[email-masked]]
> Sent: 	Friday, October 13, 2000 1:14 PM
> To: 	Carlisle Adams
> Cc: 	Stephen Farrell; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Stephen McConnell; Kent Salmond; Ken Mccoy;
> Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
> Subject: 	RE: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> Carlisle,
> 
> Thank you for your very learned and well formed response.
> 
> You do draw an important conclusion that the AA and the Holder must belong
> to the same "well-behaved" PKI in order for this scheme to work correctly.
> (I wonder how many PKI's are actually really well-behaved? :). 
 
Good question.  On the other hand, why would anyone expect to get security
from a system that was not "well-behaved"?  If security is important to you,
the onus is on you to choose (buy, implement, deploy, whatever) your PKI
carefully...

> In any case, I do not see anywhere in the ac509 profile that specifies
> that AA must belong to the same PKI (under the same rootCA?) as the
> Holder's it authorizes? Can you point me to some text stating this
> requirement, or some text that somehow implies this requirement?
 
Ed Barkmeyer also asked for this.  I haven't had a chance to skim quickly
through the profile document, so I can't comment on that one at the moment,
but this implication is definitely there in X.509 (2000).  As one example,
all through the sections on attribute certificates it talks about "the" PKI,
so it seems that the AC-based PMI is to be tied to only a single PKI.
Slightly more explicitly, however, Clause 16.1 ("Basic processing
procedure"), begins as follows:

	"The signature on every certificate in the path must be verified.
Procedures related to validating signatures and public-key certificates are
not repeated in this clause. The privilege verifier must verify the identity
of every entity in the path, using the procedures of clause 10. Note that
checking the signature on an attribute certificate necessarily involves
checking the referenced public-key certificate for its validity. Where
privileges are assigned using attribute certificates, path processing
engines will need to consider elements of both the PMI and the PKI in the
course of determining the ultimate validity of a privilege asserter's
attribute certificate."

ACs and PKCs are talked about "in the same breath" with respect to validity
checking and identity verification.  The referenced Clause 10
("Certification path processing procedure") lists the inputs to the
procedure in Section 10.1.  One of the inputs is "a trusted public key value
or key identifier (if the key is stored internally to the certification path
processing module), for use in verifying the first certificate in the
certification path".  This strongly implies to me that there is a single
trusted root key that forms the starting point for all the path processing
(which includes the AC path as well as the PKC path).

> I also see this requirement to be a crippling constraint.
> 
> The requirement for the AA and the Holder's it certificate to belong to
> the
> same PKI means that I will be able to authorize certain subject entities
> from HisCarCompany to have access to resources in MyCarCompany, unless I
> do one of the following:
> 
> 1. Create a new identity at MyCarCompany for subject entity X in 
>    HisCarCompany.
>      This is undesirable for many reasons. For example,
>      if Person X from HisCarCompany gets fired. Also, it to generate
>      new keys, new certificates, new names, new password, new
>      token card, etc. Now, causes a single-sign-on scenario.
>      
> 2. Create an entirely new PKI for the interested parties and an AA. 
>      Out of the question for most. It's Way too much work with new keys,
>      new names, new passwords, new tokens cards, etc.
 
This is not a crippling constraint because neither of the above undesirable
actions need to be taken.  If these two companies want to work together,
they need to issue cross-certificates between their root CAs anyway so that
authentication can take place.  Cross-certification ties these
previously-independent PKIs together, so that there is only a single PKI.
Appropriate name constraints in the cross-certificates ensure that identity
clashes will be ruled out of the picture, and authorization based upon
attribute certificates can proceed securely.

> It would be nice if PKI and AA combined could solve the single-sign-on
> problem.
 
If the companies follow what is outlined above, single sign-on is preserved.

> Of course, this problem would go away, if there is only one RootCA for all
> organzations, and therefore on PKI. For example, HisCarCompany, and
> MyCarCompany must get our CA certificates signed by the Verisign RootCA.
> And we and everybody that Verisign signs, must be well behaved, and the DN
> space is consequently unique.
 
I'm sure you can imagine that Entrust and Baltimore and many other PKI
providers would not be content with the scenario you paint...  :-)

But seriously, people recognized a long time ago that a single root for the
whole world will not work.  This is why cross-certification was invented --
so that independently-deployed PKIs can be joined to form a single, workable
PKI.  This is why the term "PKI networking" is sometimes used instead of
"cross-certification" (it seems slightly more descriptive).

> Is this approach realistic and practical?
 
What I described above, I believe, has the qualities of both realism and
practicality.  Cross-certification is what allows you to grow your PKI to
include other environments, but in a very controlled and reasoned manner.
Attribute certificates take the power of this secure, yet flexible,
authentication technology and overlays the power of secure, yet flexible,
authorization.  It's a very strong combination!

Carlisle.

---

From: Sean Turner <[email-masked]>
Date: Fri, 13 Oct 2000 15:37:12 -0400

Carlisle,

This should probably go in the roadmap too.

spt

Carlisle Adams wrote:

>      [email-masked]; [email-masked]; Stephen McConnell; Kent Salmond;
>      Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
>
> Good question.  On the other hand, why would anyone expect to get
> security from a system that was not "well-behaved"?  If security is
> important to you, the onus is on you to choose (buy, implement,
> deploy, whatever) your PKI carefully...
>

---

From: Polar Humenn <[email-masked]>
Date: Fri, 13 Oct 2000 17:54:49 -0400 (EDT)

Hi Carlise,

> the onus is on you to choose (buy, implement, deploy, whatever) your PKI

I don't want a closed world. I want to interoperate. This leads me to
the next point you bring up, which is about cross certification. Sorry I
snipped all the text to make this note somewhat shorter.

You say that there WILL be name constraints on CAs and they will be placed
on the cross certificates.

So, that means that the CA's when they cross certify each other have to
make sure that their name constraints (if they have any at all) are
consistent with each other.

Without doing all the set theoretic mathematics, this tells me, that if
naming constraints exist, the permitted subtrees MUST be distinct to
comprise a unique DN space for the two of them together. Otherwise, name
collisions may already exist.

I cannot figure out if the permitted subtree specification only describes
one hop from each CA certificate, or for all certificates underneath.

There is no mandate in RFC2459, that the permitted subtrees and excluded
subtrees from that CA relate to the CA's certificate DN in any way. In
fact, its explicitly called out that constraint DOES NOT exist, referring
in contrast to the PEM stringent CA and DN hierarchy.

Page 12:

      (b)  Name constraints may be imposed through explicit inclusion of
      a name constraints extension in a certificate, but are not
      required.

Therefore, while cross certifying a CA, I must chase down all the CA's and
their permitted and excluded subtrees, in general. Also, I must check the
other CA as well to make sure, which is information I don't think I have
access to.

The only place I have seen anything that looks like it will work in this
regard is in the PEM specification RFC1422, where there is a ridged
subordinate subject DN creation scheme for CAs. That is, a CA named "C=US,
O=Adiron" must generate subject DN's with "C=US, O=Adiron" in them, i.e.
"C=US, O=Adiron, OU=Research", etc. (I don't know how unwieldy that can
get at, for example, 5 or six levels of CAs deep). There is supposed to be
an Email based registry, IPRA, to make sure that the PEM root certificates
contain distinct DN's.

That document makes special dispensation for cross-certificates, or
certificates out of the application of PEM. I haven't really thought about
that.

There is a obvious reason these stringent requirements exist for the PEM
application of PKI. It is that you need unique names over this application
space because applications other than X.509 certificates reference DNs for
their purposes, i.e. other than for validation.

And, that is the case with the AA. It references DNs. They really need to
be unique, but it seems that they are not guaranteed to be.

So, why isn't there a ridged structure placed on X.509 RootCA's that the
subject names should be subordinate to the issuer DN's? There is a
definition of superior and subordinate DNs, all roots have distinct DNs,
and then make special dispensation for Cross Certificates?

Also, when RFC2459 states in the Path Validation algorithm with respect to 
the constrained subtrees state variable:

      (b)  constrained subtrees:  A set of root names defining a set of
      subtrees within which all subject names in subsequent certificates
      in the certification path shall fall. The initial value is
      "unbounded".

And processing each CA certificate:

      (j)  If permittedSubtrees is present in the certificate, set the
      constrained subtrees state variable to the intersection of its
      previous value and the value indicated in the extension field.

What does the "intersection" mean? It is not explicitly defined.

Does it mean, just the intersection of the root names named in the
constrained subtrees by explicit equality? Or does it more involved? Say
for each TYPE (DN, DNS, email, etc)  of each name in the constrained
subtress, N, if N is "superior" to at least one P of the same TYPE in the
permitted Subtrees, then replace N with P in constrained subtrees,
otherwise drop N from the constrained subtrees. If this is the case, I
would imagine then also, that an absence of a name with the same type as N
would also constitue dropping N.

If this is the case, then name constraints on the CAs would do it, and
before two companies wanted to cross certify each other their Namespaces
would have to be distinct. However, I don't think that is the case. Is it?

Cheers,
-Polar

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Oct 2000 17:31:15 +0100

Carlisle,

You're overstating the requirements for an AC to be valid. There is 
no need for the AA and holder to belong to the "same" PKI - the only 
requirement, in general, is that the RP be able to valiate the AA's PKC 
and the holder's PKC and that the AC contents be consistent with those 
two PKCs. That's what X.509(2000) says (ignoring "hints" whose significance 
we'll never know:-) and also what the PKIX AC profile says. If there is
text somewhere clearly to the contrary please point it out.

Of course, if anyone chooses to implement their RP s/w in the way you've
described then that's just fine, but irrelevant for AC profile.

Stephen.

>      Cc:     Stephen Farrell; [email-masked]; [email-masked]; [email-masked]; [email-masked];
>      Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai
>      Chin
> 
> Good question.  On the other hand, why would anyone expect to get security from a system that was
> not "well-behaved"?  If security is important to you, the onus is on you to choose (buy,
> implement, deploy, whatever) your PKI carefully...
> 
> Ed Barkmeyer also asked for this.  I haven't had a chance to skim quickly through the profile
> document, so I can't comment on that one at the moment, but this implication is definitely there
> in X.509 (2000).  As one example, all through the sections on attribute certificates it talks
> about "the" PKI, so it seems that the AC-based PMI is to be tied to only a single PKI.  Slightly
> more explicitly, however, Clause 16.1 ("Basic processing procedure"), begins as follows:
> 
>      "The signature on every certificate in the path must be verified. Procedures related to
>      validating signatures and public-key certificates are not repeated in this clause. The
>      privilege verifier must verify the identity of every entity in the path, using the procedures
>      of clause 10. Note that checking the signature on an attribute certificate necessarily
>      involves checking the referenced public-key certificate for its validity. Where privileges
>      are assigned using attribute certificates, path processing engines will need to consider
>      elements of both the PMI and the PKI in the course of determining the ultimate validity of a
>      privilege asserter's attribute certificate."
> 
> ACs and PKCs are talked about "in the same breath" with respect to validity checking and identity
> verification.  The referenced Clause 10 ("Certification path processing procedure") lists the
> inputs to the procedure in Section 10.1.  One of the inputs is "a trusted public key value or key
> identifier (if the key is stored internally to the certification path processing module), for use
> in verifying the first certificate in the certification path".  This strongly implies to me that
> there is a single trusted root key that forms the starting point for all the path processing
>      The requirement for the AA and the Holder's it certificate to belong to the
> This is not a crippling constraint because neither of the above undesirable actions need to be
> taken.  If these two companies want to work together, they need to issue cross-certificates
> between their root CAs anyway so that authentication can take place.  Cross-certification ties
> these previously-independent PKIs together, so that there is only a single PKI.  Appropriate name
> constraints in the cross-certificates ensure that identity clashes will be ruled out of the
> picture, and authorization based upon attribute certificates can proceed securely.
> 
> I'm sure you can imagine that Entrust and Baltimore and many other PKI providers would not be
> content with the scenario you paint...  :-)
> 
> But seriously, people recognized a long time ago that a single root for the whole world will not
> work.  This is why cross-certification was invented -- so that independently-deployed PKIs can be
> joined to form a single, workable PKI.  This is why the term "PKI networking" is sometimes used
> instead of "cross-certification" (it seems slightly more descriptive).
> 
> What I described above, I believe, has the qualities of both realism and practicality.
> Cross-certification is what allows you to grow your PKI to include other environments, but in a
> very controlled and reasoned manner.  Attribute certificates take the power of this secure, yet
> flexible, authentication technology and overlays the power of secure, yet flexible,

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Al Arsenault <[email-masked]>
Date: Mon, 16 Oct 2000 09:37:12 -0400

Stephen Farrell wrote:
><rest snipped>

I agree with Stephen - I can find nothing in the AC I-D that says that
the AA's PKC and the holder's PKC have to trace back to the same Root
CA.  And it was my understanding that that was decided to not be a
requirement.
As always, I'm willing to be shown where I screwed up, and this is
actually required - I've been publicly shown to be wrong so many times
that it doesn't bother me at all.  :-)

In my opinion, the "security hole" pointed out by Polar can in fact
occur, either maliciously or by "accident". (e.g., if the holder's PKC
chains back to root_CA_1, and the AA's PKC chains back to root_CA_2,
then there can be a cert under root_CA_2 with the same DN,
subjectAltName, serial number, ... as the holder's PKC. If the RP trusts
both root_CA_1 and root_CA_2, then it may be the case that the RP can't
tell which holder PKC to use. And it gets even more interesting if the
RP trusts root_CA_2 but not root_CA_1 - does the RP assume that the
right cert is the one under root_CA_2, and thus everything validates; or
does the RP think that the right holder PKC is the one under root_CA_1,
and thus reject the AC?)

However, I do not believe that the right thing to do is either mandate
the objectDigest form in the AC, or kill the AC draft.  And I don't
think it's to insert the requirement that the holder's PKC and the AA's
PKC chain back to the same root. Rather, I think that the best approach
is to acknowledge that this risk exists, and live with it. Put in an
explanation (in Security Considerations, in some other section - in the
Roadmap, too, in all likelihood - that says that if you trust two
independent Root CAs, then this is a risk you run.  

That's my .02 worth.  And if I'm wrong and missed the part in the I-D
that says the two certs do have to chain back to the same root, then I
retract the last two paragraphs.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

---

From: Polar Humenn <[email-masked]>
Date: Mon, 16 Oct 2000 10:48:07 -0400 (EDT)

> that it doesn't bother me at all.  :-)

I thought it was the case as well, that the AC can really bridge three
PKIs. That means the holder, the AA, and the RP all can have their own
different PKIs with the possibility of cross-certification of all three. I
don't even see a need for cross certification in the model. My browser
"trusts" 137 root certificates without cross-certification, and nobody
seems to care all that much.

> independent Root CAs, then this is a risk you run.  

This brush off seems to be a hard call for a group that worried so much
about the security and trust relationships of PKI to begin with. 

Well, at the very least, I'm glad that some people in the group actually
see the problem. Whether it amounts to anything significant, I can only
hope.

I cannot recommend the use of such products and services, except in
tightly controlled environments, which rules out e-commerce on the
internet, or even business-to-business on the internet, or anything on the
internet. Call me paranoid, but I am a security person, not an issurance
salesman. Unfortunately, I'd probably make a lot more money if I were the
latter. :)

Cheers,
-Polar

> retract the last two paragraphs.

-------------------------------------------------------------------
Polar Humenn                  Adiron, LLC
mailto:[email-masked]       2-212 CST      
Phone: 315-443-3171           Syracuse, NY 13244-4100
Fax:   315-443-4745           http://www.adiron.com

---

From: Al Arsenault <[email-masked]>
Date: Mon, 16 Oct 2000 17:14:31 -0400

Comments in-line, prefaced by my initials, again.

Polar Humenn wrote:
> <snip>

AWA:  Actually, I think that that's a *really band thing*.  Antime I get
a new browser installed, one of the first things I do is go delete all
the default CA certs, and then add 'em back one at a time as I need to. 
Among other things, it lets you see which certs are really being used.

> salesman. Unfortunately, I'd probably make a lot more money if I were the

AWA: Well, those who know me know that I've been called "paranoid" and a
lot of other things in my 17+ years in this security business, now. 
(Actually, I can think of at least 4 regular contributors to this list
who have called me "paranoid" at one point or another. :-) I'm generally
seen as one unwilling to accept even the tiniest of security holes. 
However, in this case, I think that it comes down to a tradeoff:

	- if the RP trusts two independent Root CAs, then there is a chance
that the two Roots can have sub-CAs that cause naming collisions.  This
applies to ACs or PKCs.

	- if you don't want to accept that risk, then as Carlisle has
suggested, you simply operate in an environment in which you don't do
this.  You make everything be "one PKI", chaining back to the "one true
Root" that you choose to/have to trust.

	- on the other hand, the benefits of accepting two independent Roots
are that you can work in two different environments, simultaneously,
without worrying about the relationship of the Roots themselves.  If I
want to use a DVNT cert issued under a DST root, and a VeriSign cert
under a VeriSign root, and an Entrust cert issued under an XYZ root, I
really don't want to care about the relationships among the top levels. 
If I choose to take the risk, it's my choice.

So: benefits of "two PKIs" vs. risks of naming collisions. Sounds like a
trade-off to me. One I think that we ought to allow.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

---

From: Polar Humenn <[email-masked]>
Date: Tue, 17 Oct 2000 09:01:59 -0400 (EDT)

On Mon, 16 Oct 2000, Al Arsenault wrote:

> > [SNIPPED] 

So, Al, Let me guess.
You are still driving your Ford Explorer with the Bridgestone tires on it.
:)

-Polar

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Oct 2000 15:46:52 -0400

I would like to redirect this thread.  We should be discussing the changes 
to the document.

What changes are needed to the base document that make it clear that 
certification paths must be validated before the authorization information 
contained in an attribute certificate can be safely used?

What changes need to be made to the Security Considerations section to 
avoid many of the problems discussed in this thread.  Carlisle Adams made 
the constructive comment that name constraints can be used to eliminate 
many of these concerns.

Can we focus on the text?

   -- Russ

---

From: Al Arsenault <[email-masked]>
Date: Tue, 17 Oct 2000 21:57:22 -0400

> I would like to redirect this thread.  We should be discussing the changes

AWA: An excellent suggestion!
 
> contained in an attribute certificate can be safely used?

AWA:  Section 5., Attribute Certificate Validation:

	Add a new 1., and renumber other items appropriately:

	To be valid an AC MUST satisfy all of the following:

   	1.   The AC holder's PK certificate must be found, and the entire
certification path of that PKC MUST be verified in accordance with
[PKIXPROF].

	2. The AC signature must be cryptographically correct, and the AC
        issuer's entire PKC certification path MUST be verified in
        accordance with [PKIXPROF]. 
	...
> the constructive comment that name constraints can be used to eliminate

AWA: I'm not wedded to the exact wording, but I'll propose:

	There is a potential security issue when an attribute certificate is
issued to a holder and the holder's PKC chains back to a root CA that is
independent from the root CA to which the AC issuer's PKC chains. 
"Independent" means that neither root CA is subordinate to the other,
and they are not cross-certified.  The security issue is that two
different PKCs, one under each of the two roots, can have the same
issuer name and serial number, and this information will be in the AC
holder field.  In this case, it may not be possible to identify to which
PKC the AC is supposed to belong, and thus attributes may be associated
with the wrong holder.

	The primary solution to this issue is for RPs to only accept AC/PKC
combinations that chain back to a common root CA, or to CAs that (1) are
cross-certified; and (2) enforce name constraints to ensure that there
are not two issuers with the same names.

> Can we focus on the text?

Okay, take your shots at it.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

---

From: Polar Humenn <[email-masked]>
Date: Tue, 17 Oct 2000 22:57:49 -0400 (EDT)

> certification path of that PKC MUST be verified in accordance with

Hmmm. I didn't realize that wasn't there, or I thought it was at least
implied by (2).

> 	There is a potential security issue when an attribute certificate is
                 ^^^^^^^^^^^
  There is a security issue

> are not two issuers with the same names.

Oh well, I can't see what techincal merit can be brought forth in the
"Security Concerns" section, especially with no possible means of solving
the problem other than declaring you to have eminate domain over all
parties, AAs,RPs,PKC RootCAs, involved. I wouldn't really need a public
standard in that case.

In addition, the (2) is not good enough. You have to ensure that there are
no two issuers with the same names when using the Issuer-Serial
baseCertificateId option, or no two end entities with the same names.  Of
course, a Relying Party may not know what he's going to get handed to it,
Issuer-Serial or entityName, since he MUST accept both. Correct?
Therefore, all DNs MUST be unique. Of course, that does nothing for
established PKIs that *already* have name collisions, or the possiblity
for creating them.

Anyway, who does the enforcing? The RP or does the cross certification of
CAs have to figure out what name constraints don't issue collisions a
priori? That means they either have to permit all the trees that don't
have collisions, or either deny all the trees that do have collisions.
This is not simple. Especially if you want identities in those collision
spaces to actually do something.

Cheers,
-Polar

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Oct 2000 14:31:44 +0100

Hi Al,

> AWA: An excellent suggestion!

Seconded. (Thirded?)

>         To be valid an AC MUST satisfy all of the following:

I'm nearly ok with this. Minor caveat is that I'd still like that
the AC profile doesn't mandate PKCs for holder->RP authentication,
so I'd tweak it to:
 
"1.   Where the holder uses a PKC to authenticate to the AC verifier, then 
the AC holder's PKC MUST be found, and the entire certification path of 
that PKC MUST be verified in accordance with [PKIXPROF]. As noted in 
the security considerations section, if some other authentication scheme
is used, AC verifiers need to be very careful mapping the identities
(authenticated identity, holder field) involved."

Similarly, I'd tweak the security considerations section text:

"         There is a potential security issue when an attribute certificate is
 issued to a holder and the holder's PKC chains back to a root CA that is
 independent from the root CA to which the AC issuer's PKC chains.
 "Independent" means that neither root CA is subordinate to the other,
 and they are not cross-certified.  The security issue is that two
 PKCs, (one under each of the two roots), belonging to two different holders, might 
 have the same subject field or even issuer name and serial number, and this 
 information will be in the AC holder field.  In this case, it may not be possible 
 to identify which PKC authenticates the AC holder, and thus attributes may 
 be associated with the wrong holder.

         One solution to this issue is for AC verifiers to only accept AC/PKC
 combinations where both the holder's and AC's PKCs chain back to a common root CA, 
 or to CAs that (1) are cross-certified; and (2) enforce name constraints to ensure 
 that there are not two issuers with the same names. Failing this, AC verifiers
 have to establish (using other means) that the potential collisions cannot
 actually occur, for example, the CPSs of the CAs involved may make it clear that
 no such name collisions can occur.

> Okay, take your shots at it.

Minor tweaks only:-)

BTW: There was also the issue raised by Tom Gindin (and supported by
James Manger) about allowing entityName = subject *or* any subjectAltName
(it currently only allows entityName = subject for this case). I asked folks 
to comment, but only James supported it and no one objected. Failing 
further comments, I'll include this change too.

Stephen.

---

From: Polar Humenn <[email-masked]>
Date: Wed, 18 Oct 2000 10:07:26 -0400 (EDT)

>  no such name collisions can occur.

I don't know if Stephen saw my previous comment before he wrote this.
So, I'll just reiterate that stating that two issuers that have the same
names are not enough, especially when you must accept an entityName with a
DN in it. I'll propose a rewording of (1) and (2) togther:

>  combinations where both the holder's and AC's PKCs chain back to a common root CA, 

or to CAs that are cross-certified such that name constraints are enforced
to ensure that there MUST NOT be two end entities with the same names.
Failing this, AC verifiers

>  no such name collisions can occur.

I don't really like this last part, but I don't really understand the Law
that applies to CPSs and how it can enforce problems, especially
automatically. All it does do is prevent a ligitimate user from using its
privileges, because the AC verifier couldn't really be sure if there was
another legitmate or illegitimate user with the same name.

I am sad that the technology cannot be introduced to ensure that this
problem doesn't exist and all we can get out of it is a warning label on
the side of the box.

Cheers,
-Polar

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 18 Oct 2000 16:35:31 +0200

> AWA: An excellent suggestion!

I guess that everybody strongly agrees. :-)

> PKC the AC is supposed to belong, and thus attributes may be associated

There is a way to (partially) "fix" this security hole. We currently have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] IssuerSerial OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate  ...

if we use ESSCertID (defined in RFC 2634 - CMS) instead of IssuerSerial then
we have:

           Holder ::= SEQUENCE {
                 baseCertificateID   [0] ESSCertID OPTIONAL,
                          -- the issuer and serial number of
                          -- the holder's Public Key Certificate ...

with 

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

and, in that case, having IssuerSerial present.

Then we would need some additional text in the explanations to say that the
hash of the certificate should also be tested.

In this way, at the time of verification, there is no ambiguity about the
link between the AC and the certificate, even if the CA has the same name as
another CA certified from a different root key.

The only problem is that this makes an ASN.1 definition different from the
ISO X.509 definition. If we plan to adopt that change, then we should raise
a defect report to ISO, which is, I think, a real defect: a comment for such
a change was raised by AFNOR (comment numbered 43) and is marked in the
disposition of comments "accepted in principal". I had not checked the text
changes (I am always trusting Sharon), but apparently there has been no
change done. :-(

==========================================================================

Copy of the original comment 43 from AFNOR.

43. Page 30. Section 13.7. Attribute certificate syntax. There is a security
weakness in the linkage of the attribute certificate with a public key
certificate, even when the baseCertificateId is used. 

The current proposal provides no protection if the key of the CA is
compromised. 

In such a case an attribute certificate could point to "CA from Delta
company, number 1234567" which is the certificate from Mr Dupont, but if the
CA key is compromised then the attacker could forge a certificate with the
same serial number that would contain the name Mr Durand. The way to counter
that threat is to include the hash of the public key certificate as well.
The ASN1 should be changed to a sequence of both the serial number and the
hash of the certificate and the corresponding explanations should be
adjusted accordingly.

IssuerSerial within the ASN1 syntax of Owner should be changed into: 

CertificateUniqueIdentifier

with:

CertificateUniqueIdentifier ::= SEQUENCE {
	certSerialNumber	CertificateSerialNumber,
	certDigestInfo	ObjectDigestInfo
}

==========================================================================

> are not two issuers with the same names.

If there is a single trusted root CA, then the problem vanishes, :-) bit we
cannot mandate this. 

For (1), we cannot either mandate cross-certificates and a single root.

For (2), name constraints are not that easy to handle. I would prefer the
use of the certificate hash, as indicated above to solve the issue and
others as indicated in the AFNOR comment 43. This is also simpler.

Denis

---

From: Polar Humenn <[email-masked]>
Date: Wed, 18 Oct 2000 12:38:49 -0400 (EDT)

On Wed, 18 Oct 2000, Denis Pinkas wrote:

>> [SNIP]

Dennis,

I still think that this solution doesn't quite solve the problem, but is a
good start.  In fact Tom Gindin's suggestion just came in and includes
yours. So I'll sort of work off of that.

The fact is that the entityName option still contains a DN and the RP MUST
be prepared to accept it. However, on what conditions should the RP accept
the Holder as a DN? (Especially if this verification is offloaded to some
remote verification engine).

Perhaps there is a way to word the USE of a DN entityName? 

When using an AC that contains the Holder specification as a DN entityName
option, the DN MUST verifiable and uniquely name an entity within the PKI
of the AA, (i.e. resolved under the same RootCA as the AC). The AA MUST
ONLY create AttributeCertificates with the Holder as a DN entityName in
this fashion. This constraint is subject to the entire PKI for which the
AA belongs belongs to behave in its creation of unique DN. Therefore,
verification is subject to the trust the RP places in the AA and its PKI
together to conform to this behavior.

[Note: this approach still does not solve the problem that Denis brings up
below as comment 43. A subordinate CA may be compromised within the PKI of
the AA and create impostor certificates, grabbing privileges.]

Therefore, it would still probably be better to use the Issuer/Serial and
a hash of the Issuer's certificate, even if in the same PKI.

Of course, when an application authenticates to an RP using PKCs this ties
the authorization to a particular certificate. Apparently that was not
desirable due to the effect of key rollover and new certificates being
issued to the same subject entity.

However, I think that if as Carlise pointed out, that if the DN is only
used in the case of a single trusted Root, then everything will be fine.

So, as Russ asked me to propose text, here it goes:

Using Tom's suggestion (I took the liberty to use the ObjectDigestInfo
that is already defined in the document for the certificate Hash).

Section 4.1:

   Holder ::= SEQUENCE {
        baseCertificateID   [0] IssuerSerial OPTIONAL,
                -- the issuer and serial number of
                -- the holder's Public Key Certificate
        entityName          [1] GeneralNames OPTIONAL,
                -- the name of the claimant or role
        objectDigestInfo    [2] ObjectDigestInfo OPTIONAL,
                -- if present, version must be v2
        verifiedBaseCertificateID     IssuerSerialCertID OPTIONAL
   }

   IssuerSerialCertID ::=  SEQUENCE {
        isserCertDigest          ObjectDigestInfo,
        issuerSerial             IssuerSerial
   }

In section 4.2.2 Holder add:

When using an entityName that contains a DN, the DN MUST verifiably and
uniquely name an entity within the PKI of the AC issuer. The PKC named by
the DN MUST verify back to the root CA of the AC issuer. The AC issuer
MUST ONLY create AttributeCertificates with the Holder as a DN entityName
in this fashion. This constraint is subject to the entire PKI for which
the AC issuer belongs to behave in its creation of unique DNs. Therefore,
verification is also subject to the trust the RP places in the AC issuer's
PKI to conform to this behavior.

In Section 5 the AC Validation Criteria is as follows: (keeping 1 as 1,
inserting 2, 3, and 4 below, and renumbering accordingly).

1. The AC signature MUST be cryptographically correct, and the AC
   issuer's entire PKC certification path MUST be verified in
   accordance with [PKIXPROF].

2. When the AC holder is named by a DN using the entityName option,
   the holder's PK certificate MUST be uniquely found under the same root
   CA as the AC issuer. The entire certification path of that PKC MUST be
   verified in accordance with [PKIXPROF].

3. When the AC holder is named by a baseCertificateId, the issuer's PK
   certificate MUST be uniquely found under the same root CA as
   the AC issuer. The entire certificate path of that PKC MUST
   be verified in accordance with [PKIXPROF].

4. When the AC holder is named by a verifiedBaseCertificateID, the
   named holder issuer's PKC must be found, and that PKC MUST correctly
   digest to the digest value contained in the verifiedBaseCertificateID.
   The entire certificate path starting with the holder's PKC and the PKC
   of the issuer the holder's PKC MUST be verified in accordance
   with [PKIXPROF].

.....

Note: there is *still* a problem with AC targeting and proxying using
just DNs.

Cheers,
-Polar

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Wed, 18 Oct 2000 13:32:42 -0400

Denis Pinkas wrote (in part):

snip 

> changes (I am always trusting Sharon), but apparently there has been no

It is a really bad idea to break compatibility 
with an international standard you are attempting
to profile. Suggesting such a course of action is
ridiculous.

No matter how benign they may appear to be, any ASN.1
changes made to the AC profile in order to attempt to
force changes into X.509 would not be wise. This would
likely lead to two different notations for ACs.

Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Oct 2000 13:48:52 -0400

Polar:

You are proposing syntax that is no longer compatible with X.509.  I am 
very unhappy with such a deviation.

Russ

---

From: Polar Humenn <[email-masked]>
Date: Wed, 18 Oct 2000 14:09:59 -0400 (EDT)

> very unhappy with such a deviation.

Hmmm. I only went on that taking into account Tom and Denises suggestion.
Do you feel that an attribute extension would be warranted instead?

Cheers,
-Polar

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Oct 2000 14:23:10 -0400

An attribute or extension is the only acceptable approach to me, unless we 
coordinate with X.509 agrees to make the same change to the base syntax.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Oct 2000 03:13:12 +0100

I completely agree.

Stephen.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 19 Oct 2000 10:30:04 +0200

Russ,

> coordinate with X.509 agrees to make the same change to the base syntax.

Since you said ... "unless we coordinate with X.509 agrees to make the same
change to the base syntax", there are two solutions, not a single acceptable
approach. On that basis, I agree with you.

We can certainly attempt to coordinate with ISO, since the Orlando meeting
is coming. I am a member of the ISO defect report team and can certainly
bring the attention of the ISO group on that topic. :-)

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 23 Oct 2000 13:57:55 +0200

Russ,

> bring the attention of the ISO group on that topic. :-)

After some side discussion with Tom Guidin, Tom made a very good
observation. The current syntax is:

   Holder ::= SEQUENCE {
      objectDigestInfo    [2] ObjectDigestInfo OPTIONAL

This syntax could be used without any change, since we have, as Tom noticed,
a SEQUENCE of OPTIONAL elements and not a CHOICE. So we would only need to
fix the text without changing the ASN.1 syntax, by adversing the combination
of the use of both the baseCertificateID and the objectDigestInfo
parameters.

Here is an extract of the ISO text, which does not explicit mention that
combination (but does not prevent it either):

" The version number differentiates between different versions of the
attribute certificate. If holder includes objectDigestInfo or if issuer
includes baseCertificateID or objectDigestInfo, version must be v2.

The holder field conveys the identity of the attribute certificate's holder.
 
The baseCertificateID component, if present, identifies a particular
public-key certificate that is to be used to authenticate the identity of
this holder when asserting privileges with this attribute certificate.

The entityName component, if present, identifies one or more names for the
holder. If entityName is the only component present in holder, any
public-key certificate that has one of these names as its subject can be
used to authenticate the identity of this holder when asserting privileges
with this attribute certificate. If baseCertificateID and entityName are
both present, only the certificate specified by baseCertificateID may be
used. In this case entityName is included only as a tool to help the
privilege verifier locate the identified public-key certificate.

Note: There is a risk with the sole use of GeneralNames  to identify the
holder, in that this points only to a name for the holder. This is generally
insufficient to enable the authentication of a holder's identity for
purposes of issuing privileges to that holder. Use of the issuer name and
serial number of a specific public-key certificate, however, enables the
issuer of attribute certificates to rely on the authentication process
performed by the CA when issuing that particular public-key certificate.
Also, some of the options in GeneralNames (e.g. IPAddress) are inappropriate
for use in naming an attribute certificate holder, especially when the
holder is a role and not an individual entity. Another problem with
GeneralNames alone as an identifier for a holder is that many name forms
within that construct do not have strict registration authorities or
processes for the assignment of names.
 
The objectDigestInfo component, if present, is used directly to authenticate
the identity of a holder, including an executable holder (e.g. an applet).
The holder is authenticated by comparing a digest of the corresponding
information, created by the privilege verifier with the same algorithm
identified in objectDigestInfo with the content of objectDigest. If the two
are identical, the holder is authenticated for purposes of asserting
privileges with this attribute certificate."  

Some small changes to that text *might* be needed to say that the
baseCertificateID may be used in conunction with the objectDigestInfo
component. In fact the use of that combination might even only appear in the
PKIX profile, while it would be "better" to have the two documents aligned.

Denis

---

From: Polar Humenn <[email-masked]>
Date: Mon, 23 Oct 2000 11:53:18 -0400 (EDT)

Denis,

I am in agreement with you on your approach of including the objectDigest
Info along with entityName or baseCertificateID. I think in environments
where the Relying Parties, Attribute Certificate Issuers, and Subject
Entities do not know and trust a priori the certificate management
environment they all are emphatically working in, then the entityName
and/or baseCertificateID must only be used in conjunction with the
objectDigestInfo.

A good thing would be to figure out under the precise conditions in which
a compliant Attribute Certificate Issuer MUST include objectDigestInfo.

I can think of one of the conditions right off.

In applications where there is no absolute assurance by all three classes
of possible parties, i.e. subjects, attribute certificate issuers, and
relying parties, are privy to each others business practices about the
use of DN's.

I am not yet sure how you can write such requirements without getting
agreements from all three parties.

-Polar