ur desision may be depend from:
1 -- u had to declare FK on child table
2 -- u didn't declare FK constraint, and use "logical FK constraints" on application level.
------------------------------------------------------------------
in first case better has
-- 2 indexes on child table (PK index and FK index)
in second case may be (but not always) better has
-- composit index that has first fields are equal filelds from PK of parent table.
------------------------------------------------------------------
Problem with perfomance on FK are
-- locks on chaid table(s) when u update/delete rows from parent table.
if u haven't any indexes on FK fields of the child table(s) and declare FK constraint
oracle have to inmpement locks to all rows from child table
(see Tom Kyte "deadlocks" and "indexes on fk")

about 1 or 2 indexes on child tabe:
if u have PK constraint, that not include any fields from FK constraint
and u going to add FK fiels to composit of PK index u:
-- if u place FK fields last, then oracle probably cant use this index
with update/delete operation on a paret table.
-- if u place FK fields first, then ur PK B+ index will be not so good
balanced, as with PK fields only.

This is reason why i gess to have 2 indexes.