[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IETF-PKIX] NO SUBJECT



-----Original Message-----
From: Mack Hicks <Mack.Hicks@BANKAMERICA.COM>
To: IETF-PKIX@LISTS.TANDEM.COM <IETF-PKIX@LISTS.TANDEM.COM>
Date: Thursday, 18 December 1997 8:24
Subject: [IETF-PKIX] NO SUBJECT


:For: IETF-PKIX Mailing list
:
:From: "Russ Housley"<housley@spyrus.com>
:
:> Mike:
:>
:>This is not necessarily so.  The use of extensions can limit the scope of
:>the "tree" that becomes valid as a result of cross-certification.  For
:>example, name constraints could result in a small subset of the
:>certificates issued by a CA being considered valid in the context path
that
:>includes a cross certificate.
:>
:>Russ
:
:Russ,
:
:I have to voice my agreement with Mike that cross-certification
:is not manageable (technical banking term - "scary".))

I also have to agree.

Within closed communities such as the postal communities and others this can
be usefull.

Within open, communities, one has to understand the business need, its not a
technical issue (anyones technology will do this after all its only a
cert?).

snip
:Cross certification may look OK to field commanders in military
:applications.  Ya know -"Well that's Sam's group - he and I
:played hockey together - Let's trust those guys."

I see this as another example of a closed community.

snip
:
:So, for financial transactions, we are left with on-line status
:verification.  Is there any bank out there that wants to cross
:certify? With whom?

In the end of the day the relying party will make the trust decision, and
technical Xcert solutions dont realy help this decision.




Content-Type: application/x-pkcs7-signature;
        name="smime.p7s"
Content-Disposition: attachment;
        filename="smime.p7s"

Attachment converted: Lutefisk:smime.p7s 1 (????/----) (0001DD70)