Re: New other certs extension I-D
Stephen Kent <kent <at> bbn.com>
2008-01-02 18:40:27 GMT
At 10:53 PM +0000 12/21/07, stephen.farrell <at> cs.tcd.ie wrote:
>> 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.
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.