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

From: Carlisle Adams <[email-masked]>
Date: Mon, 16 Oct 2000 10:17:36 -0400

Hi Al, Stephen,

> ----------
> From: 	Al Arsenault[SMTP:[email-masked]]
> Sent: 	Monday, October 16, 2000 9:37 AM
> To: 	[email-masked]
> Cc: 	Carlisle Adams; 'Polar Humenn'; [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
> 
> Stephen Farrell wrote:
> > 
> > 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.
> > 
> ><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.  :-)
 
The text that I quoted in my previous message is from X.509 (2000), not from
the AC I-D.  I have not checked, but I strongly suspect that the I-D says
nothing about this, which is probably why you cannot find it.  I think that
the X.509 text implies this pretty clearly, but I don't think this is stated
explicitly.

> 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?)
 
Yes, I agree that the "security hole" can occur if multiple PKIs are
involved, which is why I believe that the underlying assumption in X.509
(2000) is that there is one PKI and that it is managed in such a way as to
avoid identity collisions through proper use of name constraints.  This
eliminates the security hole (which, ultimately should be the goal of a
security infrastructure).

Even aside from security, however, I think that allowing for multiple PKIs
here is unreasonable in practice.  As Stephen said, what is required is that
the RP can validate the AA's PKC and the holder's PKC and that the AC
contents are consistent with those two PKCs.  But in general the AA
(particularly the SOA) does not know who the relying parties will be,
especially if delegation is involved so that there are intermediate AAs
(this is identical to a root CA not knowing who its relying parties are in
general when there are subordinate CAs in between).  So why would it make
sense for the SOA to create certificates that only RPs with trust anchors in
these two PKIs can validate?  It has no way of knowing if such RPs even
exist (they *probably* do, but the SOA doesn't know who they are, or where
they are, or what their needs/assumptions will be with respect to
authorization)!  I just can't see much value in this level of
generalization.  I'm not saying that this can't be done, or that we should
necessarily do anything to prohibit it, but I don't see the value of it and
I wonder if it actually would be used.

So, I suggest that security and simplicity both lean toward the single PKI
model.

> 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.  
 
Fair enough.  That way, those that are serious about security can "do the
right thing" and those for whom security is less important can "hope that
bad things don't happen"...  :-)

> 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.
 
As mentioned above, I doubt that you missed anything in the I-D.  But look
at .509 again with fresh eyes and let me know if I'm just imagining this
underlying assumption in the text.

Carlisle.

---

From: Dale Gustafson <[email-masked]>
Date: Mon, 16 Oct 2000 10:40:38 -0500

Hi Carlisle,

I think Polar is saying that an AC should be able to (optionally) contain a
pointer to "one and only one" PKC chain.  This seems like a reasonable
requirement given that this same concept has already been defined in several
forms for a single PKC within RFC-2459, RFC-2560, et. al.

PKI providers could still follow their preferred architectural approach
(cross-certify .vs. trust-points).  The "PKC chain pointer" structure would
probably be useful in other specifications.

Such a structure might contain a pointer to the first and last certificates in
the chain {issuer DN, serial number, cert hash} and a hash of the entire,
ordered PKC chain.  This chain pointer would map to only one PKC chain.  There
may be other representations that are more elegant yet equally effective.

Best Regards,

Dale Gustafson

Carlisle Adams wrote:

>      Cc:     Carlisle Adams; 'Polar Humenn'; [email-masked];
>      [email-masked]; [email-masked]; [email-masked]; Stephen McConnell; Kent
>      Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul; Susan Older; Shiu-Kai Chin
>
> Yes, I agree that the "security hole" can occur if multiple PKIs are involved,
> which is why I believe that the underlying assumption in X.509 (2000) is that
> there is one PKI and that it is managed in such a way as to avoid identity
> collisions through proper use of name constraints.  This eliminates the
> security hole (which, ultimately should be the goal of a security
> infrastructure).
>
> the RP can validate the AA's PKC and the holder's PKC and that the AC contents
> are consistent with those two PKCs.  But in general the AA (particularly the
> SOA) does not know who the relying parties will be, especially if delegation
> is involved so that there are intermediate AAs (this is identical to a root CA
> not knowing who its relying parties are in general when there are subordinate
> CAs in between).  So why would it make sense for the SOA to create
> certificates that only RPs with trust anchors in these two PKIs can validate?
> It has no way of knowing if such RPs even exist (they *probably* do, but the
> SOA doesn't know who they are, or where they are, or what their
> needs/assumptions will be with respect to authorization)!  I just can't see
> much value in this level of generalization.  I'm not saying that this can't be
> done, or that we should necessarily do anything to prohibit it, but I don't
> see the value of it and I wonder if it actually would be used.
>
> right thing" and those for whom security is less important can "hope that bad
> things don't happen"...  :-)
>
> As mentioned above, I doubt that you missed anything in the I-D.  But look at
> .509 again with fresh eyes and let me know if I'm just imagining this

---

From: "Stephen McConnell" <[email-masked]>
Date: Mon, 16 Oct 2000 18:26:18 +0200

Seems to me that Dale's comment seems to properly address the issue here.

Cheers, Steve.

> -----Original Message-----
> From: Dale Gustafson [mailto:[email-masked]]
> Sent: Monday, 16 October, 2000 17:41
> To: Carlisle Adams
> Cc: [email-masked]; 'Al Arsenault'; 'Polar Humenn';
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> Stephen McConnell; Kent Salmond; Ken Mccoy; Thumrongsak Kosiyatrakul;
> Susan Older; Shiu-Kai Chin
> I think Polar is saying that an AC should be able to (optionally)
> contain a pointer to "one and only one" PKC chain.  This seems
> like a reasonable requirement given that this same concept has
> already been defined in several forms for a single PKC within
> RFC-2459, RFC-2560, et. al.
>
> PKI providers could still follow their preferred architectural
> approach (cross-certify .vs. trust-points).  The "PKC chain
> pointer" structure would probably be useful in other
> specifications.
>
> Such a structure might contain a pointer to the first and last
> certificates in the chain {issuer DN, serial number, cert hash}
> and a hash of the entire, ordered PKC chain.  This chain pointer
> would map to only one PKC chain.  There may be other
> representations that are more elegant yet equally effective.
>
> Best Regards,
>
> Dale Gustafson
>
>
>
>
> Carlisle Adams wrote:
>
> >
> >
> > Hi Al, Stephen,
> >
> >      ----------

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Oct 2000 18:03:49 +0100

Carlisle,

Where in X.509(2000) is there an assertion that a "single" PKI is good, bad
or indifferent w.r.t. AC validity? I certainly don't recall one. (Maybe Hoyt 
or Sharon can clarify this?)

> The text that I quoted in my previous message is from X.509 (2000), not from the AC I-D. I have
> not checked, but I strongly suspect that the I-D says nothing about this, which is probably why
> you cannot find it.  

You won't find it since its not there, nor (IMO) should it be.

> I think that the X.509 text implies this pretty clearly, but I don't think
> this is stated explicitly.

Looks like we disagree on this. This is the X.509 quote (I hope:-):

     "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."

To me, that's prettly clearly saying: "check all PKC's involved" and nothing 
about relationships between the different roots involved.

Regards,
Stephen.

-- 
____________________________________________________________
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: Stephen Farrell <[email-masked]>
Date: Mon, 16 Oct 2000 18:13:12 +0100

Dale,

> forms for a single PKC within RFC-2459, RFC-2560, et. al.

I'm not sure what you mean here, AFAIK neither RFC contains such a 
structure or requirement.
 
> may be other representations that are more elegant yet equally effective.

In general, I don't believe this would be useful, e.g. imagine an 
originator (say an AA or an originating mail UA) including such 
an attribute in a signed data structure (an AC or s/mime message). 
Now the originator has no way to know what path(s) will be ok for the 
relying party, so this attribute can at best be a hint unless you 
effectively force the originator to "know" about the relying party's 
PKI settings. 

So, either:

- its a hint (why bother if it can be ignored?), or,
- the originator has to know the RP's settings (and we've just made
  general interop *much* harder if not impossible)

I also think folks are getting carried away here - when has any
real CA service been vulnerable to the types of (particularly
CA!) name collisions that are being claimed here? If it were, how 
much confidence should you have in anything else it claims to 
offer? I think this is just another case where the certificate
syntax itself cannot fully represent the underlying (PKI or
PMI) policy settings.

Regards,
Stephen.

---

From: Dale Gustafson <[email-masked]>
Date: Mon, 16 Oct 2000 13:48:11 -0500

Hi Stephen,

Comments inline.

Best Regards,

Dale Gustafson

Stephen Farrell wrote:

Dale,

> I think Polar is saying that an AC should be able to (optionally)
contain a

What I mean is a value that maps, cryptographically, to only one certificate.
For example if you create a pointer structure that includes a hash of the
target certificate then you can be pointing to only one certificate (since
two different certificates cannot produce the same hash value).

So a pointer to a single certificate might be something like:

CertPTR
::=     SEQUENCE {

issuerName
Name, -- Issuer's DN

serialNumber
CertificateSerialNumber,

hashAlgorithm
AlgorithmIdentifier,

certHash
OCTET STRING -- hash of certificate including issuer's signature }

PKIX RFCs and drafts have used several variations of this technique
to create a pointer to a specific certificate.  For example, RFC-2560,
page 7, defines "CertID" which includes a hash of the issuer name and a
hash of the issuer's public key value.

PKI settings.

The described pointer is a shorthand representation of the full PKC chain,
all or part of which is currently included in a typical signed S/MIME message.
This should be equally useful.

So, either:

PMI) policy settings.

I think the potential attack described earlier is that a bad guy would
intentionally assume the name of a legitimate CA for the express purpose
of gaining use of permissions, etc. provided by someone else's AC.
So we can't say this is unlikely to occur.

Regards,

Stephen.

--

Stephen Farrell

61 Fitzwilliam Lane,
fax: +353 1 647 7499

Dublin 2.
mailto:[email-masked]

Ireland
http://www.baltimore.com

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Oct 2000 20:51:32 +0100

Hi Dale,

> What I mean is a value that maps, cryptographically, to only one certificate.  

Ok there are lots of examples of pointing to one certificate all right, however,
I don't know of any that point to one certificate *path*, which is what I thought
you meant.

> I think the potential attack described earlier is that a bad guy would intentionally assume the
> name of a legitimate CA for the express purpose of gaining use of permissions, etc. provided by
> someone else's AC.  So we can't say this is unlikely to occur.

Yes, but that attack applies in all PKI cases - it amounts to 
grabbing the root configuration information of the RP, as 
discussed in Al's earlier message. If we need new bits on the
wire to protect against this, then that'd affect all PKIX
specifications and probably S/MIME, TLS and IPSec too. Do we 
really need to go there? I don't believe so. (And I certainly 
don't want to either:-) I can't see any reason why the AC 
profile is any different from any of those, in the face of 
"stomping on root CA configuration" attacks.

And so I don't see any need to add such new attributes to an
AC.

Stephen.

---

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

Hi,

I do not agree with Carlisle that the AC must verify to the same root CAs
and cross-certifications of root CAs. Nor do I think that
cross-certification eliminates name clashes in the DN space. Nor do I
think that cross-certification is actually required for it to work.

I think all naming schemes follow the basic structure of a name and an
ubiquitous identifiable scope.

Likewise, the AC Holder should have the same thing. If you end up naming
the Holder with a DN you must have a scope in which that name is defined.

Naming the Holder's Root CA (DN) and a hash of its certificate, and maybe
a path length, would probably close the door on this security hole. This
approach names the Holder and its PKI, i.e. name and scope. The scope for
the Holder can be implemented as a standard optional critical attribute.
It isn't a hint, it needs to be verified.

That way AAs and RPs have a way to make sure this door on this security
hole doesn't open. Without it you are forced to accept a risk in using
this technology.

I still have to remind the group that the same exact problems exist with
naming of Proxies and Targets of the AC. Maybe new attributes should be
invented that replace the current ProxyInfo and TargetInfo that names the
proxy or target and the scope of each.

Cheers,
-Polar

-------------------------------------------------------------------
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: Polar Humenn <[email-masked]>
Date: Mon, 16 Oct 2000 17:10:24 -0400 (EDT)

Hi, 

comments below.

> "stomping on root CA configuration" attacks.

I will not deny that if you grab root configuration information of any RP
that you have a problem in the PKI space. However, this attack doesn't
require you to grab the root configuration. It merely relies on a name
collision whether it is malicious or coincidental.

With AC's you have an indirection problem because you are "naming" a
holder with a DN. You are not doing ANY verification on anything common
between the RP and the AA with respect to the holder.

In TLS you are not naming anything. You present the certificate chain. The
chain has all the evidence you need to do verification of the subject of
the certificate chain. It verifies the authentication signature.

In applications of S/MIME, you are looking to verify a signature of the
subject. You can send the subject's certificate chain if you wish, which
reduces the problem to TLS above. In the advent that you don't send the
certificates, you can name the subject's certificate, but you still have
something, a signature that needs to be verified. So, if you don't get the
correct certificate verification of that signature CANNOT happen.

If in AC's you only name the Holder using its DN you have the following
problem. If you have the possibility of having [CA1,Holder] and
[CA2,Holder] (i.e. a name collision between the CA1 and CA2 spaces) where
[x,y] means x certifies y, in your believable world, there is nothing the
RP can do with just the AC to verify that the AC is certifying CA1's
Holder as opposed to CA2's Holder.

I don't have to grab anybody's root configuration information.

Cheers,
-Polar

---

From: Dale Gustafson <[email-masked]>
Date: Tue, 17 Oct 2000 09:40:51 -0500

Hi Stephen,

Comments inline.

Best Regards,

--dg

Stephen Farrell wrote:

Hi Dale,

> What I mean is a value that maps, cryptographically, to only one certificate.

Ok there are lots of examples of pointing to one certificate all right,
however,

I don't know of any that point to one certificate *path*, which is
what I thought

you meant.

> I think the potential attack described earlier is that a bad guy would
intentionally assume the

And so I don't see any need to add such new attributes to an AC.

I believe the potential attack consisted of replacing the entire PKC chain.
This could done if the Holder's PKC was identified only by issuer and serial
number within the AC and the attacker was somehow able to get a different
key (and the holder's DN and serial number) certified by any other accepted
CA.

A significant difference in the AC case is that the Holder's public
key is outside of the AC so there needs to be a solid link from the AC
to the holder's PKC.

If referencing the holder's PKC only (rather than a specific PKC chain)
is architecturally more elegant, then I agree that's a better solution.

Stephen.

--

Stephen Farrell

61 Fitzwilliam Lane,
fax: +353 1 647 7499

Dublin 2.

Ireland

http://www.baltimore.com