Subject: Re: New other certs extension I-D

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Jan 2008 13:40:27 -0500

At 10:53 PM +0000 12/21/07, [email-masked] wrote:
>Hi Steve,
>
>>  I did a quick read of the I-D
>
>Thanks for taking the time to read this.
>
>>  I do have a concern.  The text says:
>>
>>  When this extension is present the CA is asserting that the same end
>>  entity is the subject of the relevant certificates. Mechanisms for
>>  how this assertion is validated by the CA or used by consumers of the
>>  certificate are out of scope of this memo.
>>
>>  I agree that the CA's actions re validation may be outside the scope
>>  of a document like this. However, we might say that CA is expected to
>>  have acted in accordance with any CP cited in the new cert, and
>>  performed whatever validation called for in the CPS for the CA.
>>
>>  I am less sanguine about being silent re what the client (RP) is
>>  expected to to do based on these links.  That creates a dangerous
>>  ambiguity. Since there were some examples provided to motivate this
>>  extension, I think you should use those as a starting point to
>>  describe what you think a client will do, based on this extension.
>
>Yes, as written there'd be nothing to stop a CA
>putting in references to web server certs and VPN g/w certs
>and code signing certs all in one place, which does
>seem odd but I didn't see a security problem arising.
>
>I did think of adding an OID in there, e.g. to say that
>all the linked certs are current or former web server
>certs issued to the same organisation/web site. However,
>I didn't see a concrete problem with leaving that out,
>so I did. Might be worth thinking again though.
>
>Or, I suppose one could simply make the extension specific
>to web server certs, but that feels a bit wrong, as I reckon
>there must be other uses for this extension.

Stephen,

Maybe my comments were not precise enough.

My concern is that there is not sufficient description of what an RP 
MUST/SHOULD do with the info provided via this proposed extension. 
Giving example of what an RP MIGHT do is not enough. We need to be 
precise. In so doing, we should be able to figure out what 
constraints are imposed on CAs who make use of the extension, and 
what security implications arise.

If we just create syntax for transporting these pointers, and some 
suggestions about what an RP might do with the info, we create a 
situation where a CA doesn't know what utility they provide (because 
it cannot count on how an RP will use the info) and users cannot know 
what their local PKI engines are doing with the info, which may 
undermine local PKI management efforts.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Jan 2008 12:13:17 +0000

Hi Steve,

> MUST/SHOULD do with the info provided via this proposed extension.

I'm still not getting the concern. Since this extension is not part of
path validation, the RP actions are essentially application specific, so
there're no MUSTs or SHOULDs required for the RP here, other than to
re-iterate that an RP MUST only use certs that passed 3280(bis)
validation, which I took as implicit but might be worth calling out.

That's more or less what we do with e.g. SubjectDirectoryAttributes
[1] which is also not an input to path validation.

However, if there're any security concerns then there could be some
MUST NOTs, for example, it might make sense to say that an RP MUST
NOT assume that the other certs all have the same key usage etc.,
but that's sort-of motherhood and apple pie stuff, and I guess
isn't what you meant.

> precise. In so doing, we should be able to figure out what constraints
> are imposed on CAs who make use of the extension, and what security
> implications arise.

> situation where a CA doesn't know what utility they provide (because it
> cannot count on how an RP will use the info) and users cannot know what
> their local PKI engines are doing with the info, which may undermine
> local PKI management efforts.

Can you give an example? (I've thought about it a little bit, but
haven't come up with a good example of a problem that wouldn't just
be an implementation bug in an RP.)

As to a CA not knowing the utility, I disagree. Were this extension
to see real life use, then CAs would surely only include it when
they do understand the effects. (I can even imagine them charging
a premium;-)

Stephen.

[1] http://tools.ietf.org/html/draft-ietf-pkix-rfc3280bis-10#page-38

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jan 2008 11:14:41 -0500

>[1] which is also not an input to path validation.

Yes, but SDA is marginal and we used to disparage its use :-). (In 
RFC 2459 we said "The subject directory attributes extension is not 
recommended as an essential part of this profile, but it may be used 
in local  environments." and I'm sorry we deleted that warning in 
3280.)

Here I think the danger is greater, because we're including pointers 
to cert but not being explicit about what we expect RPs to do with 
them.  It's not enough to say that the certs have to pass the 
validation policy. If an app believes that the a cert pointed to by 
this extension is intended to replace one it already associates with 
a given entity, then this might create problems at the 
not-well-defined interface between the PKI modules and applications. 

>but that's sort-of motherhood and apple pie stuff, and I guess

no, it's not.

>be an implementation bug in an RP.)

As noted above, we don't prescribe the interface between PKI 
processing and app use of data that comes from that processing. If 
this extension is intended to solve a specific problem in this realm, 
then we need to be precise in describing what the problem is, and how 
this extension solves it. I am not comfortable defining an extension 
for which we do not do this.

>they do understand the effects. (I can even imagine them charging

Then let's have CAs contribute to the discussion and say what they 
would do with the extension, and how they want RPs to process it.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Jan 2008 17:12:43 +0000

Hiya,

Stephen Kent wrote:
> Here I think the danger is greater, because we're including pointers to
> cert but not being explicit about what we expect RPs to do with them. 
> It's not enough to say that the certs have to pass the validation
> policy. If an app believes that the a cert pointed to by this extension
> is intended to replace one it already associates with a given entity,
> then this might create problems at the not-well-defined interface
> between the PKI modules and applications. 

That's possibly true, but also possibly not. Given that we
don't specify those APIs here we can't really tell, and since
this would be a non-critical extension, only applications that
go looking (and hence understand what they want to do) would
find out about its existence.

> As noted above, we don't prescribe the interface between PKI processing
> and app use of data that comes from that processing. 

Right.

> If this extension
> is intended to solve a specific problem in this realm, then we need to
> be precise in describing what the problem is, and how this extension
> solves it. 

I would claim that (modulo -00 type text), there is the core of
such a problem and solution description in the draft. Totally
agree that it needs work though.

> I am not comfortable defining an extension for which we do
> not do this.

But I don't see how to tell the application exactly what to do
(since that's application specific) while at the same time
specifying a generic extension. (I think this is the nub of
what we're discussing.)

If there is a way, then I'm all for adding such text. I do agree
that there needs to be some text saying that if you do make use of
the linkage, then you need to be aware of various security
considerations (e.g. if an old private key were liable to be
leaked) and possible application gotchas (e.g. name changes).

If there isn't then we either kill the idea, or else have to
go with an application-specific extension, which is much less
interesting (I reckon), since I'd argue that the same problem
will arise in many applications. Basically, anyone who wants
to change things at cert renewal time but where there's
existing application state tied to the old cert.

I also reckon that this extension could be useful in load
balancing situations, though I guess one could well argue
that that's sufficiently different and can be handled via
wildcards (or handled well enough).

> Then let's have CAs contribute to the discussion and say what they would
> do with the extension, and how they want RPs to process it.

Yes, I think this is only interesting if there's a real chance that
it'll be used. Otherwise, we can just let it wither away... (I've
had a couple of "hmm, interesting..." type mails off-list, but no
more than that.)

Maybe the thing to do is to put this on the agenda next time to
see if it gets more than a few scattered yawns? If so, I guess
I can try do up a -01 before then reflecting this thread.

Cheers,
S.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Jan 2008 15:12:10 -0500

Steve,

If you have time to generate a 01 draft that tries to address the 
concerns I raised, then we can put this on the agenda for March.

Steve

---

From: Michael Ströder <[email-masked]>
Date: Wed, 09 Jan 2008 13:51:43 +0100

Stephen Kent wrote:
> 
> If this extension is intended to solve a specific problem in this
> realm, then we need to be precise in describing what the problem is,
> and how this extension solves it. I am not comfortable defining an
> extension for which we do not do this.

I concur! The abstract of the draft is pretty sparse regarding the 
motivation for such an extension.

Such a "link" would be a relation between certs. Without specifying the 
relation how can you tell the characteristics of such relation (e.g. R 
being transitive)?
=> I doubt that a simple reference will do for real-world problems.

Ciao, Michael.

-- 
Michael Ströder
E-Mail: [email-masked]
http://www.stroeder.com