[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)