Subject: Re: [IETF-PKIX] Key Usage
From: Bob Jueneman <[email-masked]>
To: [email-masked]
Date: Fri, 30 Jan 1998 16:17:45 -0700

I think we agree in spirit, but the devil is in the details

>From the standpoint of the export police, everything that is not
explicitly allowed is forbidden, so saying something is meaningless
doesn't quite go far enough. "Meaningless" doesn't imply "forbidden",
but perhaps it should, at least with respect to compliance with current
US export law and the import/usage laws of some countries as well.

I really wasn't thinking about turnign on say Encipher Only and
Digital Signature in the same key usage flag -- I was more concerned that
turning on Digital Signaturedidn't necessarily turn off Encipher.

Since turning on nothing and/or leaving the key usage flag out
entirely is pemitted, it is a little hard to argue that turning on one
bit (Digital Signature) suddenly means that something that was
permitted previously (Encipher) is no longer permitted.

Conformance with X.509 really isn't the issue, it is conformance
with the export/import guidleines.

I want to think just a lttle bit more about it, but at present I believe
the Critical flag is not particularly germane to the argument --
neither the subject nor the CA care particularly what use the recipient
makes of the public key, unless the subject would not be able to
decrypt a message sent to him using a public key that
was limited to being used for signature validation. But a country with
a usage constraint, e.g., France, might care.

One example of where public key encryption is used without
keyAgreement being set is in the SET protocol, where the account
number is encrypted directly using strong RSA encryption and a 56-bit
DES key is also encrypted -- i.e., a mixed usage.  The SET designers
had to get a special exemption for that usage, and were succesful
only because of the overall system context.

Bob

>>> Simonetti David <[email-masked]> 01/30 11:22 AM >>>
Let me take that back...

If I were designing an application, my application would only look for
the encipherOnly and decipherOnly key usages if the keyAgreement bit was
set.  I would only be looking for the keyAgreement bit if I was
attempting to execute a key agreement.

Thus, assuming a critical Key Usage extension, my application should not
allow any form of encryption-type processing unless either the
keyEncipherment bit or keyAgreement bit is set.  Then, the statement in
X.509 of the bits being meaningless with usages other than keyAgreement
is quite accurate.  Having them set with digitalSignature would not mean
anything; they would be ignored, and as long as keyAgreement or
keyEncipherment is not set, the key could never be used for encryption
purposes (assuming X.509-compliance).

Dave S.

Simonetti David wrote:
>
> Bob,
>
> X.509 defines encipherOnly and decipherOnly to be meaningful only when
> used with keyAgreement, and states "meaning with other key usage bit set
> is undefined".  I read into this as:  using these two key usages with
> any bit other than keyAgreement set is an invalid use resulting in
> certificate rejection.
>
> Dave S.
>
> Bob Jueneman wrote:
> >
> > Dave, that makes sense.
> >
> > But I would like to further clarify within your paragraph the distinction between
> > Encipher Only or Decipher Only (with or without key agreement), and Digital
> > Signature (with or without Nonrepudiation).
> >
> > In order to obtain a more enlightened approach to export controls, applications
> > and operating systems would like to enforce key usages so that a public key
> > that is intended to used to validate a digital signature cannot be used to
> > encrypt data, either directly, or via a key exchange key.
> >
> > Ideally, the combination of Encipher Only with either Digital Signature or
> > Nonrepudiation should be made an invalid state.  It would be interesting to
> > know if any existing protocols would break in that case.  If that isn't
> > acceptable, the next best thing would be for PKIX  to deprecate such a
> > usage, but that might not be acceptable either. At a minimum, however, we
> > ought to point out the potentially unfavorable export treatment any application
> > making use of such a key usage would receive. The combination of
> > Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.
> >
> > Of course keys that don't have any restrictive key usages will receive the
> > most general, i.e., from an export considerations standpoint, most restrictive
> > treatment, and that probably ought to be pointed out as well.
> >
> > Bob
> >
> > >Tim,
> > >
> > >I have proposed the following text be added to the profile to further
> > >clarify these two key usages.  I don't know whether or not my proposal
> > >was accepted.  I truely believe this text should be added to X.509.
> > >
> > >"The encipherOnly and decipherOnly key usages are intended to provide
> > >support for key agreement schemes where separate shared secret keys are
> > >used in each direction of communication.  In such a scheme, a user has
> > >more than one set of key pairs and bits 7 (encipherOnly) and 8
> > >(decipherOnly) are used to distinguish between the two types.  The
> > >originator of a message would use the recipient's public key certificate
> > >with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
> > >encryption key.  The recipient would use the originator's certificate
> > >with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
> > >encryption key.  Typically the originator would pass his or her own
> > >certificate with bits 4 and 8 along with the message."
> > >
> > >Regards,
> > >
> > >Dave S.
> > >
> > >Tim Dierks wrote:
> > >>
> > >> Could someone explain to me what the following paragraph means (section
> > >> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
> > >>
> > >>       When the decipherOnly bit is asserted and the keyAgreement bit is
> > >>       also set, the subject public key may be used only for deciphering
> > >>       data while performing key agreement.  The meaning of the
> > >>       decipherOnly bit is undefined in the absence of the keyAgreement
> > >>       bit.
> > >>
> > >> When would one use a public key to decipher a key agreement? Does this have
> > >> something to do with signatures? Whats more, I thought key agreement
> > >> referred to Diffie-Hellman and similar algorithms, which I don't easily
> > >> conceive of as doing signatures or encipherment. What's up?
> > >>
> > >> Thanks,
> > >>  - Tim
> > >>
> > >> Tim Dierks - [email-masked] - www.consensus.com
> > >>   Director of Engineering - Consensus Development
> > >>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Hal Lockhart <[email-masked]>
Date:         Fri, 30 Jan 1998 16:56:38 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] draft question
To: [email-masked]
Status:

At 12:19 PM 1/30/98 -0500, Gina DePlanche wrote:
>        I have a question regarding section 7.2.1 of the internet draft
>X.509 Certificate and CRL Profile (draft-ietf-pkix-ipki-part1-06.txt)
>
>        This section discusses using RSA with MD2, MD5 or SHA-1.
>
>        My question is regarding the RSA portion. My understanding is
>that RSA has 2 algorithms: RC4-40 and RC4-128. Is this the RSA section
>7.2.1 is referring to?

No.

RSA refers to the RSA public key algorithm, the patent to which is held by
RSA Data Security Inc. (RSADSI).  RSADSI also holds intellectual property
rights to a number of other algorithms, including the RC4 secret key
algorithm.

Other than their common origin, there is no relationship between RSA and RC4.

Regards,

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum technology, Solutions
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Approved-By: [email-masked]
Date:         Fri, 30 Jan 1998 12:19:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] draft question
To: [email-masked]
Status:

        I have a question regarding section 7.2.1 of the internet draft
X.509 Certificate and CRL Profile (draft-ietf-pkix-ipki-part1-06.txt)

        This section discusses using RSA with MD2, MD5 or SHA-1.

        My question is regarding the RSA portion. My understanding is
that RSA has 2 algorithms: RC4-40 and RC4-128. Is this the RSA section
7.2.1 is referring to? If so, how are the two algorithms distinguished
from the one object identifier (eg. md5WithRSAEncryption)?

        If I'm way off base, could someone please point me in the right
direction?

        Thanks for the help!

        - Gina

--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Approved-By:  Simonetti David <[email-masked]>
Date:         Fri, 30 Jan 1998 13:22:24 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Key Usage
To: [email-masked]
Status:

Let me take that back...

If I were designing an application, my application would only look for
the encipherOnly and decipherOnly key usages if the keyAgreement bit was
set.  I would only be looking for the keyAgreement bit if I was
attempting to execute a key agreement.

Thus, assuming a critical Key Usage extension, my application should not
allow any form of encryption-type processing unless either the
keyEncipherment bit or keyAgreement bit is set.  Then, the statement in
X.509 of the bits being meaningless with usages other than keyAgreement
is quite accurate.  Having them set with digitalSignature would not mean
anything; they would be ignored, and as long as keyAgreement or
keyEncipherment is not set, the key could never be used for encryption
purposes (assuming X.509-compliance).

Dave S.

Simonetti David wrote:
>
> Bob,
>
> X.509 defines encipherOnly and decipherOnly to be meaningful only when
> used with keyAgreement, and states "meaning with other key usage bit set
> is undefined".  I read into this as:  using these two key usages with
> any bit other than keyAgreement set is an invalid use resulting in
> certificate rejection.
>
> Dave S.
>
> Bob Jueneman wrote:
> >
> > Dave, that makes sense.
> >
> > But I would like to further clarify within your paragraph the distinction between
> > Encipher Only or Decipher Only (with or without key agreement), and Digital
> > Signature (with or without Nonrepudiation).
> >
> > In order to obtain a more enlightened approach to export controls, applications
> > and operating systems would like to enforce key usages so that a public key
> > that is intended to used to validate a digital signature cannot be used to
> > encrypt data, either directly, or via a key exchange key.
> >
> > Ideally, the combination of Encipher Only with either Digital Signature or
> > Nonrepudiation should be made an invalid state.  It would be interesting to
> > know if any existing protocols would break in that case.  If that isn't
> > acceptable, the next best thing would be for PKIX  to deprecate such a
> > usage, but that might not be acceptable either. At a minimum, however, we
> > ought to point out the potentially unfavorable export treatment any application
> > making use of such a key usage would receive. The combination of
> > Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.
> >
> > Of course keys that don't have any restrictive key usages will receive the
> > most general, i.e., from an export considerations standpoint, most restrictive
> > treatment, and that probably ought to be pointed out as well.
> >
> > Bob
> >
> > >Tim,
> > >
> > >I have proposed the following text be added to the profile to further
> > >clarify these two key usages.  I don't know whether or not my proposal
> > >was accepted.  I truely believe this text should be added to X.509.
> > >
> > >"The encipherOnly and decipherOnly key usages are intended to provide
> > >support for key agreement schemes where separate shared secret keys are
> > >used in each direction of communication.  In such a scheme, a user has
> > >more than one set of key pairs and bits 7 (encipherOnly) and 8
> > >(decipherOnly) are used to distinguish between the two types.  The
> > >originator of a message would use the recipient's public key certificate
> > >with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
> > >encryption key.  The recipient would use the originator's certificate
> > >with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
> > >encryption key.  Typically the originator would pass his or her own
> > >certificate with bits 4 and 8 along with the message."
> > >
> > >Regards,
> > >
> > >Dave S.
> > >
> > >Tim Dierks wrote:
> > >>
> > >> Could someone explain to me what the following paragraph means (section
> > >> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
> > >>
> > >>       When the decipherOnly bit is asserted and the keyAgreement bit is
> > >>       also set, the subject public key may be used only for deciphering
> > >>       data while performing key agreement.  The meaning of the
> > >>       decipherOnly bit is undefined in the absence of the keyAgreement
> > >>       bit.
> > >>
> > >> When would one use a public key to decipher a key agreement? Does this have
> > >> something to do with signatures? Whats more, I thought key agreement
> > >> referred to Diffie-Hellman and similar algorithms, which I don't easily
> > >> conceive of as doing signatures or encipherment. What's up?
> > >>
> > >> Thanks,
> > >>  - Tim
> > >>
> > >> Tim Dierks - [email-masked] - www.consensus.com
> > >>   Director of Engineering - Consensus Development
> > >>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Simonetti David <[email-masked]>
Date:         Fri, 30 Jan 1998 12:55:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Key Usage
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

Bob,

X.509 defines encipherOnly and decipherOnly to be meaningful only when
used with keyAgreement, and states "meaning with other key usage bit set
is undefined".  I read into this as:  using these two key usages with
any bit other than keyAgreement set is an invalid use resulting in
certificate rejection.

Dave S.

Bob Jueneman wrote:
>
> Dave, that makes sense.
>
> But I would like to further clarify within your paragraph the distinction between
> Encipher Only or Decipher Only (with or without key agreement), and Digital
> Signature (with or without Nonrepudiation).
>
> In order to obtain a more enlightened approach to export controls, applications
> and operating systems would like to enforce key usages so that a public key
> that is intended to used to validate a digital signature cannot be used to
> encrypt data, either directly, or via a key exchange key.
>
> Ideally, the combination of Encipher Only with either Digital Signature or
> Nonrepudiation should be made an invalid state.  It would be interesting to
> know if any existing protocols would break in that case.  If that isn't
> acceptable, the next best thing would be for PKIX  to deprecate such a
> usage, but that might not be acceptable either. At a minimum, however, we
> ought to point out the potentially unfavorable export treatment any application
> making use of such a key usage would receive. The combination of
> Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.
>
> Of course keys that don't have any restrictive key usages will receive the
> most general, i.e., from an export considerations standpoint, most restrictive
> treatment, and that probably ought to be pointed out as well.
>
> Bob
>
> >Tim,
> >
> >I have proposed the following text be added to the profile to further
> >clarify these two key usages.  I don't know whether or not my proposal
> >was accepted.  I truely believe this text should be added to X.509.
> >
> >"The encipherOnly and decipherOnly key usages are intended to provide
> >support for key agreement schemes where separate shared secret keys are
> >used in each direction of communication.  In such a scheme, a user has
> >more than one set of key pairs and bits 7 (encipherOnly) and 8
> >(decipherOnly) are used to distinguish between the two types.  The
> >originator of a message would use the recipient's public key certificate
> >with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
> >encryption key.  The recipient would use the originator's certificate
> >with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
> >encryption key.  Typically the originator would pass his or her own
> >certificate with bits 4 and 8 along with the message."
> >
> >Regards,
> >
> >Dave S.
> >
> >Tim Dierks wrote:
> >>
> >> Could someone explain to me what the following paragraph means (section
> >> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
> >>
> >>       When the decipherOnly bit is asserted and the keyAgreement bit is
> >>       also set, the subject public key may be used only for deciphering
> >>       data while performing key agreement.  The meaning of the
> >>       decipherOnly bit is undefined in the absence of the keyAgreement
> >>       bit.
> >>
> >> When would one use a public key to decipher a key agreement? Does this have
> >> something to do with signatures? Whats more, I thought key agreement
> >> referred to Diffie-Hellman and similar algorithms, which I don't easily
> >> conceive of as doing signatures or encipherment. What's up?
> >>
> >> Thanks,
> >>  - Tim
> >>
> >> Tim Dierks - [email-masked] - www.consensus.com
> >>   Director of Engineering - Consensus Development
> >>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 30 Jan 1998 09:54:46 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Usage
Comments: To: [email-masked]
To: [email-masked]
Status:

Dave, that makes sense.

But I would like to further clarify within your paragraph the distinction between
Encipher Only or Decipher Only (with or without key agreement), and Digital
Signature (with or without Nonrepudiation).

In order to obtain a more enlightened approach to export controls, applications
and operating systems would like to enforce key usages so that a public key
that is intended to used to validate a digital signature cannot be used to
encrypt data, either directly, or via a key exchange key.

Ideally, the combination of Encipher Only with either Digital Signature or
Nonrepudiation should be made an invalid state.  It would be interesting to
know if any existing protocols would break in that case.  If that isn't
acceptable, the next best thing would be for PKIX  to deprecate such a
usage, but that might not be acceptable either. At a minimum, however, we
ought to point out the potentially unfavorable export treatment any application
making use of such a key usage would receive. The combination of
Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.

Of course keys that don't have any restrictive key usages will receive the
most general, i.e., from an export considerations standpoint, most restrictive
treatment, and that probably ought to be pointed out as well.

Bob

>Tim,
>
>I have proposed the following text be added to the profile to further
>clarify these two key usages.  I don't know whether or not my proposal
>was accepted.  I truely believe this text should be added to X.509.
>
>"The encipherOnly and decipherOnly key usages are intended to provide
>support for key agreement schemes where separate shared secret keys are
>used in each direction of communication.  In such a scheme, a user has
>more than one set of key pairs and bits 7 (encipherOnly) and 8
>(decipherOnly) are used to distinguish between the two types.  The
>originator of a message would use the recipient's public key certificate
>with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
>encryption key.  The recipient would use the originator's certificate
>with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
>encryption key.  Typically the originator would pass his or her own
>certificate with bits 4 and 8 along with the message."
>
>Regards,
>
>Dave S.
>
>Tim Dierks wrote:
>>
>> Could someone explain to me what the following paragraph means (section
>> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
>>
>>       When the decipherOnly bit is asserted and the keyAgreement bit is
>>       also set, the subject public key may be used only for deciphering
>>       data while performing key agreement.  The meaning of the
>>       decipherOnly bit is undefined in the absence of the keyAgreement
>>       bit.
>>
>> When would one use a public key to decipher a key agreement? Does this have
>> something to do with signatures? Whats more, I thought key agreement
>> referred to Diffie-Hellman and similar algorithms, which I don't easily
>> conceive of as doing signatures or encipherment. What's up?
>>
>> Thanks,
>>  - Tim
>>
>> Tim Dierks - [email-masked] - www.consensus.com
>>   Director of Engineering - Consensus Development
>>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Richard Salz <[email-masked]>
Date:         Fri, 30 Jan 1998 09:39:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Richard Salz <[email-masked]>
Subject:      [IETF-PKIX] Please, enough linebreak discussion
To: [email-masked]
Status:

If you want the MIME WG's, you know where to find them. :)

Look, Bob Juenemann once again is having problems sending out well-formed
messages.  Messages should be word-wrapped between 72 and 78 columns,
or use a fancier mime type.  The latter isn't happening and the author
apparently finds it too tedious to do the former.  Seems to me the tradeoff
is pretty simple -- inconvenience one person, or inconvenience many
potential readers.  (No real skin off my nose, I can just delete them
without bothering to read past the first screenful of ugliness.)

I didn't know MIME was a pre-requisite for participating here.  Did I
miss something?
        /r$

Approved-By:  Simonetti David <[email-masked]>
Date:         Fri, 30 Jan 1998 09:26:59 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Key Usage
To: [email-masked]
Status:

Tim,

I have proposed the following text be added to the profile to further
clarify these two key usages.  I don't know whether or not my proposal
was accepted.  I truely believe this text should be added to X.509.

"The encipherOnly and decipherOnly key usages are intended to provide
support for key agreement schemes where separate shared secret keys are
used in each direction of communication.  In such a scheme, a user has
more than one set of key pairs and bits 7 (encipherOnly) and 8
(decipherOnly) are used to distinguish between the two types.  The
originator of a message would use the recipient's public key certificate
with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
encryption key.  The recipient would use the originator's certificate
with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
encryption key.  Typically the originator would pass his or her own
certificate with bits 4 and 8 along with the message."

Regards,

Dave S.

Tim Dierks wrote:
>
> Could someone explain to me what the following paragraph means (section
> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
>
>       When the decipherOnly bit is asserted and the keyAgreement bit is
>       also set, the subject public key may be used only for deciphering
>       data while performing key agreement.  The meaning of the
>       decipherOnly bit is undefined in the absence of the keyAgreement
>       bit.
>
> When would one use a public key to decipher a key agreement? Does this have
> something to do with signatures? Whats more, I thought key agreement
> referred to Diffie-Hellman and similar algorithms, which I don't easily
> conceive of as doing signatures or encipherment. What's up?
>
> Thanks,
>  - Tim
>
> Tim Dierks - [email-masked] - www.consensus.com
>   Director of Engineering - Consensus Development
>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  "Phillip H. Griffin" <[email-masked]>
Date:         Fri, 30 Jan 1998 08:42:04 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Doug Beattie wrote:
>
> I use Outlook and it looks fine.  I POP my mail off of a POP mail server, not through the Exchange mail server at GTE.  Maybe that makes some difference.
>
> Doug

Maybe. I must select "Wrap long lines" on the "View" pull down
menu of the Netscape 3.0 action bar to force your one line to
display properly as formatted multiple lines. Notice that when
using "Reply to all", that your one line has but a single ">"
in front of "I". Not sure what it looks like when you get it.

Phil

Approved-By:  Doug Beattie <[email-masked]>
Date:         Fri, 30 Jan 1998 08:02:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Doug Beattie <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

I use Outlook and it looks fine.  I POP my mail off of a POP mail server, not through the Exchange mail server at GTE.  Maybe that makes some difference.

Doug

-----Original Message-----
From:   Bob Jueneman [SMTP:[email-masked]]
Sent:   Wednesday, January 28, 1998 9:48 PM
To:     [email-masked]
Subject:        Re: [IETF-PKIX] Line break problem

Thanks, Sam, but I have received a sufficient number of
responses from people using Eudora, Microsoft Outlook,
elm, pine, and other programs to convince me that the problem
is at my end.  Until we can resolve the problem, I guess I'll have
to go back to using manual carriage returns.

Thanks for the feedback, people, and my apologies for wasting
your time and bandwidth.

Bob
>
>
>>>> Sam Schaen <[email-masked]> 01/28 8:44 PM >>>
>In Communicator 4.0x, there is a "wrap long lines" option that needs to be checked to avoid
>the problem described.

Approved-By: [email-masked]
Date:         Thu, 29 Jan 1998 07:55:52 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Bob:

Groupwise wrapped it just fine.

Michael

>>> Bob Jueneman <[email-masked]> 01/28/98 05:05PM >>>
Two people have recently complained that my messages create line lengths
that are too long, and hard to read. This used to be a problem with GroupWise,
and I had to manually insert line breaks, but the problem was solved some time ago
at our gateway.

So either it is back, or something else is going on.

So far, the two people that have complained are using NetScape Communicator, and
both are outside the US, which makes me wonder whether there is a NetScape (export-version) problem.

So let me test this. This paragraph is written as one long line, and should be automatically line wrapped and broken. If it is not, and if you are using anything other than Communicator please let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send me mail for the same problem.)

Likewise, if someone is using Netscape Communicator 3.01 in a non-US version who is NOT having any particular difficulty reading this paragraph, please let me know as well.

I'd like to fix it, but don't know what's wrong.

Bob
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By:  Tim Dierks <[email-masked]>
Date:         Thu, 29 Jan 1998 17:15:49 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject:      [IETF-PKIX] Key Usage
To: [email-masked]
Status:

Could someone explain to me what the following paragraph means (section
4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?

      When the decipherOnly bit is asserted and the keyAgreement bit is
      also set, the subject public key may be used only for deciphering
      data while performing key agreement.  The meaning of the
      decipherOnly bit is undefined in the absence of the keyAgreement
      bit.

When would one use a public key to decipher a key agreement? Does this have
something to do with signatures? Whats more, I thought key agreement
referred to Diffie-Hellman and similar algorithms, which I don't easily
conceive of as doing signatures or encipherment. What's up?

Thanks,
 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

From: [email-masked]
Date: Fri, 30 Jan 1998 2:15:39 +0000
To: [email-masked]
Cc: [email-masked]
Subject: TLS Extended Key Usage
Status:

####################################################
This message was not delivered to
[email-masked] 
TFS Admin was informed with a copy of this message
Sender was informed with a copy of this message
####################################################
I'd like to suggest that the word "Web" be stricken from the following
descriptions (in section 4.2.1 of draft-ietf-pkix-ipki-part1-06.txt), as
HTTP and the WWW is only one of many uses for TLS.

   id-kp-serverAuth              OBJECT IDENTIFIER ::=   {id-kp 1}
   -- TLS Web server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   --                         keyEncipherment or keyAgreement
   --
   id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}
   -- TLS Web client authentication
   -- Key usage bits that may be consistent: digitalSignature and/or
   --                            keyAgreement
   --

Thanks,

 - Tim Dierks

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By: [email-masked]
Date:         Thu, 29 Jan 1998 15:57:34 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject:      [IETF-PKIX] TLS Extended Key Usage
Comments: cc: "ietf-tls (Transport Layer Security WG)" <[email-masked]>
To: [email-masked]
Status:

I'd like to suggest that the word "Web" be stricken from the following
descriptions (in section 4.2.1 of draft-ietf-pkix-ipki-part1-06.txt), as
HTTP and the WWW is only one of many uses for TLS.

   id-kp-serverAuth              OBJECT IDENTIFIER ::=   {id-kp 1}
   -- TLS Web server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   --                         keyEncipherment or keyAgreement
   --
   id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}
   -- TLS Web client authentication
   -- Key usage bits that may be consistent: digitalSignature and/or
   --                            keyAgreement
   --

Thanks,

 - Tim Dierks

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 29 Jan 1998 14:14:59 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

At 01:37 PM 1/29/98 -0500, David P. Kemp wrote:
>That is an example of where the "gotcha" rule on IMPLICIT tagging
>applies :-)
>
>X.680 section 28.6:

Um, we're not using X.680, we're using X.208. Is that what X.208 says as well?

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 29 Jan 1998 13:37:41 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

> From: Nilsson Hans <[email-masked]>
>
> I think there are some errors on page 107 and 108 in the PKIX-1 draft
> for the coding of the subjectAltName:
>
> Where it says
> rfc822name
> a1 1a
> IA5String
> 16 18 65 73 65..
>
> it should read
>
> rfc822name
> 81 18
> 65 73 65...
>
> since the Certificate Extensions module specifies IMPLICIT tage. Hence
> IMPLICIT tags must be used for selecting the rfc822name choice in the
> subjectAltName extension
>
> The same error then also exists for the uniformResourceIdentifier, a6 16
> 16 14 68... when then should read
> 86 14 68...
>
> Can please some ASN.1/DER expert confirm or prove me wrong?
>
> Hans Nilsson
> AU-System, Stockholm, Sweden

That is an example of where the "gotcha" rule on IMPLICIT tagging
applies :-)

X.680 section 28.6:

  The tagging construction specifies explict tagging if any of the
  following holds:
    a) ..
    b) ..
    c) the "Tag Type" alternative is used an the value of TagDefault for
       the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
       defined by "Type" is a choice type, open type, or a DummyReference.

so even in an IMPLICIT TAGS module, GeneralName (a CHOICE) is encoded
using explicit tagging, as shown in the PKIX-1 example.

Approved-By:  Tolga Acar <[email-masked]>
Date:         Thu, 29 Jan 1998 13:16:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tolga Acar <[email-masked]>
Subject:      Re: [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

-- Tolga

>>> Nilsson Hans <[email-masked]> 1/29/98 10:26:43 >>>
>Where it says
>rfc822name
>a1 1a
>IA5String
>16 18 65 73 65..

>it should read

>rfc822name
>81 18
>65 73 65...

This seems fine to me, though i'm not an expert.
a1 stands for "context-specific 1' and '1a' is the length of the underlying item, i.e., IA5String. Thus, IMPLICIT tagging used, where the underlying tag is IA5String, and the derived tag is 'context-specific [1]'.
Similar thing goes for the second argument --- uniformResourceIdentifier.
So, this should read:
subjectAltNameValue := SEQUENCE {
    rfc822name                        [1] IA5String,  -- "escert....." of length 1a octets
    uniformResourceIdentifier   [6] IA5String   -- "http:...." of length 16 octets }

>since the Certificate Extensions module specifies IMPLICIT tage. Hence
>IMPLICIT tags must be used for selecting the rfc822name choice in the
>subjectAltName extension

Approved-By:  Nilsson Hans <[email-masked]>
Date:         Thu, 29 Jan 1998 18:26:43 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nilsson Hans <[email-masked]>
Subject:      [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

I think there are some errors on page 107 and 108 in the PKIX-1 draft
for the coding of the subjectAltName:

Where it says
rfc822name
a1 1a
IA5String
16 18 65 73 65..

it should read

rfc822name
81 18
65 73 65...

since the Certificate Extensions module specifies IMPLICIT tage. Hence
IMPLICIT tags must be used for selecting the rfc822name choice in the
subjectAltName extension

The same error then also exists for the uniformResourceIdentifier, a6 16
16 14 68... when then should read
86 14 68...

Can please some ASN.1/DER expert confirm or prove me wrong?

Hans Nilsson
AU-System, Stockholm, Sweden

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 29 Jan 1998 10:14:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
Comments: To: [email-masked]
To: [email-masked]
Status:

David, there seem to be two problems going on, and it is affecting more than just a few people.

First, something has apparently happened to our mail gateway, which used to insert carriage returns on outgoing Internet mail. I'm trying to find out what happened, and get it fixed.

Second, it appears that people using Netscape Communicator (and/or some other programs) may not be aware of the automatic line wrap capability it apparently has, or haven't turned it on.

This whole problem is of course a very irritating example of incompatible standards and approaches.  From my perspective, I would greatly prefer to control my own line wrapping, by resizing the display window and choosing the default font however I like, rather than being at the mercy of someone else's notion of what screen size and resolution looks nice.  I hate it when people write messages using little tiny lines, tiny little fonts, or great big fonts for that matter -- it's too hard to read. I also hate it when lines that were automatically broken neatly now roll over to the next line because of the line quoting conventions. Seems to me that we should have gotten away from 80 column cards and 72 column Fortran lines a long, long time ago -- I'll bet that a some of the people reading this list may never have even seen a punched card!

>From my perspective, I would  prefer to use a single > character at the beginning of the _paragraph_ to indicate quoted text, and let the line wrapping flow naturally at the _recipient's_ end. But a substantial percentage of the Internet community doesn't seem to see it that way, and I can't roll that stone up the hill by myself.

All I know is that life is too short to spend it manually inserting carriage returns after every so many characters, so I have to solve the problem somehow. Maybe we should all go back to using typewriters with little bells, and a carriage return bar that has to be thrown at the end of the line.  It would probably improve my right arm's muscle tone, too!

I promise this is last message on this topic to this list.

Bob

>>>> David P. Kemp <[email-masked]> 01/29 8:51 AM >>>
>>
>> So far, the two people that have complained are using NetScape Communicator, and
>> both are outside the US, which makes me wonder whether there is a NetScape (export-
>version) problem.
>>
>> So let me test this. This paragraph is written as one long line, and should be automatically line
>wrapped and broken. If it is not, and if you are using anything other than Communicator please
>let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send
>me mail for the same problem.)
>>
>
>Bob,
>  I'm using the Sun mail tool on a Solaris system, and your messages
>come through without line breaks.  It's easy enough to fix, since
>all Sun text windows have a "format" option that wraps at 72 characters.
>
>As you see above from the inclusion characters (>), your message had
>line breaks before:
>
> > So far, ..
> > both are outside the US ...
> >
> > So let me test this ...
>
>and that last paragraph is one long line.
>
>Regards,
> dpk

Approved-By:  Nilsson Hans <[email-masked]>
Date:         Thu, 29 Jan 1998 18:19:30 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nilsson Hans <[email-masked]>
Subject:      [IETF-PKIX] Calculation of Subjet Key Identifier
To: [email-masked]
Status:

In PKIX-1, 4.2.1.2 it is stated that:

"The hash shall be calculated over the value (excluding tag and length)
of the subject public key field in the certificate."

I have been told that there is a recommendation by Netscape that the
SHA-1 digest shall be computed over the full DER-encoded
SubjectPublicKeyInfo value, i.e. including the SEQUENCE tag, length,
AlgorithmIdentifier and SubjectKey.

Could someone please clarify and tell what the "common practice" is?

Hans Nilsson
AU-System
Stockholm, Sweden

Approved-By:  Santoni Adriano <[email-masked]>
Date:         Thu, 29 Jan 1998 09:12:00 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] R: [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

Thank you.
  Adriano

> -----Messaggio originale-----
> Da:   Mark Shuttleworth [SMTP:[email-masked]]
> Inviato:      mercoled“ 28 gennaio 1998 18.09
> A:    [email-masked]
> Oggetto:      Re: [IETF-PKIX] Character sets definitions/descriptions:
> where             online?
>
> > Anybody wants to kindly point me to some site(s) where the exact and
> > clear description of the character sets PrintableString,
> VisibleString,
> > TeletexString (or T61String), IA5String, BMPString...and such, can
> be
> > found?
>
> ISO water torture, as Peter Gutmann puts it ;)
>
> Best place I've found is his X.509 Style Guide, which you can get to
> from
> his collection of security links:
>
>   http://www.cs.auckland.ac.nz/~pgut001/links.html
>
> Now bear in mind that asking for an "exact and clear" description of
> something as painful as your chosen topic of enquiry is like asking
> for
> enjoyable dentistry.  But at least it's an interesting read.
>
> --
> Mark Shuttleworth
> Thawte Consulting

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 28 Jan 1998 19:47:34 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
Comments: To: [email-masked]
To: [email-masked]
Status:

Thanks, Sam, but I have received a sufficient number of
responses from people using Eudora, Microsoft Outlook,
elm, pine, and other programs to convince me that the problem
is at my end.  Until we can resolve the problem, I guess I'll have
to go back to using manual carriage returns.

Thanks for the feedback, people, and my apologies for wasting
your time and bandwidth.

Bob
>
>
>>>> Sam Schaen <[email-masked]> 01/28 8:44 PM >>>
>In Communicator 4.0x, there is a "wrap long lines" option that needs to be checked to avoid
>the problem described.

Approved-By:  "H. Richard Schwarz" <[email-masked]>
Date:         Wed, 28 Jan 1998 20:58:15 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "H. Richard Schwarz" <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Sam,

I tried this option at 72 characters and cannot get it to work. The
lines still string well beyone the page boundaries on the screen. Any
ideas?

Dick Schwarz

Sam Schaen wrote:

> In Communicator 4.0x, there is a "wrap long lines" option that needs
> to be checked to avoid the problem described.
>
> Bob Jueneman wrote:
>
> > Two people have recently complained that my messages create line
> lengths
> > that are too long, and hard to read. This used to be a problem with
> GroupWise,
> > and I had to manually insert line breaks, but the problem was solved
> some time ago
> > at our gateway.
> >
> > So either it is back, or something else is going on.
> >
> > So far, the two people that have complained are using NetScape
> Communicator, and
> > both are outside the US, which makes me wonder whether there is a
> NetScape (export-version) problem.
> >
> > So let me test this. This paragraph is written as one long line, and
> should be automatically line wrapped and broken. If it is not, and if
> you are using anything other than Communicator please let me know. (I
> would suggest that you copy the list, so that umpty-thousand people
> don't send me mail for the same problem.)
> >
> > Likewise, if someone is using Netscape Communicator 3.01 in a non-US
> version who is NOT having any particular difficulty reading this
> paragraph, please let me know as well.
> >
> > I'd like to fix it, but don't know what's wrong.
> >
> > Bob

Approved-By:  "H. Richard Schwarz" <[email-masked]>
Date:         Wed, 28 Jan 1998 20:52:59 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "H. Richard Schwarz" <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Bob,

This is a problem that I have been noticing more often lately. I am
using the U.S. version of NetScape Communicator Version 4.01a. Yes
indeed, it is a problem - but not just with email received from you or
this group.

Dick Schwarz

Bob Jueneman wrote:

> Two people have recently complained that my messages create line
> lengths
> that are too long, and hard to read. This used to be a problem with
> GroupWise,
> and I had to manually insert line breaks, but the problem was solved
> some time ago
> at our gateway.
>
> So either it is back, or something else is going on.
>
> So far, the two people that have complained are using NetScape
> Communicator, and
> both are outside the US, which makes me wonder whether there is a
> NetScape (export-version) problem.
>
> So let me test this. This paragraph is written as one long line, and
> should be automatically line wrapped and broken. If it is not, and if
> you are using anything other than Communicator please let me know. (I
> would suggest that you copy the list, so that umpty-thousand people
> don't send me mail for the same problem.)
>
> Likewise, if someone is using Netscape Communicator 3.01 in a non-US
> version who is NOT having any particular difficulty reading this
> paragraph, please let me know as well.
>
> I'd like to fix it, but don't know what's wrong.
>
> Bob

Approved-By:  Sam Schaen <[email-masked]>
Date:         Wed, 28 Jan 1998 19:44:45 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sam Schaen <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

In Communicator 4.0x, there is a "wrap long lines" option that needs to be checked to avoid the problem described.

Bob Jueneman wrote:

> Two people have recently complained that my messages create line lengths
> that are too long, and hard to read. This used to be a problem with GroupWise,
> and I had to manually insert line breaks, but the problem was solved some time ago
> at our gateway.
>
> So either it is back, or something else is going on.
>
> So far, the two people that have complained are using NetScape Communicator, and
> both are outside the US, which makes me wonder whether there is a NetScape (export-version) problem.
>
> So let me test this. This paragraph is written as one long line, and should be automatically line wrapped and broken. If it is not, and if you are using anything other than Communicator please let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send me mail for the same problem.)
>
> Likewise, if someone is using Netscape Communicator 3.01 in a non-US version who is NOT having any particular difficulty reading this paragraph, please let me know as well.
>
> I'd like to fix it, but don't know what's wrong.
>
> Bob

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 28 Jan 1998 17:24:58 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

I took a look at RFC 2104, which defines HMAC. The RFC suggests defining
the length of a truncated output by appending the legnth to the algorithm name,
e.g.,  HMAC-SHA-1-96.  I am told that SET uses HMAC-SHA-1-160, but
that no OID has been assigned.

Truncation appears to be a somewhat mixed blessing. In the particular case we are
talking about, if there is no chance that both the password and the hash can be
diddled with simultaneously, then presumably the Birthday Attack would not apply.

But in general I hate to rely on that kind of finesse analysis -- it is too easy to overlook
something.  I tend to reach for a bigger hammer and squash the sucker once and for all.

If it were up to me, and I didn't have the time to do a more detailed analysis (and I don't),
I would be inclined to use HMAC-SHA-1-128, and define an OID for that.  That would
be sufficient to defeat any Birthday Attack even if a plain-vanilla hash were being used,
and it would still provide the presumed advantages of truncation. It may or may not be
overkill, but at least it is a harmless overkill.

Carlisle, I would suggest that you review this issue with Paul van Oorshot.

Bob
>
>>>> Phillip Hallam-Baker <[email-masked]> 01/27 3:57 PM >>>
>> Note that these OIDs refer to a truncated HMAC where only the first
>> 96 bits of the outer hash output are used - this truncation is described
>> as a security advantage (it wasn't done solely to cram the MAC into
>> the IPSEC packets).
>
>The security advantage is small but significant. First note that the
>Bithday attack collision mode is not relevant since all that matters
>is the propability of collision between a specific password and a trial,
>collisions between the trials are irrelevant, hence 96 bits is more
>than enough for security.
>
>Omitting part of the MAC value means that it is not possible to crack
>a single MAC by exhaustive search, there is simply not enough
>information present. Given a single MAC the best the attacker can
>do is to derrive a large set of possible candidates (2^44 in this case).
>Narrowing the choice requires a further exhastive attack of these
>candidates against another MAC value.
>
>Oh well back to work...
>
>        Phill

Approved-By:  Amit Kapoor <[email-masked]>
Date:         Wed, 28 Jan 1998 16:32:01 -0000
Reply-To: "[email-masked]" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Amit Kapoor <[email-masked]>
Organization: Secant
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Hi Bob,

        Might I recommend that you test with the complaining people instead of
        copying the entire list.

        Appreciate it.

Amit
(BTW, I see it as a single line and I am using Microsoft Outlook)

-----Original Message-----
From:   Bob Jueneman [SMTP:[email-masked]]
Sent:   Thursday, January 29, 1998 12:06 AM
To:     [email-masked]
Subject:        [IETF-PKIX] Line break problem

Two people have recently complained that my messages create line lengths
that are too long, and hard to read. This used to be a problem with
GroupWise,
and I had to manually insert line breaks, but the problem was solved some
time ago
at our gateway.

So either it is back, or something else is going on.

So far, the two people that have complained are using NetScape
Communicator, and
both are outside the US, which makes me wonder whether there is a NetScape
(export-version) problem.

So let me test this. This paragraph is written as one long line, and should
be automatically line wrapped and broken. If it is not, and if you are
using anything other than Communicator please let me know. (I would suggest
that you copy the list, so that umpty-thousand people don't send me mail
for the same problem.)

Likewise, if someone is using Netscape Communicator 3.01 in a non-US
version who is NOT having any particular difficulty reading this paragraph,
please let me know as well.

I'd like to fix it, but don't know what's wrong.

Bob

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 28 Jan 1998 17:05:48 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] Line break problem
Comments: To: [email-masked], [email-masked]
To: [email-masked]
Status:

Two people have recently complained that my messages create line lengths
that are too long, and hard to read. This used to be a problem with GroupWise,
and I had to manually insert line breaks, but the problem was solved some time ago
at our gateway.

So either it is back, or something else is going on.

So far, the two people that have complained are using NetScape Communicator, and
both are outside the US, which makes me wonder whether there is a NetScape (export-version) problem.

So let me test this. This paragraph is written as one long line, and should be automatically line wrapped and broken. If it is not, and if you are using anything other than Communicator please let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send me mail for the same problem.)

Likewise, if someone is using Netscape Communicator 3.01 in a non-US version who is NOT having any particular difficulty reading this paragraph, please let me know as well.

I'd like to fix it, but don't know what's wrong.

Bob

Approved-By:  "Phillip H. Griffin" <[email-masked]>
Date:         Wed, 28 Jan 1998 18:46:11 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

Santoni Adriano wrote:
>
> Anybody wants to kindly point me to some site(s) where the exact and
> clear description of the character sets PrintableString, VisibleString,
> TeletexString (or T61String), IA5String, BMPString...and such, can be
> found?
> TIA to all good guys,
>   Adriano

Hi Santoni,

The ASN.1 standards define the types that you refer to above. In
particular, you should look under "Restricted Character String
Types" in X.680. Note tha PrintableString is a subset of the
visible US ASCII characters, or simply a subset of ASN.1 type
VisibleString. BMPString is used for national language support,
and contains 2-byte Unicode characters. A new ASN.1 type named
UTF8String contains all of BMPString and more. It allows the
US ASCII characters to be transmitted as a single byte, and also
supports 2 and 3 byte characters.

These types, generally, are based on the ISO 646:1991, and
ISO/IEC 10646-1, for ASN.1 1994, and an older version of
ISO 646 (1971?) for ASN.1 1990 (X.208), which is commonly
used in IETF works.

For more detailed information, I suggest that you consult X.680.
IESG/IETF expertise can be obtained from Harald Alvestrand, at
[email-masked], who is very much involved in
standards activities related to character sets.

Phil
--
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Approved-By: [email-masked]
Date:         Wed, 28 Jan 1998 19:09:21 +0200
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

> Anybody wants to kindly point me to some site(s) where the exact and
> clear description of the character sets PrintableString, VisibleString,
> TeletexString (or T61String), IA5String, BMPString...and such, can be
> found?

ISO water torture, as Peter Gutmann puts it ;)

Best place I've found is his X.509 Style Guide, which you can get to from
his collection of security links:

  http://www.cs.auckland.ac.nz/~pgut001/links.html

Now bear in mind that asking for an "exact and clear" description of
something as painful as your chosen topic of enquiry is like asking for
enjoyable dentistry.  But at least it's an interesting read.

--
Mark Shuttleworth
Thawte Consulting

Approved-By:  Rowland Smith <[email-masked]>
Date:         Wed, 28 Jan 1998 12:15:20 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rowland Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

At 11:51 AM 1/28/98 -0500, Scott Guthery wrote:
>BER - Basic Encoding Rules
>DER - Distinguished Encoding Rules
>CER - Canonical Encoding Rules
>PER - Packed Encoding Rules
>
>All ways of represending ASN.1 structures as bytes.
>
>Check out Burton Kaliski's note "A Layman's Guide to a Subset
>of ASN.1, BER and DER" for a good introduction.

The ITU-T standards document X.690 contains the complete specifications for
the Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), and X.691 contains the complete
specification for the Packed Encoding Rules (PER).

Later,

>Cheers, Scott
>
>-----Original Message-----
>From: Gina DePlanche <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Wednesday, January 28, 1998 11:41 AM
>Subject: [IETF-PKIX] DER vs BER
>
>
>>        Hi!
>>
>>        I've seen the acronyms BER and DER used in the PKIX drafts and
>>rfcs. Could someone tell me if there is a difference between these, and
>>where I could find it?  From what I can see, it looks like RFC1778
>>defined the encoding that should be used for LDAP.
>>
>>        Thanks,
>>        Gina
>>
>>
>>--
>>Gina M. DePlanche               |       OpenROUTE Networks, Inc.
>>[email-masked]               |       A subsidiary of Proteon, Inc.
>>(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
>>Fax: (508) 836-5347             |       01581-1799  MailStop #23
>>
>
>

--------------------------------------------------------------------------
Rowland Smith                                 Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                               Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Approved-By:  Scott Guthery <[email-masked]>
Date:         Wed, 28 Jan 1998 11:51:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Scott Guthery <[email-masked]>
Subject:      Re: [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

BER - Basic Encoding Rules
DER - Distinguished Encoding Rules
CER - Canonical Encoding Rules
PER - Packed Encoding Rules

All ways of represending ASN.1 structures as bytes.

Check out Burton Kaliski's note "A Layman's Guide to a Subset
of ASN.1, BER and DER" for a good introduction.

Cheers, Scott

-----Original Message-----
From: Gina DePlanche <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, January 28, 1998 11:41 AM
Subject: [IETF-PKIX] DER vs BER

>        Hi!
>
>        I've seen the acronyms BER and DER used in the PKIX drafts and
>rfcs. Could someone tell me if there is a difference between these, and
>where I could find it?  From what I can see, it looks like RFC1778
>defined the encoding that should be used for LDAP.
>
>        Thanks,
>        Gina
>
>
>--
>Gina M. DePlanche               |       OpenROUTE Networks, Inc.
>[email-masked]               |       A subsidiary of Proteon, Inc.
>(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
>Fax: (508) 836-5347             |       01581-1799  MailStop #23
>

Approved-By:  Tolga Acar <[email-masked]>
Date:         Wed, 28 Jan 1998 09:44:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tolga Acar <[email-masked]>
Subject:      Re: [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

The BER and DER are not the same thing. You can find a good explanation of them in  "A Layman's Guide to a Subset of ASN.1, BER, and DER" by RSA Labs, (Burt Kaliski). That doc. can be downloaded from the RSA DSI's www page.

-- Tolga

Approved-By: [email-masked]
Date:         Wed, 28 Jan 1998 06:18:18 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

        Hi!

        I've seen the acronyms BER and DER used in the PKIX drafts and
rfcs. Could someone tell me if there is a difference between these, and
where I could find it?  From what I can see, it looks like RFC1778
defined the encoding that should be used for LDAP.

        Thanks,
        Gina

--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Approved-By:  Santoni Adriano <[email-masked]>
Date:         Wed, 28 Jan 1998 17:17:49 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

Anybody wants to kindly point me to some site(s) where the exact and
clear description of the character sets PrintableString, VisibleString,
TeletexString (or T61String), IA5String, BMPString...and such, can be
found?
TIA to all good guys,
  Adriano

Approved-By: [email-masked]
Date:         Wed, 28 Jan 1998 09:56:57 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

Charles, you're pointing out an area where the X.509 group has already
agreed that text clarifying exactly the points you raise is required in
the base standard. The ASN.1 is fine, but there is no accompanying text.
Defect Report DR185 is on this specific topic. It was discussed at the
July meeting of X.509 in Helsinki and the resolution of the defect is
that clarifying text will be added to the base standard. The X.509
meeting occurs in Phoenix tomorrow and there is a Draft Technical
Corrigendum that after tomorrow's meeting, should be issued for ballot.
I'll make sure that the  text of that DTC is passed to the PKIX group so
that comments on the specific text can be provided.
------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  January 26, 1998 5:31 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross Certification - Terminology
>
><<File: smime.p7s>>
>
>-----Original Message-----
>From: David P. Kemp <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Tuesday, 27 January 1998 1:15
>Subject: Re: [IETF-PKIX] Cross Certification - Terminology
>
>
>:> From: Charles Moore <[email-masked]>
>:>
>:> If we must, I would suggest the following:
>:>
>:> Cross-Certificates
>:> CAs may cross-certify each other, that is each issue the other a
>certificate
>:> and combine the two certificates in a single directory attribute called a
>:> crossCertificatePair. This crossCertificatePair attribute, supports
>chains
>:> of trust that run in both directions and implement trust models that
>begin
>:> at the CA which issued the users certificate, rather than trust models
>where
>:> trust originates from a common "root". A crossCertificatePair, includes
>two
>:> certificates, forward and reverse.  The subject of  the forward
>certificate
>:> is the issuer of the reverse certificate and vice-versa.
>:
>:
>:Inter-domain certification is not necessarily bilateral, i.e. it does
>:not always result in a crossCertificatePair.
>
>The relevant definition is
>CertificatePair    ::= SEQUENCE {
> forward   [0] Certificate OPTIONAL,
> reverse   [1] Certificate OPTIONAL}
>
>I believe that there are optionals  here, the specification does not force a
>particular solution.
>
>snip.
>
>
>
>

Approved-By:  [email-masked]
Date:         Tue, 27 Jan 1998 23:23:04 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Patrick M. Mulrooney" <[email-masked]>
Subject:      [IETF-PKIX] ADMIN: Posting update - Please read
To: [email-masked]
Status:

Folks,

In order to defeat the "spammers" posting junk mail to the IETF-PKIX
mailing list, the list has been changed such that only those subscribed
to the list can post to the list.

In order to accommodate those who may post to the IETF-PKIX list from an
e-mail address (or addresses) other than that on which they are
subscribed to the list, an IETF-PKIX-SUBMIT list has been also created.
IETF-PKIX list subscribers in this category should also register to the
IETF-PKIX-SUBMIT list. To do this send the command
"subscribe IETF-PKIX-SUBMIT <full name>" to [email-masked]
This command should be repeated for each alternate posting From: address.

You may then post to the IETF-PKIX list from either the address registered
to the IETF-PKIX list, or from any of the addresses registered to the
IETF-PKIX-SUBMIT list.

You cannot post to the  IETF-PKIX-SUBMIT list and all messages posted to
IETF-PKIX-SUBMIT will be rejected.

In all cases, you will receive e-mail from the IETF-PKIX list only at the
address registered to the IETF-PKIX list. If this is also the only address
from which you post to the IETF-PKIX list, you do not need to register to
the IETF-PKIX-SUBMIT list.

Any e-mail posted to the IETF-PKIX list from an address not registered on
either list will be forwarded to the IETF-PKIX list owners. They will decide
how to dispose of it based on the content.

--
Postmaster
Tandem Computers

Date:         Tue, 27 Jan 1998 19:11:02 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] Mailing List  Cleanup - Please read...
To: [email-masked]
Status:

Please

If anyone is sending mail to the following addresses would you please
remove
them from your e-mail address list(s) . Some of the people have new
addresses and have been deleted from the IETF-PKIX list for quite a
while.

The following are not on the IETF-PKIX mailing list and we cannot trace
who is sending them. They are no longer valid and so they are being
rejected by the mailservers and we are bombarded with error messagesas
the list owners:

 [email-masked]
 [email-masked]
 [email-masked]
 nsyfrig @wppost.depaul.edu
 [email-masked]
 [email-masked]
 [email-masked]
 [email-masked]

Thanks
   Jeanne

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the
IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX
list.

Date:         Tue, 27 Jan 1998 19:57:21 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "maruyama@IBMUS"@US.IBM.COM
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

                   Status Distribution January 27, 1998 17:32:32

The message regarding "Re: [IETF-PKIX] cross-certification" sent on January 27,
1998 17:32:32 was sent by

Status Recipient
          Type                To
          Native Name         [email-masked]
          Foreign Native Name [email-masked]\n\n\nINTERNET

Recipients

Status Reporters
          Type                From
          Name Domain         NOTES
          Native Name         maruyama@IBMUS
          Foreign Native Name maruyama\nIBMUS\n\n
          Last Name           maruyama

Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Recipient user name maruyama@IBMUS not unique.  Several matches
found in Name & Address Book.

Date:         Tue, 27 Jan 1998 11:06:01 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

>I see two simple alternatives, and feel we should adopt one of them
>before these documents are published as proposed standards:
>
>(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
>X.509-defined term "CA-certificate"; or
>
>(b) Explicitly define the term "cross-certificate" to be the same as the
>term "CA-certificate" (as defined in X.509).

I prefer (a).

Russ

Date:         Tue, 27 Jan 1998 15:58:55 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Guess if I'm going to send private notes, I ought to check the addressee list!  Oh, well, it isn' the first time, and probably won't be the last.

>>> Bob Jueneman <[email-masked]> 01/27 3:30 PM >>>
Private note, to avoid ambarrassing myself too much.

...

Date:         Tue, 27 Jan 1998 17:57:03 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

> Note that these OIDs refer to a truncated HMAC where only the first
> 96 bits of the outer hash output are used - this truncation is described
> as a security advantage (it wasn't done solely to cram the MAC into
> the IPSEC packets).

The security advantage is small but significant. First note that the
Bithday attack collision mode is not relevant since all that matters
is the propability of collision between a specific password and a trial,
collisions between the trials are irrelevant, hence 96 bits is more
than enough for security.

Omitting part of the MAC value means that it is not possible to crack
a single MAC by exhaustive search, there is simply not enough
information present. Given a single MAC the best the attacker can
do is to derrive a large set of possible candidates (2^44 in this case).
Narrowing the choice requires a further exhastive attack of these
candidates against another MAC value.

Oh well back to work...

        Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 39 (????/----) (0001E322)

Date:         Tue, 27 Jan 1998 15:42:49 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

I wasn't necessarily rejecting your argument, I just hadn't thought through the issues enough to be convinced yet.  Your example at least provides a concrete business scenario to consider.

You might consider expanding/expounding on this a little more, to address three possible applications -- (1) recognition and acceptance of company B by company A prior to sending an encrypted message, (2) recognition and acceptance (automatically, lights out) of company B's signature (or one of their employee's), and (3) acceptance of company B's certs, allowing B's employee's free access to A's corporate network.

Do you really see a company's CA getting involved in NDA's and similar business arrangements? Still seems like a stretch, to me.

Bob>
>
>
>>>> Carlisle Adams <[email-masked]> 01/27 2:55 PM >>>
>Hi Bob,
>
>>----------
>>From:  Bob Jueneman[SMTP:[email-masked]]
>>Sent:  Tuesday, January 27, 1998 2:55 PM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] cross-certification
>>
>>3.  I'm not sure that I completely buy Carlisle's argument about need,
>>likelyhood, or even the desirability of one CA requesting a cross-certificate
>>from another CA, as it still requires out-of-band validation of the
>>correctness or the attributes and proof-of-possession of the private key,
>
>I'm a bit surprised at this comment.  Think about this kind of
>cross-certification as analogous to the establishment of a
>non-disclosure agreement (NDA).  Two companies are interested in sharing
>confidential information between specific individuals about specific
>topics.  The process typically begins with one company approaching the
>other and saying, "I'd like to do business with you.  Would you mind if
>we both sign an NDA before we start?"  Once the NDA is in place,
>information can begin to flow.
>
>Here, the cross-certification is similar to (or perhaps, in the new
>world of PKIs, an important part of) the NDA process.  In such a model
>it is entirely natural that a CA in one company would send a
>cross-certification request to, and receive a cross-certification
>response from, a CA in the other company (in fact, the certification
>would probably be mutual).  Yes, they would do the out-of-band exchange;
>yes, they would validate correctness of attributes; yes they would
>verify proof-of-possession.  This would be part of normal business
>practice.
>
>Your preferred model (in which issuers create cross-certificates without
>any involvement from the subjects) is appropriate for some environments
>and must, of course, be accommodated.  However, the model above, it
>seems to me, is appropriate (or even necessary) for other environments.
>I don't think it will be as rare or esoteric as you seem to imply...
>
>>but if the process which works for subordinate CAs also works for
>>cross-certificates I am not opposed to it being included in the certificate
>>management protocols.
>
>Great.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------

Date:         Tue, 27 Jan 1998 15:25:20 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

Right you are. Chalk it up to a brain hiccup. :-)  Somehow I was thinking that the issuer/serial pointed to the CA's certificate, whereas obviously it points to the subject's certificate.

So assuming that IBM in the previous example has (and discloses) two certificates, one from Canada and one from Singapore, and both have the same public key, then it is indeterminate as to which domain E2 and E3 belong to. If they publish a chain of certificate they could go either way. or conceivably include the bifurcated links up to two different TLCAs.

On the other hand, although it is a bit messy, if two different keys are involved (perhaps diferentiated by an issuerKeyID for convenience), then barring another hiccup I believe the domains are determinate.

In either case, I believe that the two domain path validation logic I described still works.  Do you see anything else wrong?

Bob

>> From: "Bob Jueneman" <[email-masked]>
>>
>> Although two certificates exist for IBM, and therefore there might be
>> some ambiguity, there is no ambiguity at all as to which domain E2 and
>> E3 belong to, as that is determined by the issuer and serial number.
>> Since that points to one and only one certificate, and since that
>> certificate in turn has an issuer and serial number, which domain E2
>> and E3 belong to is crystal clear -- Canada.
>
>Nope.
>
>The issuer/serialNumber can uniquely identify a particular cert belonging
>to (say) E2, but it does not uniquely identify either the issuer's (IBM's)
>cert or E2's domain.
>
>E2 belongs to whatever domain he chooses.  If E2 has a cert issued by
>IBM, and IBM has two certs (issued by Singapore and Canada) both of
>which are available to E2 and which have the same subject name and
>public key, then E2 can configure his S/MIME user agent to 1) generate
>cert paths starting at either root when sending messages, and 2) trust
>any number of roots (Canada, Singapore, VeriSign, Entrust, GTE, Thawte,
>etc) when validating received messages.
>
>E3 can make a similar choice of domain membership, and it does not have
>to be the same as E2's.   There may be external administrative restrictions
>on how E2 and E3 configure their domain membership, but nothing in PKIX
>forces them to belong to, say, Canada.
>
>
>> Thanks for all the fish, guys.  This has been a fun discussion.
>
>Likewise.

Date:         Tue, 27 Jan 1998 15:30:21 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Private note, to avoid ambarrassing myself too much.

Carlisle, it serves me right for jumping into this without having read the documents in detail.  But is the use of CertificatePair, and in general the directory operations you are discussing, part of the CMP specification?

I wasn't aware that the PKIX group had yet gotten around to specing directory entries, schemas, etc.

In any case I don't believe that it is necessarily wise to assume that a relying party will be able to access a directory outside of her own local domain.

Am I stepping on it here?

Bob

>>> Carlisle Adams <[email-masked]> 01/27 2:34 PM >>>
Hi Bob,

One comment...

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 2:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>If instead of looking up the issuer name in the directory, we looked up the
>subject name in the subjexct's own directory, and if ALL of the issuers of
>all of the certificates for that subject were to deposit their certificates
>in that directory, perhaps keyed somehow by the domain or TLCA of the various
>issuer hierarchies, then  instead of following the subject/issuer chain in
>the certificate, we could follow the various chains in the _directory_,
>instead.
>
>But that would require that the subject of all certificates be responsible
>for publishing their own certificates, even if they had no relationship to
>the issuer of the certificate.
>
>I explicitly DON'T want to assume that level of cooperation, because I want
>my local IT group to be able to cross-certify some public CA's root key (or
>for that matter, some subordinate CA's key, or even an end-user's key, if
>necessary for efficiency's sake) without ANY involvement by that CA (or
>end-user) at all.

Note that a cross-certificate can be published by the subject in the
"forward" parameter of a CertificatePair in the subject's directory
entry AND / OR can be published by the issuer in the "reverse" parameter
of a CertificatePair in the issuer's directory entry.  It is not
actually necessary to force issuers to be the publishers of
cross-certificates in their own entries, or to force subjects to be the
publishers of cross-certificates in their own entries.  Either scenario
can be used and, in fact, publishing in BOTH places (when possible and
appropriate) will allow greater flexibility in the path construction /
validation logic.

In other words, the path processing logic should not make an assumption
about where cross-certificates will be found (i.e., only subject's entry
or only issuer's entry).  It should be able to look in both places
before giving up.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 16:55:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Bob,

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 2:55 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>3.  I'm not sure that I completely buy Carlisle's argument about need,
>likelyhood, or even the desirability of one CA requesting a cross-certificate
>from another CA, as it still requires out-of-band validation of the
>correctness or the attributes and proof-of-possession of the private key,

I'm a bit surprised at this comment.  Think about this kind of
cross-certification as analogous to the establishment of a
non-disclosure agreement (NDA).  Two companies are interested in sharing
confidential information between specific individuals about specific
topics.  The process typically begins with one company approaching the
other and saying, "I'd like to do business with you.  Would you mind if
we both sign an NDA before we start?"  Once the NDA is in place,
information can begin to flow.

Here, the cross-certification is similar to (or perhaps, in the new
world of PKIs, an important part of) the NDA process.  In such a model
it is entirely natural that a CA in one company would send a
cross-certification request to, and receive a cross-certification
response from, a CA in the other company (in fact, the certification
would probably be mutual).  Yes, they would do the out-of-band exchange;
yes, they would validate correctness of attributes; yes they would
verify proof-of-possession.  This would be part of normal business
practice.

Your preferred model (in which issuers create cross-certificates without
any involvement from the subjects) is appropriate for some environments
and must, of course, be accommodated.  However, the model above, it
seems to me, is appropriate (or even necessary) for other environments.
I don't think it will be as rare or esoteric as you seem to imply...

>but if the process which works for subordinate CAs also works for
>cross-certificates I am not opposed to it being included in the certificate
>management protocols.

Great.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 10:14:04 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Eric Hughes <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

<x-rich>>>>>

<excerpt>Certainly I was unaware of the Novell patent in this area (CRL
processing) until I heard about it from Phillip Halem-Baker, despite the
fact that two of the inventors sit not more than 100 feet from me -- the
patent originated prior to my joining Novell.

</excerpt><<<<<<<<

Do you have a patent number for this?

TIA.

Eric
</x-rich>

Date:         Tue, 27 Jan 1998 16:43:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

> From: "Bob Jueneman" <[email-masked]>
>
> Although two certificates exist for IBM, and therefore there might be
> some ambiguity, there is no ambiguity at all as to which domain E2 and
> E3 belong to, as that is determined by the issuer and serial number.
> Since that points to one and only one certificate, and since that
> certificate in turn has an issuer and serial number, which domain E2
> and E3 belong to is crystal clear -- Canada.

Nope.

The issuer/serialNumber can uniquely identify a particular cert belonging
to (say) E2, but it does not uniquely identify either the issuer's (IBM's)
cert or E2's domain.

E2 belongs to whatever domain he chooses.  If E2 has a cert issued by
IBM, and IBM has two certs (issued by Singapore and Canada) both of
which are available to E2 and which have the same subject name and
public key, then E2 can configure his S/MIME user agent to 1) generate
cert paths starting at either root when sending messages, and 2) trust
any number of roots (Canada, Singapore, VeriSign, Entrust, GTE, Thawte,
etc) when validating received messages.

E3 can make a similar choice of domain membership, and it does not have
to be the same as E2's.   There may be external administrative restrictions
on how E2 and E3 configure their domain membership, but nothing in PKIX
forces them to belong to, say, Canada.

> Thanks for all the fish, guys.  This has been a fun discussion.

Likewise.

Date:         Tue, 27 Jan 1998 16:34:52 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Bob,

One comment...

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 2:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>If instead of looking up the issuer name in the directory, we looked up the
>subject name in the subjexct's own directory, and if ALL of the issuers of
>all of the certificates for that subject were to deposit their certificates
>in that directory, perhaps keyed somehow by the domain or TLCA of the various
>issuer hierarchies, then  instead of following the subject/issuer chain in
>the certificate, we could follow the various chains in the _directory_,
>instead.
>
>But that would require that the subject of all certificates be responsible
>for publishing their own certificates, even if they had no relationship to
>the issuer of the certificate.
>
>I explicitly DON'T want to assume that level of cooperation, because I want
>my local IT group to be able to cross-certify some public CA's root key (or
>for that matter, some subordinate CA's key, or even an end-user's key, if
>necessary for efficiency's sake) without ANY involvement by that CA (or
>end-user) at all.

Note that a cross-certificate can be published by the subject in the
"forward" parameter of a CertificatePair in the subject's directory
entry AND / OR can be published by the issuer in the "reverse" parameter
of a CertificatePair in the issuer's directory entry.  It is not
actually necessary to force issuers to be the publishers of
cross-certificates in their own entries, or to force subjects to be the
publishers of cross-certificates in their own entries.  Either scenario
can be used and, in fact, publishing in BOTH places (when possible and
appropriate) will allow greater flexibility in the path construction /
validation logic.

In other words, the path processing logic should not make an assumption
about where cross-certificates will be found (i.e., only subject's entry
or only issuer's entry).  It should be able to look in both places
before giving up.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 13:31:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

>
>The IANA has registered OIDs for HMAC mechanisms as used by IPSEC:
>
>  ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers
>
>iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
>isakmpOakley(1) HMAC-md5(1)  [1.3.6.1.5.5.8.1.1]
>iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
>isakmpOakley(1) HMAC-SHA(2)  [1.3.6.1.5.5.8.1.2]
>
>The reference in the IANA document [Thayer] is missing, but it refers
>to the IPSEC document roadmap, which in turn references "The Use of
>HMAC-SHA-1-96 within ESP and AH",
>
>  ftp://ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt
>
>which in turn references RFC 2104 "HMAC: Keyed Hashing for Message
>Authentication", the actual algorithm description.
>
>Note that these OIDs refer to a truncated HMAC where only the first
>96 bits of the outer hash output are used - this truncation is described
>as a security advantage (it wasn't done solely to cram the MAC into
>the IPSEC packets).

As usual when adopting a standard intended for one purpose for another completely different one, you need to be careful to ensure that the standards are meeting the same needs.

Although I haven't followed the use of HMAC in IPSEC, I would have serious reservations about the use of ANY hash algorithm that is only 96 bits long, unless I had wralked though all of the possible attack scenarios very carefully.

The problem, of course, is that a Birthday Problem attack on a 96 bit hash only requires on the order of 2^48 calculations to defeat it.  Although there may be a security advantage in doing some truncation (e.g., to protect against attempts to extract the secret salt), 96 bits is far too short for comfort.

If we can't find anything else, we should write up and use a varient of HMAC that is somewhere between 128 and 140 bits long, I believe.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date:         Tue, 27 Jan 1998 15:13:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Bob Jueneman wrote:
>
> It would be interesting to know whether the IETF and particularly the
> IESG share this assumption.

The IESG only reflects the consensus of the IETF as a whole. Time and
time again we have polled the plenary (the best method we have to
gauge the "sense" of the IETF) on issues important to the IETF. We
also have the POISED working group, which defines the standards
process, which also deals with this issue.

Personal opinions of individual IESG members can influence discussions
(we are only human), however on important policy matters we are tasked
to go with the community perspective making use of our best technical
judgment.

It is my experience that the sense of the community is formed in a
large part by how patent holders in this space have behaved in the
past.

Let me propose that we terminate this discussion here. If people feel
one way or the other about IETF intellectual property policies, the
place to raise it is in the POISED working group.

                                -Jeff
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 38 (????/----) (0001E321)

Date:         Tue, 27 Jan 1998 14:48:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

> From: Bob
>
> > From: Carlisle
> >
> >This seems to be two votes in favor of HMAC-SHA-1 and no disagreements
> >so far.  I don't mind specifying this as the mandatory parameter in
> >PasswordBasedMac, but let me repeat Nada's question:
> >
> >>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
> >>anybody have a pointer to some document specifying it?
> >
> >I need this as soon as possible (i.e., within the next day or two).  If
> >an OID doesn't exist, should PKIX define one?
>
> I don't know the OID, but I believe that one was defined for SET, if
> someone has that spec.
>
> Bob

The IANA has registered OIDs for HMAC mechanisms as used by IPSEC:

  ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers

iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
isakmpOakley(1) HMAC-md5(1)  [1.3.6.1.5.5.8.1.1]
iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
isakmpOakley(1) HMAC-SHA(2)  [1.3.6.1.5.5.8.1.2]

The reference in the IANA document [Thayer] is missing, but it refers
to the IPSEC document roadmap, which in turn references "The Use of
HMAC-SHA-1-96 within ESP and AH",

  ftp://ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt

which in turn references RFC 2104 "HMAC: Keyed Hashing for Message
Authentication", the actual algorithm description.

Note that these OIDs refer to a truncated HMAC where only the first
96 bits of the outer hash output are used - this truncation is described
as a security advantage (it wasn't done solely to cram the MAC into
the IPSEC packets).

Date:         Tue, 27 Jan 1998 12:55:15 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

Dave, you've made some insightful comments. I'll therefore elaborate on my lengthy> message to
>Al and Hal.
>
>>>> "David P. Kemp" <[email-masked]> 01/27 11:16 AM >>>
>> From: Hal Lockhart <[email-masked]>
>>
>> I grant the wording is hard to follow, but the idea is simple.  Just ask
>> the question" Is the issuer attribute a back pointer?  If yes, its
>> hierarchical, if no, its a cross-cert.
>>
>> Hal
>
>
>I thought it sounded simple too, until I drew the diagram and realized
>that the issuer field in the subordinate CA's certificate didn't solve
>anything - it's always a back pointer to something.
>
>Start with top-level CAs 0 and 1 again, or call them "Canada" and
>"Singapore":
>
>                          CA0 "Canada"
>                            \
>      CA1 "Singapore" ----> CA2 "IBM"
>      /                    /  \
>     E1                   E2   E3
>
>
>The problem is that CA2 has two certificates with the same public key
>and possibly the same subject name (IBM), but with different issuer
>names.  Each Relying Party can choose which of CA0 or CA1 to use as
>a trust anchor when validating E3's cert; for each choice there is an
>available cert with CA2 as the subject and a valid back-pointing
>issuer field.

The key verb in that paragraph is the "has" in the first sentence.

I agree that somewhere in the universe there exist the two certificates you mention, but I also believe that there is a significant difference in the state of knowledge of the relying parties who are "in" (trust) the Canada domain vs. the Singapore domain.

If you buy my argument that unilateral cross-certification _may_ at least, be completely transparent and even oblivious to the CA and end-users within the domain that is being cross-certified, then to use your example, IBM and the users E2 and E3 may be completely ignorant of the Singapore domain, or any corss-certification between Singapore and Canada.  In particular, if user E2 sends an S/MIME message to the PKIX list and includes E2's complete certificate chain, then that chain will contain certificates for E2, IBM, and Canada, period.

If E3 is the relying party, there is obviously no problem, for E3 has a common root in Canada (and also a common subordinate CA, IBM, for that matter).

But if E1 is the relying party, things are different.  E1 knows about Singapore, but she doesn't know anything about Canada. When she tries to find and validate E2's certificate in the Singapoore hierarchy, she doesn't find it, so she has to climb _E2's_ chain, leading to IBM.  Then, using my suggested algorithm she finds that Singapore has cross-certified IBM, and so the validation is successful.
>
>You have to invoke politics to determine which domain IBM belongs to,
>and therefore which cert is the cross-cert.  There doesn't seem to be
>any way around that.

>One possible solution is for both Singapore and Candada to agree that
>CA2's real name is "C=CA, O=IBM".  Any cert with CA2 as the subject
>which didn't follow name subordination would be defined as a cross-cert.
>But it doesn't seem useful to go through the process of labelling a
>particular certificate as a cross-cert if there is no difference in
>the path validation procedure as a result of assigning that label.

"Politics" in this case is the simple "eye-of-the-beholder" rule.  Although two certificates exist for IBM, and therefore there might be some ambiguity, there is no ambiguity at all as to which domain E2 and E3 belong to, as that is determined by the issuer and serial number. Since that points to one and only one certificate, and since that certificate in turn has an issuer and serial number, which domain E2 and E3 belong to is crystal clear -- Canada.  It doesn't, and shouldn't, have anything to do with country of origin or other naming conventions. (Entrust might have been a better example than IBM -- clearly Entrust might have a branch office in Singapore that might nonetheless be a member of the Canadian hierarchy.)
>
>I'm starting to believe that if the term "cross-certification" is used
>to mean anything more limited and specific than "CA-certification",
>then the description of the difference belongs *only* in Part 4.
>
>For purposes of Part 1 and Part 3, they are synonymous unless someone
>can come up with a concrete example where the difference has an
>observable effect on 1) certificate contents, 2) path validation rules,
>or 3) management protocol operations.  This is, in fact, a Good Thing.
>It means that X.509/PKIX is general enough to support the
>political/operational act of "cross-certification" without requiring
>any special-purpose syntax or protocol operations.

You may have a point here.

I believe that:

1.  There is no observable difference in the certificate contents per se (one certificate at a time, at least), so X.509 would not seem to be impacted.  That's obviously good.

2.  There is a considerable difference in the relying party's path validation rules. Those
rules will presumably need to be rewritten to handle the two independent hierarchy/directory/domain case as I previously described, assuming others accept this approach.

3.  I'm not sure that I completely buy Carlisle's argument about need, likelyhood, or even the desirability of one CA requesting a cross-certificate from another CA, as it still requires out-of-band validation of the correctness or the attributes and proof-of-possession of the private key, but if the process which works for subordinate CAs also works for cross-certificates I am not opposed to it being included in the certificate management protocols.

Thanks for all the fish, guys.  This has been a fun discussion.

Bob

Date:         Tue, 27 Jan 1998 12:16:36 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

I think we are getting somewhere, but there seem to be three separate problems to be addressed:

1.  Proper understanding trust relationships being discussed,

2.  Representing that trust relatiionship in some meaningful, parseable, and hopefully concise English definition, and

3.  Figuring out what to do about the nasty problems of certificate retrieval and public key validation in a mesh network.

>Intellectually, I believe that there is a difference between a
>"CA-certificate" issued to a CA in the same hierarchy, and a
>"cross-certificate" issued to a CA (maybe a Root CA/TopLevelCA/whatever)
>in another hierarchy.

Quite so. and the difference, of course, is who is doing the issuing, and who the relying parties are.

My primary interest (AKA bias, AKA blind spot?) in the use of cross-certificates is to support a model which allows a user or her IT organization to simply represent which independent hierarchical domains of trust they choose to give credence to.  So my primary mental model is a bottom-up, followed by multiple top-down models, controlled and modulated as required by policyOID and/or other validation path constraints.

I would be quite wary of ANY certification authority (other than my own) which cross-certifies some other CA hierarchy, unless they can assure me that they have applied the same policy mapping and other CPS constraints to that other hierarchy, and can assure me that they are equivalent.

I have no problem if the Government of Canada wishes to instruct those users over which it has either moral or legal authority, e.g., government employees within the Ministry of Defence, that they should trust the certificates issued by the Government of Singapore as effectively the equivalent of the certificates issued by the Government of Canada.  It is certainly their right to do so.

However, it would be quite another thing to assert that if I decide to trust the certificate issued by the Government of Canada, I must or at least should trust the certificate issued by the Government of Singapore.

I don't have anything against Singapore, particularly, but they obviously have a much different legal system than what I am used to, and they are sufficiently far away both in distance in culture that I would not even think of extending to them the same degree of trust I would give Canada, a country which I have visited multiple times, and whose citizens, culture, and legal system I am quite familiar with.  This is the obvious problem with transitive trust, writ large when it comes to cross-certification.
>
>For example:  at the RSA Conference two weeks ago, John Ryan of Entrust
>announced that the Government of Canada (which uses Entrust) and the
>Government of Singapore (which also uses Entrust) will soon
>cross-certify.  It seems to me that that's a valid use of the term - it
>strikes me that:
>
>        Scenario A:  the Top-Level CA of the Government of Canada issues a
>CA-certificate to a subordinate CA for Revenue Canada, or some other
>government department
>
>        Scenario B:  the Top-Level CA of the Government of Canada issues a
>cross-certificate to the Top-Level CA of the Government of Singapore,
>permitting validation of communications among some end-users supported
>by the two governments under certain conditions
>
>are two different things, that ought to be recognized as such.  While it
>may or may not be directly reflected in the certificate, the degree of
>control exerted by the issuing CA over the certificate's recipient is
>very different, and relying parties should be able to take this into
>account.
>
Agreed.
>
>So, how do we define this?  Let's start with Denis' suggestion:
>
>>Cross-certificate: A CA-certificate issued by one CA for another CA that
>>is either in a different naming hierarchy and/or in a different
>>organizational structure.
>
>I think this is okay, but I'd rather see "organizational structure"
>replaced with "domain", which I think is a much more flexible term.

Naming hierarchy is obviously much too narrow.  If I decide that I like Verisign's policies relating to their Class 3 certificates used for web servers and code signing, I may decide to trust all of their Class 3 certificate, regardless of the lack of any name constraints or other relationship.

Likewise, organizational structure doesn't work, for there isn't any organization in common.  The issue is more one of policy, and perhaps contractual agreements.  "Domain" comes closer, but tends to imply a more rigid degree of authoritative control, a la DMS, that is probably warranted in the commercial environment.  So far I haven't come up with a one-word English description. [Maybe we should adopt, and if necessary bastardize, the German word "bund," loosely meaning "association," but without the legal meaning that association might have in English. But please, all you German linguists, don't jump all over me. It's probably a bad idea.]
]>
>Bob Jueneman wrote:
>
>1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
>subject community or hierarchy) if the certificate containing the
>distinguished name of the entity listed in the subject attribute was
>issued by the same CA (distinguished name) whose distinguished name
>appears in the issuer attribute in the same certificate.
>
>I'm not sure I fully understand this (I went so far as to try
>diagramming the sentence), but it seems to only allow two-level
>hierarchies; e.g., a Top-Level CA and then one subordinate CA.  It seems
>to fall apart if you try to build (Top-Level CA, CA, subordinate CA)
>structures.  Bob:  is there anything you can do to clarify this?

Sorry, Al. I wrote that one about three times, and had some trouble understanding it myself.  But I was not trying to differentiate between a CA and a subordinate CA, but only between subordinate certificates vs. TLCA and cross-certificates.  So from my point of view your structure is wrong -- it should be TLCA, subordinate CA, subordinate CA..

What I was trying to do in economical language was to define what all of us would understand is meant by a certificate being in a given hierarchy, decended from a TLCA.  The essense of the hierarchy is the chaining relationship between the name of issuer of a certificate and the issuer name that is recorded in the certificate itself.  They are obviously the same in the case of a certificate issued  by a higher level CA to a subordinate CA in the same hierarchy, whereas they are not the same in the case of a cross-certificate. This becomes clearer if you think about starting at the bottom with an end-user certificate and climbing the tree for that chain.

In a single hierarchy, there is a one to many relationship between issuers and subjects, but for any given subject, there is only one issuer.  Given a certificate for some subordinate entity (CA or end-user), I should be able to extract the issuer name from that certificate, look up that distinguished name in a directory or other repository and thereby find the CA's own certificate, issued by the next higher level CA.  And applying that procedure recursively, I should be able to climb the tree from the bottom up, until I come to a self-signed certificate which is issued by the TLCA.

Presumably this is not the case for a cross-certified certificate.

It occurs to me that this may be a major difference between what I am assuming and what I understand (perhaps incorrectly) that some others may be doing.

If instead of looking up the issuer name in the directory, we looked up the subject name in the subjexct's own directory, and if ALL of the issuers of all of the certificates for that subject were to deposit their certificates in that directory, perhaps keyed somehow by the domain or TLCA of the various issuer hierarchies, then  instead of following the subject/issuer chain in the certificate, we could follow the various chains in the _directory_, instead.

But that would require that the subject of all certificates be responsible for publishing their own certificates, even if they had no relationship to the issuer of the certificate.

I explicitly DON'T want to assume that level of cooperation, because I want my local IT group to be able to cross-certify some public CA's root key (or for that matter, some subordinate CA's key, or even an end-user's key, if necessary for efficiency's sake) without ANY involvement by that CA (or end-user) at all.

On the other hand, I AM willing to assume that I operate my own local (or virtual) and perhaps TRUSTED (by me) directory, and that all of the certificates created by my own TLCA are deposited in that directory.

Within MY hierarchy, anchored at the top by a TLCA I trust, and within my directory, all of the certificates appear to be perfectly normal. The subject to issuer names chain correctly, and even the issuer names plus serial numbers are correct.

And within the single hierarchy of the end-user whose certificate is being validated, the certificates also appear normal, and chain correctly.

The difficulty comes in knowing when to hop off of one chain and onto another, i.e., recognizing that a cross-certificate exists in the absence of the normal issuer plus serial number chaining.

I therefore proposed the following algorithm for validating a certificate across two hierarchies, the relying party's domain and the subject's domain.:

For simplicity, let's assume that the subject has provided an entire chain of certificates along with his digital signature, leading back to his own TLCA, but that I the relyuing party have not directly included that TLCA's key in my cache of trusted root keys.  (If the subject has not provided the entire chain, then it may be necessary to find the various certificates within the subject's hierarchy/directory, or from some other repository, hinted at somehow. But this is a more or less irrelevant detail for the present argument.)

1.  Given the subject's name, I look for a certificate corresponding to that name in my own directory, perhaps aided by a hint such as a hash of the public key. If I find a certificate for that subject name and key, I know that the subject's certificate is valid because I previously put it in my trusted directory, but I can also climb the certificate tree within my own hierarchy/directory and revalidate the chain if I wish. In either case  the validation process has concluded successfully.

2.  If I don't find the subject's name and public key in my hierarchy/directory, I must extract the issuer name from the certificate provided to me. Then, using that issuer name as a subject name, I repeat step (1), first looking in _my_ hierarchy/directory to see if I have already processed a cross-certificate for that CA. If I have, I can stop and the validation is successful; if not, I must continue up the _subject's_ certificate chain.

3. If I encounter a self-signed certificate in the subject's chain of certificates, signifying a TLCA for the subject's hierarchy, and I cannot find a corresponding subject name and key in my own hierarchy/directory, then the validation process has failed for lack of a common or cross-certified root key.

Note that this process does not require that I go all the way up to the subject's TLCA before stopping. I can cross-certify some intermediate CA in the process, if necessary for efficiency, or perhaps because I trust that CA, but not necessarily other CA's higher up in that CA's chain. (I previously described a scenario involving the Utah National Guard, which might be certified by both the State of Utah and the Department of Defense.  As a resident of Utah I might trust the Utah NG, but not the entire DOD chain of CAs.)

It might be worth making another observation, to the effect that the above algorithm does NOT support transitive cross-certification.  I first look in my own hierarchy, and if I don't find a certificate I climb the subject's hierarchy. At no time will I encounter a cross-certificate issued by some intermediate party.  So if my IT organization issues a cross-certificate to the Government of Canada, I would accept all of the CAs and end-users certified by Canada, but I would never encounter a cross-certificate issued by Canada to Singapore. If I encountered an end-user's certificate from Singapore, I would end up checking my hierarchy and the Singapore hierarchy, but I would never encounter the Canadian cross-cert.  I believe that is appropriate behavior, since transitive cross-certification seems altogether too scary.

Hal Lockhardt said:

>However, this now brings us to the engineering problem that somebody tried
>to discuss a week or two back. Namely: how do we find all the certs we
>need?  If the cross cert is required to point to a cert in our chain, we
>are all set, but what if the relationship is more indirect?  Stealing
>David's pictures:
>
>                                          CA0
>                         (2)                \
>                                  CA1 ----> CA2
>                                 /         /   \
>                                E1        E2   E3
>
>Assuming E1 has the CA1 cert, this case is easy, but
>
>                                          CA0
>               (3)                          \
>                       CA1 ----> CA1a ----> CA2
>                       /                   /   \
>                      E1                  E2   E3
>
>This requires a combination of bottom-up and top-down processing.  This is
>further complicated if we have to protect against loops.

I believe that the above algorithm solves this problem, and is loop free in the case of well-formed hierarchies. If either of the two domains does in fact contain a loop, then either standard traverse-marking or counter technicques can be used to terminate processing.

Finally, to respond to Denis point:

>> 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user)
>
>Bob,
>
>If you take a look at part 3,section 3.5, we have "cross-certification:
>An requesting CA provides to a responding CA ..." this means that the
>end-entity CANNOT be an end-user.
>
I would respectfully suggest that it is the quoted definition and/or the protocol that is broken, not the cross-certificate model.

Although perhaps appropriate in the limited context (which I would argue was really addressing subordinate CA certificates, and not cross-certificates), in the general cross-certification case I reject the notion that there is necessarily any requesting/responding relationship between CAs at all.

Therefore I as the cross-certifiying CA am perfectly free to certify any entity's name and public key I choose, whether a CA or an end-user, within my own hierarchy/directory/domain.

Sorry for the length of this  -- comments came in faster than I could type!

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date:         Tue, 27 Jan 1998 14:02:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

>On the other hand, I suspect that 99% of the contributors to this list
>are not patent experts, and in many if not most cases, may have little
>or no knowledge of the patents currently held by their employer.

I don't know that Novell made any concerted effort to get its version
of CRL processing adopted as an IETF standard.

The real problem is when the patent authors are involved, allowing
of course for the problem that a person may no longer work for the
assignee but still be bound by an NDA.

> The world-wide system of patent protection is based on the assumption
>that by providing the creator of an invention the right to make a
>reasonable return on his work for a limited amount of time, the
>public will ultimately benefit from their labors, and hence the
>public good will be enhanced.

That may be the *World* approach to patent law, the US approach is
very different. The term 'intellectual property' tends to be
interpreted in terms of 'rights' with a sort of 'land rush' mentality
in which the first (white) person to stake a claim gets to take
the Indian's land.

Unlike other patent offices the US PTO does not have an outside
review period. as a result it has allowed a number of ludicrous
patent grants, the term 'patently obvious' frequently comming to
mind. It does not even manage to check its own issued patents
for prior art, let alone the current litterature.

The consensus view of patents in the IETF would most likely be
that they are a form of government taxation on invention akin
to a compulsory lottery. Most are forced to participate, to
grab patents so that they can trade them with other people who
have patents they need access to.

This is why I was asking what people intend to do with their
patents, the IESG has a history of playing hardball. Not letting
a standard pass until the patent holders reliquish their rights
being a common one. Have a look at the 'Intelecutal Property'
statements on the IETF home page.

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 37 (????/----) (0001E31F)

Date:         Tue, 27 Jan 1998 13:40:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi,

It seems the indenting didn't show up properly last time, so it might be
hard for others to distinguish what Bob said from what I said.  Let's
try this again...

>----------
>From:  Carlisle Adams
>Sent:  Tuesday, January 27, 1998 12:01 PM
>To:    'Bob Jueneman'
>Subject:       RE: [IETF-PKIX] cross-certification
>
>Hi Bob,
>
>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 5:00 PM
>To:    Carlisle Adams; [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>Carlisle, for the record I continue to have a problem with what appears to be
>the basic premise regarding unilateral cross-certification, i.e., that it
>necessarily needs to be requested by the subject of the certificate at all.
>But perhaps I am not reading the text correctly.
>
>You are reading the text correctly.  But that basic premise is there for a
>very simple reason.  If the subject is not involved in this decision (i.e.,
>if the issuer decides entirely on its own to create a cross-certificate for
>that subject) AND if the issuer is the one responsible for publishing the
>cross-certificate once its created, then there is no need for a protocol.
>There is nothing whatsoever in that exercise that needs to be specified in
>CMP.
>
>What we're trying to cover is the case in which the subject *does* ask for
>the cross-certificate.  In this situation, there needs to be a protocol
>specified (so that the subject knows *how* to ask, and the issuer knows how
>to respond).
>
>If my IT organization decides to bestow corporate trust on some TLCA, and
>does so by means of a unilateral cross-certificate (outside of the TLCA's
>hierarchy), I don't expect the TLCA being so recognized to initiate or even
>participate in the creation of the certificate, either by participation in a
>protocol or through any legal or business arrangements, necesarily.
>
>And for that reason, I'm not sure why it would make sense to depart from the
>general pattern of haivng the CA who issues the certificate be responsible
>for publishing it.  Surely the issuing CA would still be responsbile for
>publishing any6 CRLs, so why be inconsistent?
>
>Again, you and Nada agree here and I'm not hearing opposing views from the
>list.  Therefore, I will relax the constraint that the subject (the
>requester) is the one who publishes.  As it turns out, the better solution is
>already accommodated in the protocol:  if the requester cares who publishes
>(and where), then it should use the PKIPublicationInfo parameter.  I will add
>a note to the effect that if this optional parameter is omitted in the
>request, then the issuer is the one who publishes the resulting certificate.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
>

Date:         Tue, 27 Jan 1998 11:40:15 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

>Hi Bob, Nada,
>
>>----------
>>From:  Bob Jueneman[SMTP:[email-masked]]
>>Sent:  Monday, January 26, 1998 8:44 PM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] mandatory PasswordBasedMac
>>
>>Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather
>>than triple-DES MAC for password protection.
>>
>>Although the use of triple-DES for password authentication may be approved
>>for export from the US, proving beyond a reasonable doubt that that is all
>>that it is used for may pose substantial difficulties. In addition, the use
>>of triple-DES may also cause significant _import_ restrictions, e.g., into
>>France, Russia, and some other countries.
>>
>>As a general principle, we should not be using an encryption algorithm,
>>especially a symmetric algorithm, when a safer, less controversial algorithm
>>is available and more than adequate for the purpose.
>
>This seems to be two votes in favor of HMAC-SHA-1 and no disagreements
>so far.  I don't mind specifying this as the mandatory parameter in
>PasswordBasedMac, but let me repeat Nada's question:
>
>>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
>>anybody have a pointer to some document specifying it?
>
>I need this as soon as possible (i.e., within the next day or two).  If
>an OID doesn't exist, should PKIX define one?

I don't know the OID, but I believe that one was defined for SET, if someone has that spec.

Bob

Date:         Tue, 27 Jan 1998 11:28:29 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

Bob (et al) :

My understanding of cross certificates is kind of basic:  If I am a CA and wish to incorporate the certificates issued by  another CA into my trust domain, then  I would execute a contract with that CA then issue a CA-certificate  to that CA.  I would impose some limitation on levels of issuers below the contracted CA and  no trust for CAs above or without contract.  This would bring all of "my" certificate subscribers (including those of the cross-certified CAs) still to me to validate certs for relying on those certs issued by a CA to whom I have issued an issuer cert.  The draw back in this scenario is that I do not have any contractual business relationship with those subscribers of the CA I brought into my "trust" domain, so I assume liability to my reliant party community for the identity and usage of those certs.  Hopefully, my contract with the cross-certified CA indemnifies me sufficiently from their errors (or fraud).

The schemes for "cross-certifying" that some vendors have implemented where a "lateral" cross cert is issued for a CA outside my "hierarchy" of trust (do not end at the same root as mine) are more "scary" when they also bring in all the "lateral" cross-certifications of those CAs as well.  I have a hard time recognizing with whom I need contracts and indemnity with.  IIt may be just the one CA relationship who will indemnify me from all of the errors, omissions and fraud of all of their cross-certified CAs (and their's and so on) that they bring to my domain of trust.

I think that a workable situation might be with correspondent Ca contracts for identity of the other CA's clients just in order to establish a new contract and business realtionship with each individual on whose identity I need to rely.  I can have correspondent CA relationships established and certificate status or CRL checks with those correspondents without automatically bringing in all of their subscribers without establishing those subscriber buisiness relationships.  These correspondnet relationships do not entail merging the domains of trust (or CRLs, ARLs, etc.) and are backed by the correspondent contracts.

I know this is a different model than that of a "Public" CA wishing to enable its subscribers to communicate with other CA's subscribers.  My current focus is on design and implementation of a "Corporate" PKI within an extranet environment over the public nets to do commerce.  With this different focus, my comments may be particular to the corporate, eComemrce model and not the public infrastructure.

In the corporate model, I need business agreements with those I do business with.  If I have a contract with you as a CA, then I need recourse against you for problems caused by "your" customers.  If I need to do business with "your" customers and you do not wish to indemnify me, then I need to establish a relatinship with them myself.

Do you concur?

michael

>>> Bob Jueneman <[email-masked]> 01/26/98 05:11PM >>>
Dave,

>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed. Certificate definitions should certainly not depend on the container used to hold them!

>
>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".
>
>If we could come up with a simple and consensus-agreed definition
>which could be quickly inserted into CMP, that would be ideal.
>Can you write such a definition?  (I can't.)

How's this:

1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate.

2.  A Top-Level Certification Authority certificate is by definition a self-signed certificate, i.e., one in which the issuer and subject distinguished names are identical.  A TLCA normally issues certificates to subordinate CAs and/or end-entities which contain the TLCA's name as the issuer.

3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) which is neither a subordinate  certificate as defined by (1), nor a TLCA certificate as defined by (2).  I.e., the name of the issuing CA in the certificate in question is _not_ the same as that contained in the issuer attribute of any certificates issued to the subject entity by the TLCA in that hierarchy.

Bob

>
>In the meantime, I agree with you that there appears to be a meaningful
>difference between a CA-cert and a cross-cert, even if we can't define
>what it is.  For that reason, I agree that it would be undesirable
>to change "cross-certificate" to "CA-certificate" in PKIX documents.
>Option (a) was better than option (b), but doing nothing is better
>still.

Option (a) would be better than (b), since most of the discussion in the PKIX documents seems to revolve around the issuance of subordinate CA certificate rather than what I would call a true cross-certificate.  But doing nothing would simply prolong the agony.

Bob

>
>Dave Kemp
>
>
>
>> From: Sharon Boeyen <[email-masked]>
>>
>> Cross-certification can certainly occur either uni-laterally or
>> bi-laterally.
>>
>>  If CA A issues a cross cert for CA B, that cross cert can be published
>> :
>> a)  by CA A as a forward cross-certificate in the cross-certificates
>> attribute of CA A's entry;
>> b)  by CA B as a reverse cross-certificate in the cross-certificates
>> attribute of CA B's entry;
>> c)  or both
>> If the cross-certification is bi-lateral the reverse would apply to the
>> cross-certificate issued by CA B for CA A.
>>
>> CA A should control what gets published/or not in its entry and CA B
>> control what gets published/or not in its entry. Nada is correct that in
>> no case should we expect that CA A have write permission to CA B's entry
>> or vice versa.
>>
>> I do expect that some of these directory specific issues will get
>> addressed in the PKIX LDAP schema specification that we agreed to pursue
>> at the December meeting. For instance, we would want to make sure that
>> cross-certificates are placed in the cross-certificates attribute and
>> not the CA-certificate attribute.
>>
>> Another reason to maintain the term cross-certification and not confuse
>> matters further.
>>
>> ------------------
>> Sharon Boeyen
>> Entrust Technologies

Date:         Tue, 27 Jan 1998 13:26:54 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      [IETF-PKIX] FW: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi,

Sorry, I meant for this to go to everyone, not just to Bob.

>----------
>From:  Carlisle Adams
>Sent:  Tuesday, January 27, 1998 12:01 PM
>To:    'Bob Jueneman'
>Subject:       RE: [IETF-PKIX] cross-certification
>
>Hi Bob,
>
>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 5:00 PM
>To:    Carlisle Adams; [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>Carlisle, for the record I continue to have a problem with what appears to be
>the basic premise regarding unilateral cross-certification, i.e., that it
>necessarily needs to be requested by the subject of the certificate at all.
>But perhaps I am not reading the text correctly.
>
>You are reading the text correctly.  But that basic premise is there for a
>very simple reason.  If the subject is not involved in this decision (i.e.,
>if the issuer decides entirely on its own to create a cross-certificate for
>that subject) AND if the issuer is the one responsible for publishing the
>cross-certificate once its created, then there is no need for a protocol.
>There is nothing whatsoever in that exercise that needs to be specified in
>CMP.
>
>What we're trying to cover is the case in which the subject *does* ask for
>the cross-certificate.  In this situation, there needs to be a protocol
>specified (so that the subject knows *how* to ask, and the issuer knows how
>to respond).
>
>If my IT organization decides to bestow corporate trust on some TLCA, and
>does so by means of a unilateral cross-certificate (outside of the TLCA's
>hierarchy), I don't expect the TLCA being so recognized to initiate or even
>participate in the creation of the certificate, either by participation in a
>protocol or through any legal or business arrangements, necesarily.
>
>And for that reason, I'm not sure why it would make sense to depart from the
>general pattern of haivng the CA who issues the certificate be responsible
>for publishing it.  Surely the issuing CA would still be responsbile for
>publishing any6 CRLs, so why be inconsistent?
>
>Again, you and Nada agree here and I'm not hearing opposing views from the
>list.  Therefore, I will relax the constraint that the subject (the
>requester) is the one who publishes.  As it turns out, the better solution is
>already accommodated in the protocol:  if the requester cares who publishes
>(and where), then it should use the PKIPublicationInfo parameter.  I will add
>a note to the effect that if this optional parameter is omitted in the
>request, then the issuer is the one who publishes the resulting certificate.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
>

Date:         Tue, 27 Jan 1998 13:16:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

> From: Hal Lockhart <[email-masked]>
>
> I grant the wording is hard to follow, but the idea is simple.  Just ask
> the question" Is the issuer attribute a back pointer?  If yes, its
> hierarchical, if no, its a cross-cert.
>
> Hal

I thought it sounded simple too, until I drew the diagram and realized
that the issuer field in the subordinate CA's certificate didn't solve
anything - it's always a back pointer to something.

Start with top-level CAs 0 and 1 again, or call them "Canada" and
"Singapore":

                          CA0 "Canada"
                            \
      CA1 "Singapore" ----> CA2 "IBM"
      /                    /  \
     E1                   E2   E3

The problem is that CA2 has two certificates with the same public key
and possibly the same subject name (IBM), but with different issuer
names.  Each Relying Party can choose which of CA0 or CA1 to use as
a trust anchor when validating E3's cert; for each choice there is an
available cert with CA2 as the subject and a valid back-pointing
issuer field.

You have to invoke politics to determine which domain IBM belongs to,
and therefore which cert is the cross-cert.  There doesn't seem to be
any way around that.

One possible solution is for both Singapore and Candada to agree that
CA2's real name is "C=CA, O=IBM".  Any cert with CA2 as the subject
which didn't follow name subordination would be defined as a cross-cert.
But it doesn't seem useful to go through the process of labelling a
particular certificate as a cross-cert if there is no difference in
the path validation procedure as a result of assigning that label.

I'm starting to believe that if the term "cross-certification" is used
to mean anything more limited and specific than "CA-certification",
then the description of the difference belongs *only* in Part 4.

For purposes of Part 1 and Part 3, they are synonymous unless someone
can come up with a concrete example where the difference has an
observable effect on 1) certificate contents, 2) path validation rules,
or 3) management protocol operations.  This is, in fact, a Good Thing.
It means that X.509/PKIX is general enough to support the
political/operational act of "cross-certification" without requiring
any special-purpose syntax or protocol operations.

Date:         Tue, 27 Jan 1998 11:45:20 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

Hi Bob, Nada,

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 8:44 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] mandatory PasswordBasedMac
>
>Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather
>than triple-DES MAC for password protection.
>
>Although the use of triple-DES for password authentication may be approved
>for export from the US, proving beyond a reasonable doubt that that is all
>that it is used for may pose substantial difficulties. In addition, the use
>of triple-DES may also cause significant _import_ restrictions, e.g., into
>France, Russia, and some other countries.
>
>As a general principle, we should not be using an encryption algorithm,
>especially a symmetric algorithm, when a safer, less controversial algorithm
>is available and more than adequate for the purpose.

This seems to be two votes in favor of HMAC-SHA-1 and no disagreements
so far.  I don't mind specifying this as the mandatory parameter in
PasswordBasedMac, but let me repeat Nada's question:

>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
>anybody have a pointer to some document specifying it?

I need this as soon as possible (i.e., within the next day or two).  If
an OID doesn't exist, should PKIX define one?

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 11:27:16 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Al,

>----------
>From:  Arsenault, Al W.[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 10:29 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>        Scenario A:  the Top-Level CA of the Government of Canada issues a
>CA-certificate to a subordinate CA for Revenue Canada, or some other
>government department
>
>        Scenario B:  the Top-Level CA of the Government of Canada issues a
>cross-certificate to the Top-Level CA of the Government of Singapore,
>permitting validation of communications among some end-users supported
>by the two governments under certain conditions
>
>are two different things, that ought to be recognized as such.  While it
>may or may not be directly reflected in the certificate, the degree of
>control exerted by the issuing CA over the certificate's recipient is
>very different, and relying parties should be able to take this into
>account.

I agree that these seem intuitively to be two different things and that
it would be nice to recognize them as such.  However, as you rightly
point out, the difference may not be directly reflected in the
certificate.  In other words, there may be nothing whatsoever in the
bare syntax of the certificates that allows you to make the distinction
in an automated way.  It seems to me that it might be a somewhat
fruitless exercise to take things that can't be distinguished by the
bits-on-the-wire and try to give them different names.

As odd as it may seem to some, I think that these are both examples of
cross-certification because in each case there are two distinct CAs
involved (and I think that looking at things in terms of "subject
communities" and "relying party communities" makes this clear).

Agreed:  using the term "cross-certificate" for both cases fails to
distinguish between Scenario A and Scenario B.  However, the term
"CA-certificate" fails to distinguish between Scenario A above and a
self-signed certificate.  When reasoning about and implementing path
validation logic, distinguishing the latter seems (to me) to be more
important than distinguishing the former.  Thus, I'd be more inclined to
give the latter different names than to give the former different names.

>So, how do we define this?  Let's start with Denis' suggestion:
>
>>Cross-certificate: A CA-certificate issued by one CA for another CA that
>>is either in a different naming hierarchy and/or in a different
>>organizational structure.
>
>I think this is okay, but I'd rather see "organizational structure"
>replaced with "domain", which I think is a much more flexible term.

I kind of agree, but I fear that it's so much more flexible a term that
for most practical purposes, it's really undefined...  :-)

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 11:14:52 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

At 10:29 AM 1/27/98 -0500, Arsenault, Al W. wrote:

>Bob Jueneman wrote:
>
>>1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
>>subject community or hierarchy) if the certificate containing the
>>distinguished name of the entity listed in the subject attribute was
>>issued by the same CA (distinguished name) whose distinguished name
>>appears in the issuer attribute in the same certificate.
>
>I'm not sure I fully understand this (I went so far as to try
>diagramming the sentence), but it seems to only allow two-level
>hierarchies; e.g., a Top-Level CA and then one subordinate CA.  It seems
>to fall apart if you try to build (Top-Level CA, CA, subordinate CA)
>structures.  Bob:  is there anything you can do to clarify this?

I grant the wording is hard to follow, but the idea is simple.  Just ask
the question" Is the issuer attribute a back pointer?  If yes, its
hierarchical, if no, its a cross-cert.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 27 Jan 1998 10:29:38 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Intellectually, I believe that there is a difference between a
"CA-certificate" issued to a CA in the same hierarchy, and a
"cross-certificate" issued to a CA (maybe a Root CA/TopLevelCA/whatever)
in another hierarchy.

For example:  at the RSA Conference two weeks ago, John Ryan of Entrust
announced that the Government of Canada (which uses Entrust) and the
Government of Singapore (which also uses Entrust) will soon
cross-certify.  It seems to me that that's a valid use of the term - it
strikes me that:

        Scenario A:  the Top-Level CA of the Government of Canada issues a
CA-certificate to a subordinate CA for Revenue Canada, or some other
government department

        Scenario B:  the Top-Level CA of the Government of Canada issues a
cross-certificate to the Top-Level CA of the Government of Singapore,
permitting validation of communications among some end-users supported
by the two governments under certain conditions

are two different things, that ought to be recognized as such.  While it
may or may not be directly reflected in the certificate, the degree of
control exerted by the issuing CA over the certificate's recipient is
very different, and relying parties should be able to take this into
account.

So, how do we define this?  Let's start with Denis' suggestion:

>Cross-certificate: A CA-certificate issued by one CA for another CA that
>is either in a different naming hierarchy and/or in a different
>organizational structure.

I think this is okay, but I'd rather see "organizational structure"
replaced with "domain", which I think is a much more flexible term.

Bob Jueneman wrote:

1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
subject community or hierarchy) if the certificate containing the
distinguished name of the entity listed in the subject attribute was
issued by the same CA (distinguished name) whose distinguished name
appears in the issuer attribute in the same certificate.

I'm not sure I fully understand this (I went so far as to try
diagramming the sentence), but it seems to only allow two-level
hierarchies; e.g., a Top-Level CA and then one subordinate CA.  It seems
to fall apart if you try to build (Top-Level CA, CA, subordinate CA)
structures.  Bob:  is there anything you can do to clarify this?

                        Al Arsenault

- speaking only for myself.  My views do not necessarily reflect those
of my employer.

>

Date:         Tue, 27 Jan 1998 10:22:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

At 05:11 PM 1/26/98 -0700, Bob Jueneman wrote:

>How's this:
>
>1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
subject community or hierarchy) if the certificate containing the
distinguished name of the entity listed in the subject attribute was issued
by the same CA (distinguished name) whose distinguished name appears in the
issuer attribute in the same certificate.
>
>2.  A Top-Level Certification Authority certificate is by definition a
self-signed certificate, i.e., one in which the issuer and subject
distinguished names are identical.  A TLCA normally issues certificates to
subordinate CAs and/or end-entities which contain the TLCA's name as the
issuer.
>
>3. A cross-certificate is a certificate issued to a end-entity (CA or
end-user) which is neither a subordinate  certificate as defined by (1),
nor a TLCA certificate as defined by (2).  I.e., the name of the issuing CA
in the certificate in question is _not_ the same as that contained in the
issuer attribute of any certificates issued to the subject entity by the
TLCA in that hierarchy.

I like these (assuming the correction that cross-certs can only be issued
to CA's as suggested by Denis). They are unambigious and seem to get at the
"what is a domain?" issue in a concrete way that avoids all the politics
and religion.

However, this now brings us to the engineering problem that somebody tried
to discuss a week or two back. Namely: how do we find all the certs we
need?  If the cross cert is required to point to a cert in our chain, we
are all set, but what if the relationship is more indirect?  Stealing
David's pictures:

                                          CA0
                         (2)                \
                                  CA1 ----> CA2
                                 /         /   \
                                E1        E2   E3

Assuming E1 has the CA1 cert, this case is easy, but

                                          CA0
               (3)                          \
                       CA1 ----> CA1a ----> CA2
                       /                   /   \
                      E1                  E2   E3

This requires a combination of bottom-up and top-down processing.  This is
further complicated if we have to protect against loops.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 27 Jan 1998 08:58:03 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Fillingham, David W." <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme
To: [email-masked]
Status:

Mack:

I definitely agree with you that it is "good news" that the NACHA CA
Demonstrators are taking advantage of the PKIX Part IV Policy Framework
to generate comparable policies!  This is precisely what the document
was written for - and it's great to see it being used as you describe!

I believe Section 5 of the Part IV document addresses your concern.  It
says...

5. PRACTICES AND POLICY SPECIFICATION OUTLINE

This section contains a possible outline for a practices and policy
specification, intended to serve as a checklist or (with some further
development) a standard template for use by certificate policy or CPS
writers.  Such a common outline will facilitate:

(a)  Comparison of two certificate policies during cross-certification
(for the purpose of equivalency mapping).

(b) Comparison of a CPS with a certificate policy definition to ensure
that the CPS faithfully implements the policy.

(c) Comparison of two CPSs.

It then goes on to provide a suggested numbered outline.  I think the
intent is that policies and CPS documents follow the Section 5 outline -
but if we can get the bulk of the CA community writing their policies
with the policy elements in the right order, then I think we'll have
made significant progress!  Not sure where the PKIX would make a
recommendation to do so, other than in the PKIX Part IV document itself
- and the recommendation is already there.

Thanks for your interest in, and support of, the IETF PKIX Policy
Framework!

Dave Fillingham

>----------
>From:  Mack Hicks[SMTP:[email-masked]]
>Sent:  Thursday, January 22, 1998 2:17 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme
>
>For: IETF-PKIX Mailing list
>
>As part of the NACHA Demonstrator for CA interoperability,
>the participant banks are putting together their Certificate Practice
>Stmts.  During this process, some people noted that the
>IETF PKIX Part IV - CPCPSF is being often being used as an outline.
>For example, the American Bar Association ISC is using the "same
>numbering scheme" in their documents (or so I was so informed.)
>
>This is really good news.
>Relying parties could then look at a CP and CPS by examining known
>paragraphs for information regarding such things as key size and
>authentication mechanisms.
>
>My question:
>
>  Is the numbering being used from the PART IV itself or from the
>  suggested outline?
>  Your CPCPSF numbering seems to be "slightly" different.
>
>  Since Part IV is not a standard, but a reference doc (sorry - I have
>  forgotten the exact name) - should there be a recommendation within
>  PKIX that CP's and CPS's follow the numbering scheme?
>
>PS:  NACHA Demonstrator <URL:http://www.nacha.org/tic/workgrps.htm#CA>
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>
>

Date:         Tue, 27 Jan 1998 13:27:33 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Bob Jueneman wrote:

> >If we could come up with a simple and consensus-agreed definition
> >which could be quickly inserted into CMP, that would be ideal.
> >Can you write such a definition?  (I can't.)
>
> How's this:

(...)

> 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user)

Bob,

If you take a look at part 3,section 3.5, we have "cross-certification:
An requesting CA provides to a responding CA ..." this means that the
end-entity CANNOT be an end-user.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Tue, 27 Jan 1998 13:45:09 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Carlisle Adams wrote:

(text deleted)

> Relying Party:  a relying party of a CA is an entity that validates
> certificate chains using the public key of that CA as an end-point
> (i.e., a trust anchor).

If we were going to need and keep that definition, then I would prefer
the following wording:

Relying Party:  a relying party of a CA is an entity that validates
certificate chains using one or more self-signed certificates of
that CA as an end-point (i.e., a trust anchor).

(text deleted)

An intuitive difference between a CA-certificate and a cross-certificate
is that a CA-certificate is a certificate simply stating that this is a
certificate issued by one CA for another CA, whereas a cross-certificate
implies that at the time the certificate is generated, the two CAs have
loose relationships. This may mean that they are in different naming
hierarchies and/or different organizational structures. Let me make a
try and put a Euro (instead of a cent) into the balance  :-)

Cross-certificate: A CA-certificate issued by one CA for another CA that
is either in a different naming hierarchy and/or in a different
organizational structure.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Mon, 26 Jan 1998 18:44:04 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather than triple-DES MAC for password protection.

Although the use of triple-DES for password authentication may be approved for export from the US, proving beyond a reasonable doubt that that is all that it is used for may pose substantial difficulties. In addition, the use of triple-DES may also cause significant _import_ restrictions, e.g., into France, Russia, and some other countries.

As a general principle, we should not be using an encryption algorithm, especially a symmetric algorithm, when a safer, less controversial algorithm is available and more than adequate for the purpose.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Nada Kapidzic Cicovic <[email-masked]> 01/22 2:47 AM >>>
At 11:46 1/21/98 -0500, Carlisle Adams wrote:
>Hi Nada,
>
>>----------
>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>Sent:  Monday, January 12, 1998 8:03 AM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] mandatory PasswordBasedMac
>>
>>I have one more comment on the completeness of ipki3cmp document.
>>
>>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
>>mandatory algorithm for PKI message protection. As far as I understand, the
>>reason for specifying mandatory algorithms is for easier interoperability
>>between complying implementations. However, PasswordBasedMac (as specified
>>in section "3.1.3 PKI Message Protection") is parametrized with a
>>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
>>but for MAC different alternatives are given.
>>
>>Shouldn't the specification of mandatory algorithms make clear which
>>algorithms should be used in place of the mentioned two parameters in
>>PasswordBasedMac? What would be the preferable alternatives?
>
>Good point (thanks for noticing this)!  Yes, a particular OWF and MAC
>should be mandated for interoperability purposes.
>
>Unless there are any strong objections, I think the most sensible
>choices would be SHA-1 for the OWF (since it's already mandated as part
>of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES
>(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and
>PROT_SYM_ALG).

Well, HMAC-SHA-1 is also a valid and presumably much faster alternative to
Triple-DES-MAC. If SHA-1 is mandatory for OWF, then HMAC-SHA-1 can be a
natural choice for the MAC.

BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
anybody have a pointer to some document specifying it?

Regards,

Nada

>
>I will add this to Appendix B2.  Thanks again!
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Mon, 26 Jan 1998 17:11:32 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

Dave,

>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed. Certificate definitions should certainly not depend on the container used to hold them!

>
>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".
>
>If we could come up with a simple and consensus-agreed definition
>which could be quickly inserted into CMP, that would be ideal.
>Can you write such a definition?  (I can't.)

How's this:

1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate.

2.  A Top-Level Certification Authority certificate is by definition a self-signed certificate, i.e., one in which the issuer and subject distinguished names are identical.  A TLCA normally issues certificates to subordinate CAs and/or end-entities which contain the TLCA's name as the issuer.

3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) which is neither a subordinate  certificate as defined by (1), nor a TLCA certificate as defined by (2).  I.e., the name of the issuing CA in the certificate in question is _not_ the same as that contained in the issuer attribute of any certificates issued to the subject entity by the TLCA in that hierarchy.

Bob

>
>In the meantime, I agree with you that there appears to be a meaningful
>difference between a CA-cert and a cross-cert, even if we can't define
>what it is.  For that reason, I agree that it would be undesirable
>to change "cross-certificate" to "CA-certificate" in PKIX documents.
>Option (a) was better than option (b), but doing nothing is better
>still.

Option (a) would be better than (b), since most of the discussion in the PKIX documents seems to revolve around the issuance of subordinate CA certificate rather than what I would call a true cross-certificate.  But doing nothing would simply prolong the agony.

Bob

>
>Dave Kemp
>
>
>
>> From: Sharon Boeyen <[email-masked]>
>>
>> Cross-certification can certainly occur either uni-laterally or
>> bi-laterally.
>>
>>  If CA A issues a cross cert for CA B, that cross cert can be published
>> :
>> a)  by CA A as a forward cross-certificate in the cross-certificates
>> attribute of CA A's entry;
>> b)  by CA B as a reverse cross-certificate in the cross-certificates
>> attribute of CA B's entry;
>> c)  or both
>> If the cross-certification is bi-lateral the reverse would apply to the
>> cross-certificate issued by CA B for CA A.
>>
>> CA A should control what gets published/or not in its entry and CA B
>> control what gets published/or not in its entry. Nada is correct that in
>> no case should we expect that CA A have write permission to CA B's entry
>> or vice versa.
>>
>> I do expect that some of these directory specific issues will get
>> addressed in the PKIX LDAP schema specification that we agreed to pursue
>> at the December meeting. For instance, we would want to make sure that
>> cross-certificates are placed in the cross-certificates attribute and
>> not the CA-certificate attribute.
>>
>> Another reason to maintain the term cross-certification and not confuse
>> matters further.
>>
>> ------------------
>> Sharon Boeyen
>> Entrust Technologies

Date:         Mon, 26 Jan 1998 16:08:49 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

>Given Jeff's comments below, perhaps it is an appropriate time to invite
>all individuals/corporations participating in the PKIX work to inform us of
>any other patent filings or patents granted that might impact any of the
>PKIX projects.  We can do without more surprises down the track.

>Warwick

Other organizations I am aware of address this problem by assigning _)corporate_ membership in the group, and by signing a document which clearly spells out what the intellectual property rights of the "contributing" organization are vs. the rights of other members of the group, or the public.

The IETF, on the other hand, defines "membership" very loosely, if at all, and the contributions are generally viewed as being those of the individual, not the corporation.  It therefore seems difficult to assign the responsibility for patent clearance, licensing, etc., to the individual contributors, who may be quite ill-suited to that role.

I do agree that it would be poor form for someone to knowingly, much less deliberately, submit a contribution which later (surprise!) is revealed to be encumbered by a patent.

On the other hand, I suspect that 99% of the contributors to this list are not patent experts, and in many if not most cases, may have little or no knowledge of the patents currently held by their employer. Certainly I was unaware of the Novell patent in this area (CRL processing) until I heard about it from Phillip Halem-Baker, despite the fact that two of the inventors sit not more than 100 feet from me -- the patent originated prior to my joining Novell.  And I haven't had the time (or inclination, to be candid) to research the patent vs. the proposed standard (to which I have contributed only occasional comments) to see whether the proposed standard infringes or not.

Another issue is the extent to which a "contribution" is more or less complete and intact, vs. the more normal kinds of evolving commentary and dialogue.  In the case of a more or less complete contribution, I would normally expect that a company has reviewed the general concept to determine whether they have any intellectual property issues, prior to publicly disclosing what might be an invention. But in the case of a continued technical dialogue, I think it would be quite rare to get a IP review prior to making a suggestion that might ultimately be included in a proposed standard.

Of course another whole issue entirely is whether the IETF, and more particularly the IESG, does the public good or ill by what I perceive to be a rather blatant anti-intellectual property bias.  In other words, does deliberately crafting or modifying standards to avoid infringing on the valid inventions of others in the field tend to reward innovation and invention, or discourage it?

The world-wide system of patent protection is based on the assumption that by providing the creator of an invention the right to make a reasonable return on his work for a limited amount of time, the public will ultimately benefit from their labors, and hence the public good will be enhanced.

It would be interesting to know whether the IETF and particularly the IESG share this assumption.

Bob

(Speaking strictly for myself, and not necessarily for any past, present, or future employers, and/or any other organizations with which I may be associated)

>
>At 06:38 PM 1/13/98 -0500, Jeffrey I. Schiller wrote:
>>Indeed it is poor form for an individual to make contributions to a
>>working group and after the group has adopted those recommendations,
>>announce that the proposal is encumbered by that individual or the
>>individuals company (and the individual was aware of the encumbrance at
>>the time of suggestion). In other words, when you make a contribution to
>>a WG, it is exactly that, a *contribution*.
>>
>>Some believe that because the patent application process is secret, that
>>information about pending patents does not have to be revealed. This
>>just isn't so. Although the patent process is secret, it is completely
>>reasonable for the IETF to say "If you want to contribute a technology
>>to a working group effort, then you must disclosure your interest." If
>>you don't wish to disclose your interest, you don't have to make the
>>suggestion!
>>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date:         Tue, 27 Jan 1998 08:31:06 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 27 January 1998 1:15
Subject: Re: [IETF-PKIX] Cross Certification - Terminology

:> From: Charles Moore <[email-masked]>
:>
:> If we must, I would suggest the following:
:>
:> Cross-Certificates
:> CAs may cross-certify each other, that is each issue the other a
certificate
:> and combine the two certificates in a single directory attribute called a
:> crossCertificatePair. This crossCertificatePair attribute, supports
chains
:> of trust that run in both directions and implement trust models that
begin
:> at the CA which issued the users certificate, rather than trust models
where
:> trust originates from a common "root". A crossCertificatePair, includes
two
:> certificates, forward and reverse.  The subject of  the forward
certificate
:> is the issuer of the reverse certificate and vice-versa.
:
:
:Inter-domain certification is not necessarily bilateral, i.e. it does
:not always result in a crossCertificatePair.

The relevant definition is
CertificatePair    ::= SEQUENCE {
 forward   [0] Certificate OPTIONAL,
 reverse   [1] Certificate OPTIONAL}

I believe that there are optionals  here, the specification does not force a
particular solution.

snip.

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

Attachment converted: Lutefisk:smime.p7s 36 (????/----) (0001E31D)

Date:         Tue, 27 Jan 1998 07:56:13 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

-----Original Message-----
snip--

. For instance, we would want to make sure that
:cross-certificates are placed in the cross-certificates attribute and
:not the CA-certificate attribute.

Agree
:
:Another reason to maintain the term cross-certification and not confuse
:matters further.
:
Agree.

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

Attachment converted: Lutefisk:smime.p7s 35 (????/----) (0001E31B)

Date:         Mon, 26 Jan 1998 16:05:32 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

Consider the following two certification graphs, each with three
End Entities:

                                          CA0
  (1)                    (2)                \
         CA1                      CA1 ----> CA2
        /   \                    /         /   \
       E1   CA2                 E1        E2   E3
           /   \
          E2   E3

Graph (1) purports to be a single-rooted heirarchy where E1, E2 and E3 all
  begin verifying at the self-signed cert of CA1.  CA2 has a CA-certificate
  issued by CA1.

Graph (2) purports to represent unilateral cross-certification, where E1
  trusts CA1's self-signed cert, and E2 and E3 trust CA0's self-signed cert.
  (CA0 is introduced solely to allow CA2 to be a non-root in both graphs.)
  CA2 has a CA-certificate, which in this case is also a cross-certificate,
  issued by CA1.

Note to Phill: in this example both graphs are acyclic.

As much as I'd like to believe that there is a difference between
CA-certification within an organization/heirarchy and
cross-certification across unrelated organizations, I am unable to
discern any difference between the two graphs.  Today, in graph 2,
E2 and E3 trust root CA0.  Tomorrow, E2 might trust CA0 while E3
chooses to trust CA1.  The next day, they might both trust only CA1.
Next week, each might trust both CA0 and CA1.

Any scheme which labels a cert issued by CA1 to CA2 depending on the
independent and dynamic trust decisions made by CA2's subjects seems to
stand on shaky ground.  And Carlisle's proposal also implies that all
CA-certification fits his definition of cross-certification.

So I guess we're coming around to Warwick's option (b).

Date:         Mon, 26 Jan 1998 13:26:25 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

Sharon:

Well I, for one, asked many people who mentioned cross-certification for
clarification and, as with our experience on this list, was not overly
surprised to find that they were quite often talking about different
things.  The waters are muddy now.  We have no choice but to either define
the term or drop it.

Do I take it you are voting for my (b) option?

Warwick

At 08:04 AM 1/26/98 -0500, Sharon Boeyen wrote:
>I believe that removing the term cross-certification will do nothing
>more than add confusion to the situation. At the RSA conference last
>week, for example,  I attended numerous sessions where the term
>cross-certification was used repeatedly and not once did I hear a
>question asking for clarification. We will only muddy the waters now if
>we try to change the term, or even worse, people reading our documents
>may interpret that PKIX doesn't address cross-certification.
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>
>>----------
>>From:  Warwick Ford[SMTP:[email-masked]]
>>Sent:  January 25, 1998 7:03 PM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] Cross Certification - Terminology
>>
>>The thread on cross-certification terminology did not achieve much except
>>to confirm that many people have different views on what
>>"cross-certification" means and what needs to be done to address the
>>subject area.  We shall clearly not resolve all the issues here quickly,
>>but there were some valuable contributions to start from.
>>
>>However, we need immediately to clarify or fix the usage of the term in
>>PKIX 1 and CMP, since that is causing lots of confusion in the outside
>>world.  I see two simple alternatives, and feel we should adopt one of them
>>before these documents are published as proposed standards:
>>
>>(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
>>X.509-defined term "CA-certificate"; or
>>
>>(b) Explicitly define the term "cross-certificate" to be the same as the
>>term "CA-certificate" (as defined in X.509).
>>
>>I know that not everyone agrees with (b).  For that reason, I propose we do
>>(a), but am willing to open this up to one last round of opinions.
>>
>>Warwick
>>
>>---------------------------------------------------------------------
>>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>>---------------------------------------------------------------------
>>
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 26 Jan 1998 13:21:00 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed

>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".

Where are these communities defined? The subject community
could potentially be defined in the certificate (e.g. *.cnn.com), its
the relying party community that is fuzzy.

Regardless, I really don't think that the problem lies there. The
problem is that 'cross certification' is a property of the trust
graph, not the individual links that compose it. If the graph
is acyclic then no cross certification is going on, if it is cyclic
then there is.

This does not mean that there is a difference between a
CA certificate and a cross certificate however. Both are
simply a type of certificate that makes a claim to delegate
trust in some sense 'I trust X and all Y's that X trusts'.

If we were to define a cross certificate as a CA-certificate that
is a part of a cycle then the type of a particular certificate
would change simply by the issuing of a certificate that
completed a cycle.

E.G if Alice CA-certifies Bob and Bob CA-certifies Carol and
these are the only certificates existing then they are simply
CA-certificates, they could even fit into the PEM model. But
should Carol or Bob decide to CA-certify Alice all the
certificates suddenly become 'Cross certificates'.

This is clearly nonsense but I believe the root of the problem
is the attempt to make a distinction where none exists. Either
a party is making the statement 'trust this person as a CA'
or they are not. Issuing a CA cert involves liability and that is
so regardless of whether the certificate is called a CA-cert,
a cross-certificate or for that matter a PGP key signing.

There is a whole litterature on preventing deadlock in
communications networks that is in effect addressing the
same issue. Deadlock is a global property of networks,
not a property of individual arcs or nodes. Much confusion
was caused until that realisation was made.

It is important to remember that what is left out of
a specification can be just as important as what is
left in.

        Phill

Date:         Mon, 26 Jan 1998 12:43:10 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Dave,

Let's try this...

>----------
>From:  David P. Kemp[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 11:09 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed; this is hardly a useful definition.

>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".

Here is a proposal.

Subject:  a subject of a CA is an entity that is identified by the
subject field of a certificate issued by that CA.

Relying Party:  a relying party of a CA is an entity that validates
certificate chains using the public key of that CA as an end-point
(i.e., a trust anchor).

Given these definitions, I would argue that if the "subject community"
and the "relying party community" are identical, then the cert is not
simply a certificate in which the subject and issuer are CAs, but a
"self-signed CA cert" in which the subject and issuer are the *same* CA
(since only a single CA can have this property).  If the communities are
not identical (as is the case by definition when the subject and issuer
CAs are distinct), then the cert is a "cross-certificate".

This is really the definition of cross-certification  implied by PKIX-1
and CMP ("any case of issuance of a certificate by one CA for another",
as Warwick put it), primarily because this is the definition implied by
X.509 itself where terms like CA-Certificate, CertificationPath,
CertificatePair, and CrossCertificates are all used in the same context
(that of constructing chains of certificates from a relying party to a
subject through an arbitrary set of distinct CAs).  See for example
Warwick's book "Computer Communications Security", p.389.  See also
Menezes, et al, "Handbook of Applied Cryptography", p.572, where
CA-certificate and cross-certificate are defined synonymously.

The point here is that *any* two CAs have different subject and relying
communities, regardless of whether they are in the same organizational
structure or different organizational structures, regardless of whether
they exist in the same hierarchy or different hierarchies or no
hierarchies at all.  Therefore, if they engage in unilateral or mutual
certification, the result is a cross-certificate (or a pair of
cross-certificates).

>If we could come up with a simple and consensus-agreed definition
>which could be quickly inserted into CMP, that would be ideal.
>Can you write such a definition?  (I can't.)

Comments on the above?

>In the meantime, I agree with you that there appears to be a meaningful
>difference between a CA-cert and a cross-cert, even if we can't define
>what it is.  For that reason, I agree that it would be undesirable
>to change "cross-certificate" to "CA-certificate" in PKIX documents.
>Option (a) was better than option (b), but doing nothing is better
>still.

If by "CA-cert" in the previous paragraph you mean "what goes into the
CA-certificate attribute for CA X's directory entry", then I think it
only makes sense for this to be CA X's self-signed certificate.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Mon, 26 Jan 1998 12:50:53 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

>I believe that removing the term cross-certification will do nothing
>more than add confusion to the situation. At the RSA conference last
>week, for example,  I attended numerous sessions where the term
>cross-certification was used repeatedly and not once did I hear a
>question asking for clarification

That is not necessarily a good thing. I have been to conferences
at which the term 'Object Oriented' has been used by almost
every speaker, in most cases as a synonym for 'modern'.

The purpose of a specification is to make the most precise
statement possible about a protocol. Terms that have been
discovered by marketing tend to rapidly become meaningless.

            Phill

Date:         Mon, 26 Jan 1998 11:09:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Sharon,

If CA A issues a certificate for CA B, what criteria are used to
decide if it is a cross-certificate or a CA-certificate?

Defining the distinction to be "if it's published in a
cross-certificate directory attribute, then it's a cross-certificate"
seems tautological - if there is no other distinction then there is no
need for the two different types of directory attributes.

It seems clear to me that the distinction must be based on Tim Moses'
concepts of "subject community" and "relying party community" -
if those communities are identical then the cert is a CA cert,
if the resulting communities are not identical then it is a cross-cert.
But that just shifts the problem from defining "cross-certificate"
to defining "subject community".

If we could come up with a simple and consensus-agreed definition
which could be quickly inserted into CMP, that would be ideal.
Can you write such a definition?  (I can't.)

In the meantime, I agree with you that there appears to be a meaningful
difference between a CA-cert and a cross-cert, even if we can't define
what it is.  For that reason, I agree that it would be undesirable
to change "cross-certificate" to "CA-certificate" in PKIX documents.
Option (a) was better than option (b), but doing nothing is better
still.

Dave Kemp

> From: Sharon Boeyen <[email-masked]>
>
> Cross-certification can certainly occur either uni-laterally or
> bi-laterally.
>
>  If CA A issues a cross cert for CA B, that cross cert can be published
> :
> a)  by CA A as a forward cross-certificate in the cross-certificates
> attribute of CA A's entry;
> b)  by CA B as a reverse cross-certificate in the cross-certificates
> attribute of CA B's entry;
> c)  or both
> If the cross-certification is bi-lateral the reverse would apply to the
> cross-certificate issued by CA B for CA A.
>
> CA A should control what gets published/or not in its entry and CA B
> control what gets published/or not in its entry. Nada is correct that in
> no case should we expect that CA A have write permission to CA B's entry
> or vice versa.
>
> I do expect that some of these directory specific issues will get
> addressed in the PKIX LDAP schema specification that we agreed to pursue
> at the December meeting. For instance, we would want to make sure that
> cross-certificates are placed in the cross-certificates attribute and
> not the CA-certificate attribute.
>
> Another reason to maintain the term cross-certification and not confuse
> matters further.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies

Date:         Mon, 26 Jan 1998 15:35:30 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] R: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "applica tion"
To: [email-masked]
Status:

So you confirm my 2nd interpretation. Thank you.
  Adriano

> -----Messaggio originale-----
> Da:   Santosh Chokhani [SMTP:[email-masked]]
> Inviato:      luned“ 26 gennaio 1998 15.18
> A:    [email-masked]
> Oggetto:      Re: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning
> of             "application"
>
> Example of Application in this case are: electronic mail, retail
> transactions, contracts, travel order, etc.  I hope these examples
> clarify the term applications.
>
> > -----Original Message-----
> > From: Santoni Adriano [SMTP:[email-masked]]
> > Sent: Monday, January 26, 1998 7:25 AM
> > To:   [email-masked]
> > Subject:      [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of
> > "application"
> >
> > Hi all. Sorry if this question has been asked before.
> >
> > Regarding the following excerpt from
> draft-ietf-pkix-ipki-part4-02...
> >
> >         4.1.3  Community and Applicability
> >
> >                  [cut]
> >
> >                  This subcomponent also contains:
> >
> >                     *  A  list of applications for which the issued
> > certificates
> >                     are suitable.
> >
> >                     * A list  of  applications  for  which  use  of
> > the
> > issued
> >                     certificates is restricted.  (This list
> implicitly
> > prohibits
> >                     all other uses for the certificates.)
> >
> > ...anybody wants to explain if the term "application" here means:
> >
> > *       some specific software product (e.g. Netscape Navigator,
> Lotus
> > Domino, etc.)
> > *       a generic software system category that accomplish some
> > category
> > of business needs (e.g. home banking, software publishing, digital
> > signature of disk files, etc.)
> >
> > TIA to all volunteers,
> >    Adriano
> >
> > Ing. Adriano Santoni
> > Direzione Rete - Servizio Progettazione Rete Logica
> > Societˆ Interbancaria per l'Automazione - SIA S.p.A.
> > Viale Certosa, 218 - I-20156 MIlano
> >
> > Vox: +39 2 3005 277
> > Fax: +39 2 38003333
> > Email: [email-masked]
> > Website: http://www.sia.it

Date:         Mon, 26 Jan 1998 09:39:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

> From: Charles Moore <[email-masked]>
>
> If we must, I would suggest the following:
>
> Cross-Certificates
> CAs may cross-certify each other, that is each issue the other a certificate
> and combine the two certificates in a single directory attribute called a
> crossCertificatePair. This crossCertificatePair attribute, supports chains
> of trust that run in both directions and implement trust models that begin
> at the CA which issued the users certificate, rather than trust models where
> trust originates from a common “root”. A crossCertificatePair, includes two
> certificates, forward and reverse.  The subject of  the forward certificate
> is the issuer of the reverse certificate and vice-versa.

Inter-domain certification is not necessarily bilateral, i.e. it does
not always result in a crossCertificatePair.

I favor Warwick's option (a):

    (a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
        X.509-defined term "CA-certificate"

Date:         Mon, 26 Jan 1998 15:22:55 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Antonio Esposito <[email-masked]>
Subject:      [IETF-PKIX] unsubscribe
To: [email-masked]
Status:

<html><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.71.1712.3"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 size=2>unsubscribe</FONT></DIV></BODY></HTML>

</html>

Date:         Mon, 26 Jan 1998 09:18:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santosh Chokhani <[email-masked]>
Subject:      Re: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "application"
To: [email-masked]
Status:

Example of Application in this case are: electronic mail, retail
transactions, contracts, travel order, etc.  I hope these examples
clarify the term applications.

> -----Original Message-----
> From: Santoni Adriano [SMTP:[email-masked]]
> Sent: Monday, January 26, 1998 7:25 AM
> To:   [email-masked]
> Subject:      [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of
> "application"
>
> Hi all. Sorry if this question has been asked before.
>
> Regarding the following excerpt from draft-ietf-pkix-ipki-part4-02...
>
>         4.1.3  Community and Applicability
>
>                  [cut]
>
>                  This subcomponent also contains:
>
>                     *  A  list of applications for which the issued
> certificates
>                     are suitable.
>
>                     * A list  of  applications  for  which  use  of
> the
> issued
>                     certificates is restricted.  (This list implicitly
> prohibits
>                     all other uses for the certificates.)
>
> ...anybody wants to explain if the term "application" here means:
>
> *       some specific software product (e.g. Netscape Navigator, Lotus
> Domino, etc.)
> *       a generic software system category that accomplish some
> category
> of business needs (e.g. home banking, software publishing, digital
> signature of disk files, etc.)
>
> TIA to all volunteers,
>    Adriano
>
> Ing. Adriano Santoni
> Direzione Rete - Servizio Progettazione Rete Logica
> Societˆ Interbancaria per l'Automazione - SIA S.p.A.
> Viale Certosa, 218 - I-20156 MIlano
>
> Vox: +39 2 3005 277
> Fax: +39 2 38003333
> Email: [email-masked]
> Website: http://www.sia.it

Date:         Mon, 26 Jan 1998 08:29:32 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Cross-certification can certainly occur either uni-laterally or
bi-laterally.

 If CA A issues a cross cert for CA B, that cross cert can be published
:
a)  by CA A as a forward cross-certificate in the cross-certificates
attribute of CA A's entry;
b)  by CA B as a reverse cross-certificate in the cross-certificates
attribute of CA B's entry;
c)  or both
If the cross-certification is bi-lateral the reverse would apply to the
cross-certificate issued by CA B for CA A.

CA A should control what gets published/or not in its entry and CA B
control what gets published/or not in its entry. Nada is correct that in
no case should we expect that CA A have write permission to CA B's entry
or vice versa.

I do expect that some of these directory specific issues will get
addressed in the PKIX LDAP schema specification that we agreed to pursue
at the December meeting. For instance, we would want to make sure that
cross-certificates are placed in the cross-certificates attribute and
not the CA-certificate attribute.

Another reason to maintain the term cross-certification and not confuse
matters further.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  January 26, 1998 4:08 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>At 12:03 1/22/98 -0500, you wrote:
>>Hi Nada,
>>
>>>----------
>>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>>Sent:  Thursday, January 22, 1998 5:26 AM
>>>To:    [email-masked]
>>>Subject:       [IETF-PKIX] cross-certification
>>>
>>>Carlisle,
>>>
>....
>
>>>My additional question on second sentence in B7 is: why is publication of
>>>cross-certificate responsibility of requesting CA, and not of the issuing
>>>CA as in any other case?
>>
>>Certainly, the certificate could be published by either side.  However,
>>a basic premise in this document is that the issuing CA (i.e., the one
>>that actually creates and signs the certificate) has final authority
>>over the certificate contents.  Thus, an EE can put anything in the
>>cert. template, but the CA is free to make any modifications that it
>>likes.  The same is true for the cross certification exchange.  Note,
>>though, that for this particular case it may be of slightly more
>>importance that the requester fully approve of all the contents of the
>>certificate before it gets published.  It seemed to me that the simplest
>>way to ensure this was to specify in no uncertain terms that the
>>requester is the one responsible for publishing.
>>
>
>My concern is that requesting CA will not have enough privileges to publish
>the cross-certificate into issuing CA's directory. (This certificate should
>be published in issuing CA's directory, since it is intended to be used by
>end-entities in issuing CA's domain when verifying certificates from
>requester CA's domain.)
>
>Therefore, it seems more natural to have cross-certificate published by its
>issuer.
>
>Regards,
>
>Nada
>
>
>>
>>--------------------------------------------
>>Carlisle Adams
>>Entrust Technologies
>>[email-masked]
>>--------------------------------------------
>>
>______________________________________________________________
>
>Nada Kapidzic Cicovic
>COST - Computer Security Technologies CST AB
>(subsidiary of Entegrity Solutions Corporation)
>office:   + 46 (0)8 477 77 37
>mobile:   + 46 (0)70 495 09 03
>fax:      + 46 (0)8 477 77 31
>e-mail:   [email-masked] or [email-masked]
>address:  Finlandsgatan 60, 164 74 Kista, Sweden
>

Date:         Mon, 26 Jan 1998 08:04:54 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

I believe that removing the term cross-certification will do nothing
more than add confusion to the situation. At the RSA conference last
week, for example,  I attended numerous sessions where the term
cross-certification was used repeatedly and not once did I hear a
question asking for clarification. We will only muddy the waters now if
we try to change the term, or even worse, people reading our documents
may interpret that PKIX doesn't address cross-certification.
------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  January 25, 1998 7:03 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Cross Certification - Terminology
>
>The thread on cross-certification terminology did not achieve much except
>to confirm that many people have different views on what
>"cross-certification" means and what needs to be done to address the
>subject area.  We shall clearly not resolve all the issues here quickly,
>but there were some valuable contributions to start from.
>
>However, we need immediately to clarify or fix the usage of the term in
>PKIX 1 and CMP, since that is causing lots of confusion in the outside
>world.  I see two simple alternatives, and feel we should adopt one of them
>before these documents are published as proposed standards:
>
>(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
>X.509-defined term "CA-certificate"; or
>
>(b) Explicitly define the term "cross-certificate" to be the same as the
>term "CA-certificate" (as defined in X.509).
>
>I know that not everyone agrees with (b).  For that reason, I propose we do
>(a), but am willing to open this up to one last round of opinions.
>
>Warwick
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
>

Date:         Mon, 26 Jan 1998 13:24:45 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "application"
To: [email-masked]
Status:

Hi all. Sorry if this question has been asked before.

Regarding the following excerpt from draft-ietf-pkix-ipki-part4-02...

        4.1.3  Community and Applicability

                 [cut]

                 This subcomponent also contains:

                    *  A  list of applications for which the issued
certificates
                    are suitable.

                    * A list  of  applications  for  which  use  of  the
issued
                    certificates is restricted.  (This list implicitly
prohibits
                    all other uses for the certificates.)

...anybody wants to explain if the term "application" here means:

*       some specific software product (e.g. Netscape Navigator, Lotus
Domino, etc.)
*       a generic software system category that accomplish some category
of business needs (e.g. home banking, software publishing, digital
signature of disk files, etc.)

TIA to all volunteers,
   Adriano

Ing. Adriano Santoni
Direzione Rete - Servizio Progettazione Rete Logica
Societˆ Interbancaria per l'Automazione - SIA S.p.A.
Viale Certosa, 218 - I-20156 MIlano

Vox: +39 2 3005 277
Fax: +39 2 38003333
Email: [email-masked]
Website: http://www.sia.it

Date:         Mon, 26 Jan 1998 10:51:33 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Hamming, J.E." <[email-masked]>
Subject:      [IETF-PKIX] Question
To: [email-masked]
Status:

how do i remove myself from this list?

Date:         Mon, 26 Jan 1998 10:08:47 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

At 12:03 1/22/98 -0500, you wrote:
>Hi Nada,
>
>>----------
>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>Sent:  Thursday, January 22, 1998 5:26 AM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] cross-certification
>>
>>Carlisle,
>>
....

>>My additional question on second sentence in B7 is: why is publication of
>>cross-certificate responsibility of requesting CA, and not of the issuing
>>CA as in any other case?
>
>Certainly, the certificate could be published by either side.  However,
>a basic premise in this document is that the issuing CA (i.e., the one
>that actually creates and signs the certificate) has final authority
>over the certificate contents.  Thus, an EE can put anything in the
>cert. template, but the CA is free to make any modifications that it
>likes.  The same is true for the cross certification exchange.  Note,
>though, that for this particular case it may be of slightly more
>importance that the requester fully approve of all the contents of the
>certificate before it gets published.  It seemed to me that the simplest
>way to ensure this was to specify in no uncertain terms that the
>requester is the one responsible for publishing.
>

My concern is that requesting CA will not have enough privileges to publish
the cross-certificate into issuing CA's directory. (This certificate should
be published in issuing CA's directory, since it is intended to be used by
end-entities in issuing CA's domain when verifying certificates from
requester CA's domain.)

Therefore, it seems more natural to have cross-certificate published by its
issuer.

Regards,

Nada

>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Mon, 26 Jan 1998 09:12:48 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

Warwick Ford wrote:

 :The thread on cross-certification terminology did not achieve much
except
 :to confirm that many people have different views on what
 :"cross-certification" means and what needs to be done to address the
 :subject area.  We shall clearly not resolve all the issues here
quickly,
 :but there were some valuable contributions to start from.
 :
 :However, we need immediately to clarify or fix the usage of the term
in
 :PKIX 1 and CMP, since that is causing lots of confusion in the outside
 :world.
 :
 : I see two simple alternatives, and feel we should adopt one of them
 :before these documents are published as proposed standards:
 :
 :(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
 :X.509-defined term "CA-certificate"; or

This seems reasonable. However, seeing how would look the text (only for
the sections where the word is used) would be nice before a complete new
draft is re-issued.

 :(b) Explicitly define the term "cross-certificate" to be the same as
the
 :term "CA-certificate" (as defined in X.509).
 :
 :I know that not everyone agrees with (b).  For that reason, I propose
we do
 :(a), but am willing to open this up to one last round of opinions.

Charles Moore wrote:

> If we must, I would suggest the following:
>
> Cross-Certificates
> CAs may cross-certify each other,

I fear you are re-opening an issue that I thought to be closed.
Cross-certification is one way, not necessarilly bi-lateral.

> that is each issue the other a certificate
> and combine the two certificates in a single directory attribute called a
> crossCertificatePair. This crossCertificatePair attribute, supports chains
> of trust that run in both directions and implement trust models that begin
> at the CA which issued the users certificate, rather than trust models where
> trust originates from a common ãrootä. A crossCertificatePair, includes two
> certificates, forward and reverse.  The subject of  the forward certificate
> is the issuer of the reverse certificate and vice-versa.

I do not agree with the above. Warwick is pretty right when he says
"many people have different views on what "cross-certification" means.
:-)

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Mon, 26 Jan 1998 11:59:55 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, 26 January 1998 7:25
Subject: [IETF-PKIX] Cross Certification - Terminology

:The thread on cross-certification terminology did not achieve much except
:to confirm that many people have different views on what
:"cross-certification" means and what needs to be done to address the
:subject area.  We shall clearly not resolve all the issues here quickly,
:but there were some valuable contributions to start from.
:
:However, we need immediately to clarify or fix the usage of the term in
:PKIX 1 and CMP, since that is causing lots of confusion in the outside
:world.
Is it?
: I see two simple alternatives, and feel we should adopt one of them
:before these documents are published as proposed standards:
:
:(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
:X.509-defined term "CA-certificate"; or
:
:(b) Explicitly define the term "cross-certificate" to be the same as the
:term "CA-certificate" (as defined in X.509).
:
:I know that not everyone agrees with (b).  For that reason, I propose we do
:(a), but am willing to open this up to one last round of opinions.

If we must, I would suggest the following:

Cross-Certificates
CAs may cross-certify each other, that is each issue the other a certificate
and combine the two certificates in a single directory attribute called a
crossCertificatePair. This crossCertificatePair attribute, supports chains
of trust that run in both directions and implement trust models that begin
at the CA which issued the users certificate, rather than trust models where
trust originates from a common ãrootä. A crossCertificatePair, includes two
certificates, forward and reverse.  The subject of  the forward certificate
is the issuer of the reverse certificate and vice-versa.

Cross certificates provide a simple technical mechanism that may support a
number of different policies, such policies are not subject to
standardisation within PKIX.

:
:Warwick
:
:---------------------------------------------------------------------
:Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
:   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
:---------------------------------------------------------------------
:

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

Attachment converted: Lutefisk:smime.p7s 33 (????/----) (0001E315)

Date:         Sun, 25 Jan 1998 16:51:37 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
Comments:     RFC822 error: <E> Mail origin cannot be determined.
Comments:     RFC822 error: <E> Original tag data was -> Brian Franks <>
From: Undetermined origin c/o LISTSERV administrator <[email-masked]>
Subject:      [IETF-PKIX] Search Engines
To: [email-masked]
Status:

I saw your web site on the internet.  I work
for a company that submits web sites to search
engines.  We can submit your web site to over
250 of the worlds best  search engines for only
$39.95!  If you would like to put your web site in
the fast lane and get more  hits, call our 800#
or see our web page for more information.

Sincerely,

Brian Franks
NetWorld
(800) 484-2621 X5568

Date:         Sun, 25 Jan 1998 16:03:37 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

The thread on cross-certification terminology did not achieve much except
to confirm that many people have different views on what
"cross-certification" means and what needs to be done to address the
subject area.  We shall clearly not resolve all the issues here quickly,
but there were some valuable contributions to start from.

However, we need immediately to clarify or fix the usage of the term in
PKIX 1 and CMP, since that is causing lots of confusion in the outside
world.  I see two simple alternatives, and feel we should adopt one of them
before these documents are published as proposed standards:

(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
X.509-defined term "CA-certificate"; or

(b) Explicitly define the term "cross-certificate" to be the same as the
term "CA-certificate" (as defined in X.509).

I know that not everyone agrees with (b).  For that reason, I propose we do
(a), but am willing to open this up to one last round of opinions.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Sat, 24 Jan 1998 22:14:34 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] another characteristic of online validation.
To: [email-masked]
Status:

Mack Hicks wrote:
> I have to voice my agreement with Mike that cross-certification
> is not manageable (technical banking term - "scary".))
>
> An example, the trusted relationships between UNIX nodes.  One can
> make the point that the Rhost kind of trust is similar to the
> cross-certification model.  Rhost type of trust has done nothing
> but get lots of people into lots and lots of trouble.
>
> 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."
>
> Some people think banks trust each other through their Am Bnks Ass
> number (like on the checks).  Anyone who has gotten a bounced check
> knows this is not the case.  Knowing the "naming" and "addressing"
> (name constraints!) does not increase the level of trust.
>
> Keeping naming constraints current - or even manageable - is the
> full time task for lots of people in the mainframe world.
> Keeping that trust (usually in one place - like RACF or ACF2)
> is a full time job that often goes horribly wrong.
>
>
> 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?
>
> -   -    -    -    -    -    -    -    -    -    -    -    -
> Mack Hicks (415) 278-7230  -- Interactive Banking Division
> 425 1st St m/s3671, SF CA 94105 <[email-masked]>

another characteristic we've been exploring with x9.59 and aads is the
question of systemic risk introduced by inserting a dependency on
some other agency when completing a transaction. imagine a financial
institution with triple redundant implementation at three harden sites
spread around the country ... and now having to go out over the
internet and finding some CA operating in somebody's closet
in order to complete a transaction. How many people would like
to have "whether or not their paycheck got deposted in their
bank account" dependent on if a http "hit" was succesful or not.

for some of the discussion see http://www.garlic.com/~lynn/

Date:         Sat, 24 Jan 1998 16:38:13 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: D26NM061/26/M/IBM <[email-masked]>
Subject:      [IETF-PKIX] David Hemsath/Austin/IBM is out of the office.
To: [email-masked]
Status:

I am out of the office from 01/24/98, returning 02/02/98.  You will receive
only this notification of my absence prior to my return, at which time I will
respond.

Date:         Sat, 24 Jan 1998 16:03:19 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Given Jeff's comments below, perhaps it is an appropriate time to invite
all individuals/corporations participating in the PKIX work to inform us of
any other patent filings or patents granted that might impact any of the
PKIX projects.  We can do without more surprises down the track.

Warwick

At 06:38 PM 1/13/98 -0500, Jeffrey I. Schiller wrote:
>Indeed it is poor form for an individual to make contributions to a
>working group and after the group has adopted those recommendations,
>announce that the proposal is encumbered by that individual or the
>individuals company (and the individual was aware of the encumbrance at
>the time of suggestion). In other words, when you make a contribution to
>a WG, it is exactly that, a *contribution*.
>
>Some believe that because the patent application process is secret, that
>information about pending patents does not have to be revealed. This
>just isn't so. Although the patent process is secret, it is completely
>reasonable for the IETF to say "If you want to contribute a technology
>to a working group effort, then you must disclosure your interest." If
>you don't wish to disclose your interest, you don't have to make the
>suggestion!
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Fri, 23 Jan 1998 15:37:42 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: RPK New Zealand Ltd <[email-masked]>
Subject:      [IETF-PKIX] Announcement: RPK InvisiMail released on 12 Jan, 1998
To: [email-masked]
Status:

You have received this message because at some time during the past two years you have requested to be put on the RPK New Zealand Ltd. company mailing list.  (We're the Fast Public Key Encryption company).  If you wish to be removed from the list, please forward this message to [email-masked]

--------------------------------

RPK New Zealand Ltd. in a joint venture with Virtually Online Ltd. has released RPK InvisiMail, a standards-based e-mail security application for use with Internet mail software (SMTP/POP3).  The product offers the strongest encryption available anywhere in the world.  Since it was built outside the United States, it is also available all over the world with strong encryption.  RPK InvisiMail is also the easiest product of its type to setup and use which makes it quite unique.

You can learn more about this product by reading the press release below or by visiting the web site at www.InvisiMail.com.  We are also offering FREE downloads of the RPK InvisiMail Intro product.  Please give it a try and pass it along to anyone you like.

--------------------------------

For Immediate Release

Contact:        Sal Cataldi, Cataldi PR +1 212.941.9464, [email-masked], www.InvisiMail.com

RPK InvisiMail(tm), secure Internet e-mail with globally available strong encryption for Microsoft, Netscape platforms

SAN FRANCISCO, Jan. 12, 1998 - InvisiMail Ltd (www.InvisiMail.com) announced today immediate worldwide availability of RPK(tm) InvisiMail(tm), a standards-based e-mail security add-in for Microsoft, Netscape and other POP3/SMTP Internet e-mail clients and gateway servers.  Tested and certified by the International Computer Security Association (www.ncsa.com), RPK InvisiMail automatically and transparently encrypts e-mail messages and attachments, authenticates the sender and verifies the contents of each message have not been changed in transit.

RPK InvisiMail is globally available with high strength encryption.  InvisiMail and the underlying RPK encryption algorithm were developed outside the United States.  Therefore, InvisiMail is not subject to restrictive U.S. export policies.  RPK InvisiMail is as easy to set up and use as anti-virus software, and just as important.

While Microsoft and Netscape battle each other with incompatible and difficult to use security offerings, InvisiMail seamlessly integrates with ALL popular POP3/SMTP e-mail products including Netscape, Microsoft, Eudora, Pegasus, Calypso -- more than any other solution available today -- making it the preferred e-mail security product for multi-platform use, worldwide.

All InvisiMail users can send the FREE InvisiMail Intro version to anyone worldwide, providing compatibility without requiring others to purchase anything, making InvisiMail unique among
e-mail security offerings.

"Most people don't realize that their e-mail can be forged, altered or read by anyone, any time, without any evidence," said Jack Oswald, President and CEO of RPK Ltd.  "Without products like RPK InvisiMail, communications on the Internet are untrustworthy."

InvisiMail uses the RPK Fast Public Key Encryptonite(tm) Engine, the strongest cryptography available worldwide today.  RPK is dramatically faster than the well-known RSA algorithm, yet just as secure.  RPK has been analyzed by world class cryptographers who have issued reports on the security and integrity of the technology.

"InvisiMail is the easiest, fastest, most transparent e-mail security product I have seen," said Kevin Shannon, President of net*Gain, a specialist in launching Internet companies. "This is the product we've all been waiting for."

As part of its official launch, InvisiMail Professional is available FREE to all New Zealand residents for ninety days.

RPK InvisiMail is available in two desktop versions: Intro (FREE) and Professional (introductory price $29.95).  RPK InvisiMail Enterprise Gateway Server will be available Q2 1998.  InvisiMail can be downloaded from: www.InvisiMail.com.

All trademarks and registered trademarks are those of their respective companies.

***

Date:         Fri, 23 Jan 1998 09:09:59 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Kesselman, Glenn A" <[email-masked]>
Subject:      [IETF-PKIX] Please add me to the mailing list
To: [email-masked]
Status:

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD27DE.AEE2BD00
Content-Type: text/plain

Glenn A. Kesselman
Director of Western Regional Sales
Entegrity Solutions Corp.
2077 Gateway Place, Suite 200
San Jose, CA 95110
Voice: (408) 487-8600 ext. 117
Fax: (408) 487-8610
[email-masked]
http://www.entegrity.com

------ =_NextPart_001_01BD27DE.AEE2BD00
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.0.1457.3">

</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=3D2 FACE=3D"Arial">Glenn A. =
Kesselman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Director of Western Regional Sales =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Entegrity Solutions Corp.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2077 Gateway Place, Suite 200</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">San Jose, CA =
95110&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Voice: (408) 487-8600 ext. =
117&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Fax: (408) 487-8610 </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.entegrity.com" =
TARGET=3D"_blank">http://www.entegrity.com</A></FONT></U>
<BR>
<BR>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD27DE.AEE2BD00--

Date:         Fri, 23 Jan 1998 14:48:59 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] PKIX information flow ...
To: [email-masked]
Status:

Dear PKIX-list.

I have some questions, which I hope someone can answer:

Consider the PKI-scenario consiting of

     1. CA
     2. RAs
     3. a repository/directory
     4. some End Entities

Having read PKIX: Infrastructure Certificate Management Protocols, PKI
Operational Protocols- LDAPv2
and RFC 1777 (LDAP) I am under the impression, that information flowing
between the instances in such a
PKI is done through the ASN.1 structure

 PKIMessage ::= SEQUENCE {
      header           PKIHeader,
      body             PKIBody,
      protection   [0] PKIProtection OPTIONAL,
      extraCerts   [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
  }

and that information flowing between the repository/directory and end
entities alternatively
could be done through LDAPv2.

Is this correct?

Next: Does someone have experience with PKIX with information flow
building on the above PKIMessage
structure and/or LDAP (directory <--> end entities) ?

- Jakob

Alternate-recipient: Allowed
Disclose-recipients: Prohibited
Content-return: Allowed
Content-identifier: 06BC834C79B42220
Conversion: Allowed
Original-encoded-information-types: IA5-Text
Priority: normal
X400-Content-type: P2-1988 ( 22 )
X400-MTS-identifier: [/c=US/admd=attmail/; 06BC834C79B42220-attmail]
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date:         Thu, 22 Jan 1998 11:17:22 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mack Hicks <[email-masked]>
Subject:      [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme
Comments: To: Return requested <[email-masked]>
To: [email-masked]
Status:

For: IETF-PKIX Mailing list

As part of the NACHA Demonstrator for CA interoperability,
the participant banks are putting together their Certificate Practice
Stmts.  During this process, some people noted that the
IETF PKIX Part IV - CPCPSF is being often being used as an outline.
For example, the American Bar Association ISC is using the "same
numbering scheme" in their documents (or so I was so informed.)

This is really good news.
Relying parties could then look at a CP and CPS by examining known
paragraphs for information regarding such things as key size and
authentication mechanisms.

My question:

  Is the numbering being used from the PART IV itself or from the
  suggested outline?
  Your CPCPSF numbering seems to be "slightly" different.

  Since Part IV is not a standard, but a reference doc (sorry - I have
  forgotten the exact name) - should there be a recommendation within
  PKIX that CP's and CPS's follow the numbering scheme?

PS:  NACHA Demonstrator <URL:http://www.nacha.org/tic/workgrps.htm#CA>

-   -    -    -    -    -    -    -    -    -    -    -    -
Mack Hicks (415) 278-7230  -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <[email-masked]>

Date:         Thu, 22 Jan 1998 12:03:18 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Nada,

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  Thursday, January 22, 1998 5:26 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] cross-certification
>
>Carlisle,
>
>Thanks for replying to my previous messages. I the meantime I found one
>more strangeness in ipki3cmp:
>
>In 4.6.1 One-way request-response scheme of cross-certification, it is
>stated that all messages in this scheme (request/response/confirm) will be
>protected with a MAC based on a shared authentication code.
>However, Appendix B7 states that protection bits on these messages are to
>be calculated using MSG_SIG_ALG.
>
>I suppose that the proper way of protection of cross-certification messages
>is the one described in B7, and that section 4.6.1 should be modified
>accordingly.

Actually, it's the other way around:  4.6.1 is correct and B7 should be
modified to MSG_MAC_ALG.  Thanks again for your careful reading.

>My additional question on second sentence in B7 is: why is publication of
>cross-certificate responsibility of requesting CA, and not of the issuing
>CA as in any other case?

Certainly, the certificate could be published by either side.  However,
a basic premise in this document is that the issuing CA (i.e., the one
that actually creates and signs the certificate) has final authority
over the certificate contents.  Thus, an EE can put anything in the
cert. template, but the CA is free to make any modifications that it
likes.  The same is true for the cross certification exchange.  Note,
though, that for this particular case it may be of slightly more
importance that the requester fully approve of all the contents of the
certificate before it gets published.  It seemed to me that the simplest
way to ensure this was to specify in no uncertain terms that the
requester is the one responsible for publishing.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Thu, 22 Jan 1998 11:26:14 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Carlisle,

Thanks for replying to my previous messages. I the meantime I found one
more strangeness in ipki3cmp:

In 4.6.1 One-way request-response scheme of cross-certification, it is
stated that all messages in this scheme (request/response/confirm) will be
protected with a MAC based on a shared authentication code.
However, Appendix B7 states that protection bits on these messages are to
be calculated using MSG_SIG_ALG.

I suppose that the proper way of protection of cross-certification messages
is the one described in B7, and that section 4.6.1 should be modified
accordingly.

My additional question on second sentence in B7 is: why is publication of
cross-certificate responsibility of requesting CA, and not of the issuing
CA as in any other case?

Regards,

Nada

Date:         Thu, 22 Jan 1998 10:47:06 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

At 11:46 1/21/98 -0500, Carlisle Adams wrote:
>Hi Nada,
>
>>----------
>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>Sent:  Monday, January 12, 1998 8:03 AM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] mandatory PasswordBasedMac
>>
>>I have one more comment on the completeness of ipki3cmp document.
>>
>>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
>>mandatory algorithm for PKI message protection. As far as I understand, the
>>reason for specifying mandatory algorithms is for easier interoperability
>>between complying implementations. However, PasswordBasedMac (as specified
>>in section "3.1.3 PKI Message Protection") is parametrized with a
>>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
>>but for MAC different alternatives are given.
>>
>>Shouldn't the specification of mandatory algorithms make clear which
>>algorithms should be used in place of the mentioned two parameters in
>>PasswordBasedMac? What would be the preferable alternatives?
>
>Good point (thanks for noticing this)!  Yes, a particular OWF and MAC
>should be mandated for interoperability purposes.
>
>Unless there are any strong objections, I think the most sensible
>choices would be SHA-1 for the OWF (since it's already mandated as part
>of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES
>(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and
>PROT_SYM_ALG).

Well, HMAC-SHA-1 is also a valid and presumably much faster alternative to
Triple-DES-MAC. If SHA-1 is mandatory for OWF, then HMAC-SHA-1 can be a
natural choice for the MAC.

BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
anybody have a pointer to some document specifying it?

Regards,

Nada

>
>I will add this to Appendix B2.  Thanks again!
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Wed, 21 Jan 1998 15:06:28 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      [IETF-PKIX] late meeting minutes
Comments: To: Dixie Walker <[email-masked]>
To: [email-masked]
Status:

<x-rich><fontfamily><param>Times</param><bigger><bigger>PKIX WG Meeting Minutes
(12/8+10/97)

Approximately 360 attendees participated in the two PKIX WG session at

the 40th IETF.  Several of the PKIX I-Ds have been through working

group last call and have moved on to the IESG for review, but a few

issues remain and must be resolved prior to IESG approval and IETF

last call.

Part 1 (Certificate/CRL Profile)

This draft completed WG last call, but a few issues remain to be

resolved.  Issues relating to use of algorithm OIDs and some ASN.1

errors have been resolved, and the authors have avoided inclusion of

some legal language that was previously proposed.

Unresolved issues:

        - There is disagreement about wildcarding in names (e.g., DNS

and RFC 822).  A small group met to resolve this issue after the (2nd)

meeting.  That group suggested disallowing use of asterisks in these

name forms as a means of conveying the notion that the name was a

place-holder for a set of names.  Instead, a new document will be

created to describe name form conventions, on a per-application

context basis, with explicitly declared semantics, in support of the

requirements that motivated use of wildcard name forms.

        - We are using '88 ASN.1, but BMP string is a new ASN.1

construct, so this is a technical matter (but does not affect bit on

the wire format).

        - There is a related issue is use of UTF8, a new ('98 ASN.1)

character set encoding, an alternative to BMP.  This appears to be an

issue at the IESG last call level of approval, but is not an issue

among PKIX members.

        - For key usage, we propose to stay with what X.509 says,

despite disagreements over whether it is the "right" interpretation.

        - Should CRLDistributionPoint be critical, non-critical, or at

the discretion of the CA?  Currently, it cannot be marked critical,

but this can cause problems.  The concern is that if marked critical,

then a client without support for this would reject the certificate,

even if the user was willing to ignore this extension, as required by

X.509. Not resolved.

Part 2 (split into LDAP, FTP, HTTP, OCSP)

No problems with FTP or HTTP. LDAP v2 profile completed both

last calls and is to be forwarded to IESG for approval.  We agree to
add

a new work item to deal with v3, since current LDAP use in PKIX is
based

on v2.  There was a suggestion to add a work item to develop a minimal

schema for PKIX use of LDAP.  This is a possible overlap with the LDAP

WG, so coordination is required.  Later during the week the LDAP WG
chair

was contacted and it was determined that creation of a schema for use
with

PKIX was within the purview of the PKIX WG. See slides for additional
details.

Part 3 (Certificate Management Protocol)

No issues here other than the character set concerns raised under Part
1.

Certificate Request Syntax (PKCS7/10 focus)

A proposal was made to move work on this to S/MIME WG, and Schiller

and Housley (S/MIME WG chair) have no objections.  However, this work

is not S/MIME-specific and several PKIX and S/MIME WG members believe

that this work item should remain in PKIX, as it is more general.  The

fundamental question is whether CRS is a completely separate protocol,

focused on S/MIME, or if it is a profile for Part 3.  This was
subsequently

resolved [see below]. A straw poll of attendees showed a plurality of
attendees

in favor of keeping the work item in this WG, and only a single vote in
favor of

moving it to S/MIME.  The S/MIME WG, meeting two days later, concurred

with this and did not recommend adoption of CRS within that WG,
assuming that

PKIX would reconcile CRS/CMP differences and include a specification
for

securely transporting commonly-agreed certificate management messages
over

CMS (i.e., son of PKCS 7).

At the second PKIX WG meeting, a compromise approach was announced,

aimed at reconciling differences between CRS and CMP.  In essence, a

common certificate request message syntax was agreed upon, and CMP
will

adopt this syntax as the certificate request payload type within that
protocol

(replacing the current certificate request payload format).  CRS also
will be

revised to reference that syntax.  This new, harmonized certificate
request

format will appear as a separate RFC.  It is not anticipated that

this will delay the progression of CMP to proposed standard, since it
is

simply a protocol syntax change for alignment purposes, plus a
splitting of

one document into two in the interest of facilitating future
developments.

CRS will continue to progress, specifying the mapping of certificate

management messages onto CMS and providing the vehicle for producing

and RFC (or RFCs) that document agreed common formats for other
certificate management messages (i.e., messages other than certificate
request).

Time-Stamping and Notary Protocols

These are new, potential work items, discussed on a preliminary basis

in Munich.  Two presentations: Rob Zuccherato (Entrust) on time

stamping and notary functions, and Stuart Haber (Surety) on time

stamping. See slides for additional details.

Entrust- Time stamping service described here deals exclusively with

establishing existence of data (really a hash of data) at a point in

time.  Basic notary service for data demonstrates that a requester

posses data (not just a hash of the data) at a given time.  A

certificate notary service requires validation of a certificate chain

for the requester, including CRLs and ARLs.  There is also a fancy

data notarization service, encompassing data validity, and a combined

service of data possession and validity.  Some folks note that

validation of data (and certificates) is outside the scope of what

real world notaries do in the U.S. (but Latin Notaires do have broader

functions).

Surety- Stuart provided an overview of time stamping problem and

solution space, with a focus on the hash tree technology developed

(patented) and offered by Surety as a service.  The current Surety

service offers a 1 second granularity,

At least one WG member argued that the notary and time stamping

functions are not completely PKI-specific, and we should try to avoid

duplication of efforts like the PKIX/SPKI situation.  Another member

noted that there is a new I-D for time stamping via NTP, that raises

possible overlap concerns as well.  One possible outcome is a split of

time stamping vs. notary functions.  Certificate path validation, a

part of the described notary service, does make sense for PKIX,

consistent with X.509 validation procedures.

A straw poll during the second PKIX meeting showed a strong sentiment

that this WG amend its charter to include development of a standard for

time stamping, but there was not strong support for adding a work item

to develop notary functions (other than certificate path validation).
Thus an

extension of the WG charter will be proposed to the IESG in order to

address time stamping.

OCSP

Mike Myers provided a status review for this I-D, and responded to

comments that have appeared on the WG list over the last few weeks.  A

number of modifications will be made as a result of these comments

Mike described a schedule for revisions and (new) comments to bring

OCSP to WG last call in time for the next (LA) IETF meeting.  Included

in the revisions will be a better characterization of the contexts in

which OCSP are expected to operate, since that range of environments

has grown since OCSP was initially designed. To better accommodate this

diversity, a document structure was proposed that establishes a base
OCSP

document and syntax and one or more supplementary texts that build upon

the base syntax, as noted above.

</bigger></bigger></fontfamily>
</x-rich>

Date:         Wed, 21 Jan 1998 11:30:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] request for change of CertRepContent
To: [email-masked]
Status:

Hi Nada,

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  Thursday, January 08, 1998 5:22 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] request for change of CertRepContent
>
>I wonder if this is the right time to request a change in ipki3cmp format
>of the certification response message (being in the final call stage), but
>it seems to be lacking one very useful information: CRLs needed to verify
>certificates contained in the message.
>
>The inclusion of CRLs would enable certificate verification software to
>verify certificates without extra access to CRL repositories. The field can
>be made optional, so that CAs are not required to keep CRLs after
>publishing them, but in case they do keep CRLs this field may be used to
>make certificate validation process faster.
>
>The suggested format of CertRepContent is the following:
>
>  CertRepContent ::= SEQUENCE {
>      caPubs          [0] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
>  ->  crls            [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL,
>      -- CRLs corresponding to caPubs and certificates in response
>      response            SEQUENCE OF CertResponse
>  }
>
>Any comments?

Given that extra certificates can also be carried in the extraCerts
field of the PKIMessage structure, I'm not sure that CertRepContent is
the ideal place to carry the CRL (if it is carried).  My strong
preference would be to carry it in the generalInfo field of the
PKIHeader (recall that this is an optional sequence of InfoTypeAndValue
and that one of the InfoTypeAndValue contents defined in Section 3.3.18
is CurrentCRL).

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Wed, 21 Jan 1998 11:46:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

Hi Nada,

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  Monday, January 12, 1998 8:03 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] mandatory PasswordBasedMac
>
>I have one more comment on the completeness of ipki3cmp document.
>
>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
>mandatory algorithm for PKI message protection. As far as I understand, the
>reason for specifying mandatory algorithms is for easier interoperability
>between complying implementations. However, PasswordBasedMac (as specified
>in section "3.1.3 PKI Message Protection") is parametrized with a
>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
>but for MAC different alternatives are given.
>
>Shouldn't the specification of mandatory algorithms make clear which
>algorithms should be used in place of the mentioned two parameters in
>PasswordBasedMac? What would be the preferable alternatives?

Good point (thanks for noticing this)!  Yes, a particular OWF and MAC
should be mandated for interoperability purposes.

Unless there are any strong objections, I think the most sensible
choices would be SHA-1 for the OWF (since it's already mandated as part
of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES
(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and
PROT_SYM_ALG).

I will add this to Appendix B2.  Thanks again!

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 20 Jan 1998 15:33:09 +0000
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Neil Hopcroft <[email-masked]>
Subject:      [IETF-PKIX] PolicyConstraints Extension
To: [email-masked]
Status:

Looking at section 4.2.1.12 of PKIX Part 1 the ASN1 given appears not to
be complete, and, on further investigation there appears also to be a
problem with the coding in appendix A ("PolicyConstraints Syntax" not
"PolicyConstraintsSyntax"), also, should there be some kind of reference
to CertPolicySet?

I have attempted to find some archives for this list but the reference
to the FTP site on the IETF page is broken.

Thanks for you help

    Neil

Date:         Mon, 19 Jan 1998 10:46:00 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]
Status:

At 06:28 PM 1/15/98 -0500, Sharon Boeyen wrote:
>U.S. patent 5699431 is on the topic of crl distribution points and as
>such is related to PKIX.
>
>CRL distribution points are an optional item in the PKIX certificate and
>crl profiles and I don't believe there is, or should be, anything on
>distribution points which is mandated by any part of the PKIX
>specifications.

I think it is important for some competent, disinterested party to look
into this as soon as possible.  I have not seen the patent, but I know that
initial patents in a new field are usually worded quite broadly.  The
discussion in December on OCSP convinced me that, at least in the abstract,
OCSP and traditional CRLs may be viewed as endpoints on a spectrum of
configuration options for CRL distribution points.

I hope no one will interpret this comment to mean that I suspect bad faith
on the part of Entrust, quite the opposite.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Sun, 18 Jan 1998 10:03:00 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jean Pawluk <[email-masked]>
Subject:      [IETF-PKIX] IETF-PKIX membership check
Comments: cc: [email-masked]
To: [email-masked]
Status:

 In the never-ending battle to get the IETF-PKIX list up to date,
 I am sending this message to check the current membership data.

 Is anyone forwarding to a remailer using an old membership list?

 I remove people from this list and verify that they are gone, yet
 we still are receiving mail messages here saying that mail cannot
 be delivered to the people who have been removed. Well that is no
 surprise, except they have not been on this list for at least 6
 weeks, so we are wondering if anyone was using remailers.

 Thanks

 Jeanne

Date:         Fri, 16 Jan 1998 22:29:20 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     Authenticated Sender is <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] DEREGULATION OF THE U.S ELECTRIC UTILITY
Comments: To: [email-masked]
To: [email-masked]
Status:

 DEREGULATION OF THE U.S ELECTRIC UTILITY
 INDUSTRY IS CREATING A $215 BILLION FINANCIAL
 OPPORTUNITY FOR YOU!

 Imagine Utility Savings of 20% - 40%!  now imagine
 being a marketer of those savings and earning a recurring
 monthly  commission on the Utility usage of consumers
 throughout the country...

 <<<<< Call 1-800-358-2754  for 24 hr, 1 min message >>>>>

 __________________________________________________

 Effective Jan '98, Electric Utility Monopolies will be
 dissolved on a State-by-State basis opening a $215
 "Billion Dollar" industry to free-market competition.

 We need independent "Electric Power Marketers" in
 all 50 States especially California and the Northeast.
 Build a leveraged, recurring income in as little as
 10-15 hours/week.  full training and support; minimal
 start-up; lucrative.

 New Ground- Floor Opportunity with established
 international networking giant.  Capitalize now on
 projected $10 Billion in annual revenue.

 People made millions with deregulation of the
 Telecommunications Industry.  The Electric Utility
 Industry will be three times the opportunity.

 <<< Call 1-800-358-2754  for 24 hr, 1 min message >>>

 (Please do not reply via e-mail.  Call our Voicemail and
 leave your name, telephone number and the best time
 to call and we will contact you as soon as possible)

 To be removed, call the above number and SPELL your
 email address stating you would like to be removed from
 future mailings.

Date:         Thu, 15 Jan 1998 17:55:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]
Status:

RFC 2026 (aka BCP 9) has all the detail on this. Section 10.3.1, step 6, says:

The contributor represents that he has disclosed the existence of
any proprietary or intellectual property rights in the
contribution that are reasonably and personally known to the
contributor.

Section 10.3.2 specifies what kind of patent information must be made
available before something can move onto standards track. If a company is
known to have an applicable patent but has not come up with a patent
statement, that company can hold up the process of getting the document on
standards track (nudge, nudge).

--Paul Hoffman, Director
--Internet Mail Consortium

Date:         Thu, 15 Jan 1998 18:28:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]
Status:

U.S. patent 5699431 is on the topic of crl distribution points and as
such is related to PKIX.

CRL distribution points are an optional item in the PKIX certificate and
crl profiles and I don't believe there is, or should be, anything on
distribution points which is mandated by any part of the PKIX
specifications.

The patent was just issued in December and an intellectual property
statement for submission to standards bodies, as required, is nearly
complete. We do plan to make the technology covered by the patent
available  fairly and equitably. Apologies for the delay, however we
believed that the disclosure was required at issuance, not application
and that is why it is only being done now. Is there an IETF procedure or
requirements specification related to this process so we can ensure that
we follow it correctly?

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

Date:         Thu, 15 Jan 1998 11:26:47 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Whittaker <[email-masked]>
Subject:      Re: [IETF-PKIX] Looking for advise
To: [email-masked]
Status:

Good questions.  One quick note:  you don't need LDAP at all to build a
PKI.  That LDAP is used in many PKIs has to do with its desirable
characteristics as an access protocol into the directories that are used
to support those PKIs.  In those cases, LDAP is used only to obtain
verification materials, such as certificates and revocation lists;  it
is not a necessary part of verification itself.

>        I was looking to get some advice from the group to be sure I
>have everything I need. My company produces an edge router. From the
>reading I've done, it looks to me that I need to implement LDAP into our
>router and use it to verify the X.509 certificates received from remote
>peers.  Is this too simplistic a view, or is this really all I need? If
>so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm)

Do you need to use LDAP?  No, not necessarily, that depends on how your
system works....
>
>        A couple of other questions I have:
>        1. How does my router get a certificate for local peers?

This depends on the protocols used to establish connectios with local
peers.  If you are using GSSAPI, then the initial handshake transfers
the certificate; this is the case with SPKM-1 and SPKM-2.  Other
protocols (such as IPSEC?) have different methods.

> Can it be done dynamically via the add operation of a ModifyRequest?

I wouldn't think so.  I'm assuming that you are thinking of using LDAP
to talk to a directory, and not to talk to another router.  If so, then
you would use a base object search and request that the appropriate
attribute(s) (probably userCertificate) be returned.

If you were thinking of using the LDAP modify request to write the
certificate to the peer router, well, I wouldn't, because then the
router has to implement an LDAP server side as well as client, and
that's more work than you need.

If your context establishment protocol does not include certificate
exchange, you'll need to define a mechanism, one more efficient than
LDAP.

>        2. I am assuming the IP address and public key of a CA can be
>configured by the user. Is this correct?

Again, the answer is "that depends".  That depends on your PKI model and
trust architecture.  You may not have a CA at all (PGP trust model).  Or
your software may have been configured with the IP address of the CA,
and the CA gave your software a copy of its public key as part of
initialization of your PKI identity (Entrust model, one possible IPKI
model).  In the latter case, if the peer router was certified by your
CA, and your context establishment protocol provided for certificate
exchange, then you'd only need a directory access protocol to obtain the
revocation lists published by your CA, and then only if you used
revocation lists.

>        3. Are there public CAs available for testing purposes?

Various groups, too numerous to mention, have established
auto-responders and other infrastructure elements in support of testing
their specifications.  If you want to obtain certificates, there are
many sources, some of which were recently mentioned in cert-talk:

        http://www.entrust.com/webca/index.htm
        http://www.darmstadt.gmd.de/ice-tel
        http://www.secude.com/trustfactory/
        http://www.verisign.com/

To subscribe to cert-talk, see the attached message with subject
"Announcing cert-talk".

Since you are doing router work, I assume your interest is IPSEC.  You
might try contacting some IPSEC people.  Their mailing list is at

>        4. Will there be many changes between LDAPv2 and LDAPv3?

Many changes.  LDAPv3 does not mandate LDAPv2 support, and there isn't
backwards compatibility.

Your need for LDAPv3 vs LDAPv2 depends on what you are trying to do.
Note that the PKIX group has created a profile for using LDAPv2 for
repository (directory) access in an IPKI environment.  An LDAPv3 profile
will be forthcoming.

In either case, you would need to become conversant with both protocols,
but first you need to know why and whether you need LDAP at all.

>        5. Is there a workshop for X.509 compliant equipment to test for
>interoperability? (For example, There is an interoperability workshop for
>the PPP related protocols)

See the answer to question 3.

At the risk of being accused of advertising, check out the Entrust web
site for information on the Entrust/IPSEC Negotiator Toolkit.  It may
have some of the capabilities you desire.

pww

>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
>System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3401
>
>

From: "Thane E. Plambeck" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Announcing the cert-talk X.509 mailing list
Date: Wed, 10 Dec 1997 12:49:07 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

                          Announcing

                          cert-talk

            X.509 Digital Certificate Discussion List

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CHARTER:

      The cert-talk mailing list is a public, unmoderated forum
devoted to practical technical issues surrounding the use of X.509
certificates in public-key cryptography applications.

SUBJECT MATTER:

Topics of interest on cert-talk include, but are not limited to:

      * Practical problems and tools related to certificate
        manipulation:

        Import and export of certificates into applications
        Data extraction from certificates
        Certificate extension handling
        Compatibility of certificates across applications
        Revocation schemes
        Certificate storage schemes and APIs
        Distinguished name manipulation
        Certificate profiles and trust attributes
        Chain formation
        Signing and verification

      * Use of (and problems with) X.509 certificates with other
        public key technologies and networking standards such as:

        Secure Sockets Layer (SSL) and IETF TLS
        S/MIME secure electronic mail
        PKCS consortium standards
        SET (Secure Electronic Transactions)
        SKIP
        LDAP

HOW DO I SUBSCRIBE TO CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, send mail to the email address

 [email-masked]

    with the body of the message containing the single word SUBSCRIBE
    You need not put any text in the subject of your message.

    Please do not send requests to the cert-talk list itself.

ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK?

    Any mail addressed to <[email-masked]> will be sent
    to all members of the cert-talk mailing list.

HOW DO I UNSUBSCRIBE FROM CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, to remove your name from the cert-talk list send
    mail to the address

        [email-masked]

    with the message body being the single word UNSUBSCRIBE. You need
    not put any text in the body of your message.

    Please do not send requests to the cert-talk list itself.

FOR MORE INFORMATION:

              http://mail.structuredarts.com/cert-talk/

MAINTAINER:

              Structured Arts Computing Corporation
              20111 Stevens Creek Blvd, Suite 145
              Cupertino, California 95014-2345

              http://www.structuredarts.com/

              [email-masked]

Date:         Thu, 15 Jan 1998 11:29:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Whittaker <[email-masked]>
Subject:      Re: [IETF-PKIX] Looking for advise
To: [email-masked]
Status:

>
>Sorry, I forgot the IPSEC ML address.

>Good questions.  One quick note:  you don't need LDAP at all to build a PKI.
>That LDAP is used in many PKIs has to do with its desirable characteristics
>as an access protocol into the directories that are used to support those
>PKIs.  In those cases, LDAP is used only to obtain verification materials,
>such as certificates and revocation lists;  it is not a necessary part of
>verification itself.
>
>        I was looking to get some advice from the group to be sure I
>have everything I need. My company produces an edge router. From the
>reading I've done, it looks to me that I need to implement LDAP into our
>router and use it to verify the X.509 certificates received from remote
>peers.  Is this too simplistic a view, or is this really all I need? If
>so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm)
>
>Do you need to use LDAP?  No, not necessarily, that depends on how your
>system works....
>
>        A couple of other questions I have:
>        1. How does my router get a certificate for local peers?
>
>This depends on the protocols used to establish connectios with local peers.
>If you are using GSSAPI, then the initial handshake transfers the
>certificate; this is the case with SPKM-1 and SPKM-2.  Other protocols (such
>as IPSEC?) have different methods.
>
> Can it be done dynamically via the add operation of a ModifyRequest?
>
>I wouldn't think so.  I'm assuming that you are thinking of using LDAP to
>talk to a directory, and not to talk to another router.  If so, then you
>would use a base object search and request that the appropriate attribute(s)
>(probably userCertificate) be returned.
>
>If you were thinking of using the LDAP modify request to write the
>certificate to the peer router, well, I wouldn't, because then the router has
>to implement an LDAP server side as well as client, and that's more work than
>you need.
>
>If your context establishment protocol does not include certificate exchange,
>you'll need to define a mechanism, one more efficient than LDAP.
>
>        2. I am assuming the IP address and public key of a CA can be
>configured by the user. Is this correct?
>
>Again, the answer is "that depends".  That depends on your PKI model and
>trust architecture.  You may not have a CA at all (PGP trust model).  Or your
>software may have been configured with the IP address of the CA, and the CA
>gave your software a copy of its public key as part of initialization of your
>PKI identity (Entrust model, one possible IPKI model).  In the latter case,
>if the peer router was certified by your CA, and your context establishment
>protocol provided for certificate exchange, then you'd only need a directory
>access protocol to obtain the revocation lists published by your CA, and then
>only if you used revocation lists.
>
>        3. Are there public CAs available for testing purposes?
>
>Various groups, too numerous to mention, have established auto-responders and
>other infrastructure elements in support of testing their specifications.  If
>you want to obtain certificates, there are many sources, some of which were
>recently mentioned in cert-talk:
>
>       http://www.entrust.com/webca/index.htm
>       http://www.darmstadt.gmd.de/ice-tel
>       http://www.secude.com/trustfactory/
>       http://www.verisign.com/
>
>To subscribe to cert-talk, see the attached message with subject "Announcing
>cert-talk".
>
>Since you are doing router work, I assume your interest is IPSEC.  You might
>try contacting some IPSEC people.  Their mailing list is at
>mailto:[email-masked]
>
>        4. Will there be many changes between LDAPv2 and LDAPv3?
>
>Many changes.  LDAPv3 does not mandate LDAPv2 support, and there isn't
>backwards compatibility.
>
>Your need for LDAPv3 vs LDAPv2 depends on what you are trying to do.  Note
>that the PKIX group has created a profile for using LDAPv2 for repository
>(directory) access in an IPKI environment.  An LDAPv3 profile will be
>forthcoming.
>
>In either case, you would need to become conversant with both protocols, but
>first you need to know why and whether you need LDAP at all.
>
>        5. Is there a workshop for X.509 compliant equipment to test for
>interoperability? (For example, There is an interoperability workshop for
>the PPP related protocols)
>
>See the answer to question 3.
>
>At the risk of being accused of advertising, check out the Entrust web site
>for information on the Entrust/IPSEC Negotiator Toolkit.  It may have some of
>the capabilities you desire.
>
>pww
>
>
>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
>System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3401
>
>
>

From: "Thane E. Plambeck" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Announcing the cert-talk X.509 mailing list
Date: Wed, 10 Dec 1997 12:49:07 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

                          Announcing

                          cert-talk

            X.509 Digital Certificate Discussion List

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CHARTER:

      The cert-talk mailing list is a public, unmoderated forum
devoted to practical technical issues surrounding the use of X.509
certificates in public-key cryptography applications.

SUBJECT MATTER:

Topics of interest on cert-talk include, but are not limited to:

      * Practical problems and tools related to certificate
        manipulation:

        Import and export of certificates into applications
        Data extraction from certificates
        Certificate extension handling
        Compatibility of certificates across applications
        Revocation schemes
        Certificate storage schemes and APIs
        Distinguished name manipulation
        Certificate profiles and trust attributes
        Chain formation
        Signing and verification

      * Use of (and problems with) X.509 certificates with other
        public key technologies and networking standards such as:

        Secure Sockets Layer (SSL) and IETF TLS
        S/MIME secure electronic mail
        PKCS consortium standards
        SET (Secure Electronic Transactions)
        SKIP
        LDAP

HOW DO I SUBSCRIBE TO CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, send mail to the email address

 [email-masked]

    with the body of the message containing the single word SUBSCRIBE
    You need not put any text in the subject of your message.

    Please do not send requests to the cert-talk list itself.

ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK?

    Any mail addressed to <[email-masked]> will be sent
    to all members of the cert-talk mailing list.

HOW DO I UNSUBSCRIBE FROM CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, to remove your name from the cert-talk list send
    mail to the address

        [email-masked]

    with the message body being the single word UNSUBSCRIBE. You need
    not put any text in the body of your message.

    Please do not send requests to the cert-talk list itself.

FOR MORE INFORMATION:

              http://mail.structuredarts.com/cert-talk/

MAINTAINER:

              Structured Arts Computing Corporation
              20111 Stevens Creek Blvd, Suite 145
              Cupertino, California 95014-2345

              http://www.structuredarts.com/

              [email-masked]

Date:         Thu, 15 Jan 1998 10:41:41 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] Looking for advise
To: [email-masked]
Status:

        Folks,

        Thank you to everyone who has given me pointers on reading
material to get started. It has proven very helpful.

        I was looking to get some advice from the group to be sure I
have everything I need. My company produces an edge router. From the
reading I've done, it looks to me that I need to implement LDAP into our
router and use it to verify the X.509 certificates received from remote
peers.  Is this too simplistic a view, or is this really all I need? If
so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm)

        A couple of other questions I have:
        1. How does my router get a certificate for local peers? Can it
be done dynamically via the add operation of a ModifyRequest?
        2. I am assuming the IP address and public key of a CA can be
configured by the user. Is this correct?
        3. Are there public CAs available for testing purposes?
        4. Will there be many changes between LDAPv2 and LDAPv3?
        5. Is there a workshop for X.509 compliant equipment to test for
interoperability? (For example, There is an interoperability workshop for
the PPP related protocols)

        Thanks in advance for the help!

        - Gina
--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Date:         Wed, 14 Jan 1998 00:09:20 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

Steve, thanks for the clarification.

Unfortunately, I was unaware of the Novell patent that might or might not be
involved in this particular instance, and so I can't even answer from a
technical perspective whether or not the cited Novell patent might apply to
the proposed standard, and if so how or to what degree.

Until we can answer that question, of course, it is rather premature to
discuss R&D or educational use, much less licensing terms.  On the other
hand, discriminatory and/or onerous terms are probably not the ideal way to
win friends in this industry, so it is a pretty good bet that we wouldn't do
that.  Of course, I'm not an attorney, much less an intellectual property
attorney, nor am I authorized to commit the company, etc., etc.

So the answer, unfortunately, is that I will have to get back to you if you
and/or the IESG feels that this is a substantive issue.

Bob

>>> Stephen Kent <[email-masked]> 01/13/98 09:29AM >>>
Bob,

        It is the IESG's position hat standards shouldm whenever possible,
avoid the use of encumbered technology.  So, for example, there was a big
deal getting RSA to agree to allow R&D and educational use of the algorithm
in PEM, long ago.  More recently, the IESG insistend that the TLS WG make
Diffie-Hellman and DSA the default algorithms for SSL, specifically to
avoid RSA patent problems.  So, the answers to your first question is that
the IESG does want WGs to avoid use of patented technology if at all
possible.  If patented technology is incorporated into an IETF standard,
then there must be a formal statement from the patent holders about
non-discrimnatory licensing and non-onerous fees, or the IESG will reject
the standard.  Thus it is important that these issues be resolved prior to
IESG submission.

        With regard to your second question, no, it is not incumbent on
companies to review all IETF I-Ds and advise the IESG of possible patent
overlaps.  However, it is expected that WG members participating in the
development of a standards, and who are aware of patents held by their
company (or themeslves), will make the WG aware of such intellectual
property issues in the course of standards development.

        At this point I am seriously considering asking the authors to
delete portions of the relevent documents for which there may be patent
problems, so that the documents can proceed to IESG approval.

Steve

Date:         Tue, 13 Jan 1998 18:38:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Phillip M Hallam-Baker wrote:
> >Does the IESG expect some company (Novell, Nortel, etc.) to take on the
> >burden of examining some protocol and issuing a statement that said
> protocol
> >does not infringe on their patent?
>
> The IESG cannot make such a requirement, but it does very much frown
> upon companies who are aware of pending patent claims failing to
> report them while being actively involved in the development of a
> specification.

Indeed it is poor form for an individual to make contributions to a
working group and after the group has adopted those recommendations,
announce that the proposal is encumbered by that individual or the
individuals company (and the individual was aware of the encumbrance at
the time of suggestion). In other words, when you make a contribution to
a WG, it is exactly that, a *contribution*.

Some believe that because the patent application process is secret, that
information about pending patents does not have to be revealed. This
just isn't so. Although the patent process is secret, it is completely
reasonable for the IETF to say "If you want to contribute a technology
to a working group effort, then you must disclosure your interest." If
you don't wish to disclose your interest, you don't have to make the
suggestion!

As for unilateral statements. I do not make decisions in a vacuum. I
poled people individually at the Munich meeting to get the sense of the
community about encumbered vs. unencumbered technologies (where a viable
alternative was available). We then asked the plenary. The consensus was
clear, the IETF favors unencumbered technologies. This is not an
arbitrary decision of the IESG!

                         -Jeff

>
> Of course there are many reasons for filing a patent besides wanting to
> exercise it. Many patents are filed in the US simply to stop the PTO
> issuing a patent to some smart Alex ten years later.
>
> >I am reasonably certain that the IESG doesn't get involved in negotiating
> >license agreements, so I would assume that they wouldn't ask for a company
> >to waive its patent rights.
>
> Bad assumption.
>
> They tend to simply insist that any patent encumbered technology
> be deleted from the draft prior to approving it. In IETF terms this is
> equivalent to 'Go straight to editing session, do not pass Go, do not
> collect $200'.
>
> It is not unusual for the alternatives to be offered in the form 'delete
> this from the spec or undertake to not enforce the patent on
> any party excepting a party which attempts to prevent you from
> using the patented property'.
>
> This is 'negotiation' of a form but a rather one sided one in that it
> consists of a unilateral ultimatum. Jeff Schiller, the security area
> director recently issued a series of similar ultimatums to the PGP
> and S/MIME groups where there were unsolved questions of
> intellectual property in the trademark area.
>
> This is why I raised the issue on the list. Until it is resolved we
> cannot get any of the drafts affected issued as RFCs.
>
>             Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 29 (????/----) (0001E0CB)

Date:         Tue, 13 Jan 1998 17:13:52 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ronald Ogle <[email-masked]>
Organization: Operational Research Consultants Inc.
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

David P. Kemp wrote:

> > From: Bob Jueneman <[email-masked]>
> >
> > If you recall, you [Warwick] were the one who convinced me of the elegance of the
> > policy OID constraint approach to certificate chaining, pointing out that it
> > allowed the user himself, (or his IT organization) to create a certificate
> > which effectively serves as his own local (unpublished) TLCA and
> > cross-certifies other CAs, without requiring access to some kind of a local
> > database of trusted CAs to validate each certificate.  A suitable trusted
> > smart card, a la Fortessa, containing a trusted public key or self-signed
> > certifcate, could feasibly implement the relying party's trust policy
> > without requiring a trusted operating system host.
> .......

> We have been grappling with the problem of reconciling three PKI models
> into a coherent concept of operations for a PKI to serve Federal Government
> users:
>  * single-rooted heirarchy (DMS / MISSI v1),
>  * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI v2)
>  * single-level certification with each user configuring a list of
>     "trusted" CAs (the current web browser model)
>

Wouldn't there also be a case for inter-domain certification  (point 2) at other
subordinate "chained" CA levels and not just at the root level?  For example, if you
have a "Federal Root CA" that signs all other Government CAs, in this case the DoD CA,
wouldn't you want the DoD CA to be able to inter-domain certify with other CA Roots
instead of requiring the inter-domain certification to take place at the Federal Root
CA.

Just my opinion.
Ron Ogle

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ronald Ogle
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 4 (TEXT/R*ch) (0001E0CA)

Date:         Tue, 13 Jan 1998 14:07:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: Robert Jueneman <[email-masked]>
To: [email-masked]
Status:

>I'm not entirely sure what you are asking, perhaps because I am rather
>ignorant of what the IESG's position is vis a vis patents and standards.
>
>Does the IESG insist on standards avoiding any existing patents?  In that
>case, what do they do about RSA, etc?

In general the IESG is very reluctant to approave any standard that does not
meet their deffinition of 'open'. In particular they will in general insist
that a
specification be implementable using patent free technology wherever
possible,
PEM was a rare case in which they considered the RSA/Diffie Helleman
patent essential.

In any case whenever a protocol is encumbered in some way by a protocol
they insist on an intellectual property statement and an undertaking to
license the patent according to non discriminatory terms.

>Does the IESG expect some company (Novell, Nortel, etc.) to take on the
>burden of examining some protocol and issuing a statement that said
protocol
>does not infringe on their patent?

The IESG cannot make such a requirement, but it does very much frown
upon companies who are aware of pending patent claims failing to
report them while being actively involved in the development of a
specification.

Of course there are many reasons for filing a patent besides wanting to
exercise it. Many patents are filed in the US simply to stop the PTO
issuing a patent to some smart Alex ten years later.

>I am reasonably certain that the IESG doesn't get involved in negotiating
>license agreements, so I would assume that they wouldn't ask for a company
>to waive its patent rights.

Bad assumption.

They tend to simply insist that any patent encumbered technology
be deleted from the draft prior to approving it. In IETF terms this is
equivalent to 'Go straight to editing session, do not pass Go, do not
collect $200'.

It is not unusual for the alternatives to be offered in the form 'delete
this from the spec or undertake to not enforce the patent on
any party excepting a party which attempts to prevent you from
using the patented property'.

This is 'negotiation' of a form but a rather one sided one in that it
consists of a unilateral ultimatum. Jeff Schiller, the security area
director recently issued a series of similar ultimatums to the PGP
and S/MIME groups where there were unsolved questions of
intellectual property in the trademark area.

This is why I raised the issue on the list. Until it is resolved we
cannot get any of the drafts affected issued as RFCs.

            Phill

Date:         Tue, 13 Jan 1998 12:34:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

At 06:33 PM 1/12/98 -0400, Ronald Ogle wrote:
>Well, I don't know about that.  You may be familiar with Caller ID on the
>telephone.  With Caller ID, you can send the caller to a message stating that
>you will not answer the phone unless he/she publishes his/her phone number to
>your Caller ID service.  Abstract this idea out to e-mail.  If the e-mail
sender
>does not sign the e-mail, then an e-mail is sent back stating that the
recipient
>will not except unsigned e-mail.  Also, you could have a filter based on the
>signature that would reject or at least but the e-mail in a location that was
>unobtrusive.  So just like an unwanted phone call, an unwanted e-mail can
now go
>into the perverbial bit bucket without human intervention.

I am afraid I must agree with Perry. I don't think this approach will work
for long or work for most people.  Basically, you will have to either list
who you will receive from (inclusion), or who you will NOT receive from
(exclusion).  In either case, you will soon be administering large
unmanagable lists.

Further, inclusion will exclude mail you really want.  For example, I have
frequently been contacted by old friends and acquaintences who saw my
posting somewhere, or got my address from a mutual friend.  Or consider the
common case of starting a side discussion with another subscriber to a
mailing list.

Exclusion just puts you in the same old game of continous catch up with the
spammers.  As Perry points out, there is no reason to believe that they
will not be able to obtain digital identities (certs) for their many and
varied pseudonyms with the same level of assurance as your friends will get
for their real identities.

I am increasingly becoming convinced that any successful strategy against
spam will have to be economic in nature.  Other steps may temporarily slow
them down, but are at best stopgap.

>Perry E. Metzger wrote:
>
>> Andrew Csinger writes:
>> > Although somewhat off-topic, I think it's important to note in passing
>> > that
>> >
>> > PKI is ultimately the <bold><italic>solution</italic></bold> to the
>> > problem of SPAM,
>>
>> Not likely. Just because you can then verify that one of
>> Spamford Wallace's 7000 aliases sent the mail message doesn't mean it
>> does you any good to know where it came from.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 13 Jan 1998 11:29:03 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Bob,

        It is the IESG's position hat standards shouldm whenever possible,
avoid the use of encumbered technology.  So, for example, there was a big
deal getting RSA to agree to allow R&D and educational use of the algorithm
in PEM, long ago.  More recently, the IESG insistend that the TLS WG make
Diffie-Hellman and DSA the default algorithms for SSL, specifically to
avoid RSA patent problems.  So, the answers to your first question is that
the IESG does want WGs to avoid use of patented technology if at all
possible.  If patented technology is incorporated into an IETF standard,
then there must be a formal statement from the patent holders about
non-discrimnatory licensing and non-onerous fees, or the IESG will reject
the standard.  Thus it is important that these issues be resolved prior to
IESG submission.

        With regard to your second question, no, it is not incumbent on
companies to review all IETF I-Ds and advise the IESG of possible patent
overlaps.  However, it is expected that WG members participating in the
development of a standards, and who are aware of patents held by their
company (or themeslves), will make the WG aware of such intellectual
property issues in the course of standards development.

        At this point I am seriously considering asking the authors to
delete portions of the relevent documents for which there may be patent
problems, so that the documents can proceed to IESG approval.

Steve

Date:         Mon, 12 Jan 1998 18:33:57 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ronald Ogle <[email-masked]>
Organization: Operational Research Consultants Inc.
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
Comments: To: [email-masked]
To: [email-masked]
Status:

Well, I don't know about that.  You may be familiar with Caller ID on the
telephone.  With Caller ID, you can send the caller to a message stating that
you will not answer the phone unless he/she publishes his/her phone number to
your Caller ID service.  Abstract this idea out to e-mail.  If the e-mail sender
does not sign the e-mail, then an e-mail is sent back stating that the recipient
will not except unsigned e-mail.  Also, you could have a filter based on the
signature that would reject or at least but the e-mail in a location that was
unobtrusive.  So just like an unwanted phone call, an unwanted e-mail can now go
into the perverbial bit bucket without human intervention.

Perry E. Metzger wrote:

> Andrew Csinger writes:
> > Although somewhat off-topic, I think it's important to note in passing
> > that
> >
> > PKI is ultimately the <bold><italic>solution</italic></bold> to the
> > problem of SPAM,
>
> Not likely. Just because you can then verify that one of
> Spamford Wallace's 7000 aliases sent the mail message doesn't mean it
> does you any good to know where it came from.
>
> Perry

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ronald Ogle
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 3 (TEXT/R*ch) (0001DEBE)

Date:         Mon, 12 Jan 1998 11:52:32 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki2opp-06.txt
Comments: To: [email-masked]
To: [email-masked]
Status:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the Public-Key
Infrastructure (X.509) Working Group of the IETF.

        Title           : Internet X.509 Public Key Infrastructure Operational
                          Protocols - LDAPv2
        Author(s)       : T. Howes, S. Boeyen, P. Richard
        Filename        : draft-ietf-pkix-ipki2opp-06.txt
        Pages           : 12
        Date            : 09-Jan-98

     The protocol described in this document is designed to satisfy some
     of  the  operational  requirements within the Internet X.509 Public
     Key Infrastructure (IPKI).  Specifically, this  document  addresses
     requirements  to  provide access to Public Key Infrastructure (PKI)
     repositories for the purposes of  retrieving  PKI  information  and
     managing  that  same  information.  The mechanism described in this
     document is based on  the  Lightweight  Directory  Access  Protocol
     (LDAP) v2, defined in RFC 1777, defining a profile of that protocol
     for use within the IPKI and updates encodings for certificates  and
     revocation  lists  from  RFC 1778. Additional mechanisms addressing
     PKIX operational requirements are specified in separate documents.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ipki2opp-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-06.txt

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za

        Europe: ftp.nordu.net
                ftp.nis.garr.it

        Pacific Rim: munnari.oz.au

        US East Coast: ds.internic.net

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ipki2opp-06.txt".

NOTE:   The mail server at ds.internic.net can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID:     <[email-masked]>

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get [IETF-PKIX] I-D ACTION-dr 1 (EuSn/CSOm) (0001DEA9)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki2opp-06.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki2opp-06 (AURL/Arch) (0001DEAA)
Content-Type: text/plain
Content-ID:     <[email-masked]>

Date:         Mon, 12 Jan 1998 14:03:06 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

I have one more comment on the completeness of ipki3cmp document.

In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
mandatory algorithm for PKI message protection. As far as I understand, the
reason for specifying mandatory algorithms is for easier interoperability
between complying implementations. However, PasswordBasedMac (as specified
in section "3.1.3 PKI Message Protection") is parametrized with a
one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
but for MAC different alternatives are given.

Shouldn't the specification of mandatory algorithms make clear which
algorithms should be used in place of the mentioned two parameters in
PasswordBasedMac? What would be the preferable alternatives?

Regards,

Nada
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Mon, 12 Jan 1998 00:13:33 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

I'm not entirely sure what you are asking, perhaps because I am rather
ignorant of what the IESG's position is vis a vis patents and standards.

Does the IESG insist on standards avoiding any existing patents?  In that
case, what do they do about RSA, etc?

Does the IESG expect some company (Novell, Nortel, etc.) to take on the
burden of examining some protocol and issuing a statement that said protocol
does not infringe on their patent?

I am reasonably certain that the IESG doesn't get involved in negotiating
license agreements, so I would assume that they wouldn't ask for a company
to waive its patent rights.

Maybe we ought to hear from the Area Director on this issue.

Bob

>Bob Jueneman wrote:
>
>[details of Silvios patents deleted]
>
>Since you are Novell Bob, perhaps you could find out about the intention
>and interpretation of the Novell patent?
>
>http://patent.womplex.ibm.com/details?patent_number=5687235
>5687235 : Certificate revocation performance optimization
>
>INVENTORS:
>              Perlman; Radia J., Acton, MA
>              Reed; Edwards E., Lindon, UT
>              Carter; Tammy G., Pleasant Grove, UT
>ASSIGNEES:
>              Novell, Inc., Orem, UT
>ISSUED:
>              Nov. 11, 1997
>
>                                  FILED:
>                                       Oct. 26, 1995
>
>ABSTRACT:   The present invention is an improved certificate revocation
>process that improves the efficiency of an authentication exchange in a
>public key distributed network system. Specifically, the present
>invention includes a novel revocation service (RS) that, in response to
>a unique request from a server node, selects certain revoked
>certificates from a current CRL to include in its reply so as to consume
>minimal system bandwidth
>
>
>It would also be handy if someone from Entrust or Nortel could give some
>information about their intentions concerning their CRL distribution
>points patent.
>
>
>Needless to say this is all going to have to be sorted out before the
>IESG accepts the PKIX standards.

Date:         Sun, 11 Jan 1998 23:56:12 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

>> From: Bob Jueneman <[email-masked]>
>>
>> If you recall, you [Warwick] were the one who convinced me of the
elegance of the
>> policy OID constraint approach to certificate chaining, pointing out that
it
>> allowed the user himself, (or his IT organization) to create a
certificate
>> which effectively serves as his own local (unpublished) TLCA and
>> cross-certifies other CAs, without requiring access to some kind of a
local
>> database of trusted CAs to validate each certificate.  A suitable trusted
>> smart card, a la Fortessa, containing a trusted public key or self-signed
>> certificate, could feasiblely implement the relying party's trust policy
>> without requiring a trusted operating system host.
>>
>> This way the RP has only his own public key to trust, and the IT
>> organization doesn't have to run around the country or the world
populating
>> new trusted TLCA keys into client software every time a new CA pops up or
a
>> key is replaced. They merely post new certificates on an untrusted
directory
>> or repository, to be downloaded as needed.
>
>
>I quite agree, and am surprised that this approach to PKI organization
>has not been more widely publicized, or documented (as an informational
>appendix or RFC, not as normative text) in PKIX.  Bob, this is the
>clearest statement I've seen yet of the advantages of the "domain
>administrator" (or "local TLCA") model - may I quote you?

In general, I assume that anything posted to a _public _ list such as this
is said on the record, and as such may be quoted without explicit
permission.  But thanks for the courtesy of asking.
>
>We have been grappling with the problem of reconciling three PKI models
>into a coherent concept of operations for a PKI to serve Federal Government
>users:
> * single-rooted hierarchy (DMS / MISSI v1),
> * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI
v2)
> * single-level certification with each user configuring a list of
>    "trusted" CAs (the current web browser model)
>
>The local-TLCA model, if supported by commercial product vendors, would
>satisfy the needs of individual users to choose who they trust (and
>also make trust decisions more explicit by requiring the user to issue
>a cert to each CA in the list, and allow finer granularity of control,
>if desired, by including name and policy constraints in the
>user-generated certs).
>
>It would also satisfy the needs of organizations to inject some
>assurance into the PKI management process, and allow control of some
>functions to be delegated to lower levels while retaining control over
>other functions (such as organizational messaging, high-value
>contracts, etc) at the organizational level.
>
>Dave Kemp

I think that I have described a further extension to this general paradigm,
certainly in person at a Federal PKI meeting and on some legal lists, but I
don't recall whether I discussed it on the PKIX list.  So let me elaborate
somewhat.

I am increasingly convinced that despite whatever benefits might accrue from
the official licensing of CAs a la the Utah Digital Signature Act, it is not
likely to extend or scale very well.  Although I currently live in Utah, I
would not claim that it was the hub of the universe with respect to
electronic commerce.  I therefore doubt that there will be a huge rush for
every CA in the world to sign up as a Utah-licensed CA.  The same is
probably true of Florida, Washington, Illinois, and the other states which
Utah-like legislation, much less the "minimalist" states such as California,
Massachusetts, etc.

What might happen, however, is that some of those states, some governmental
agencies, and perhaps some industry associations, might either formally or
informally publish a set of reasonable set of criteria for what constitutes
a reasonable set of operational practices for a CA.  (The ABA Information
Security committee -- the group that wrote the Digital Signature Guidelines
-- is presently addressing a set of Guidelines for CA accreditation that may
eventually form the basis for such an effort.)

Assuming that some reasonably small set of criteria are developed, _and_
assuming that those same organizations develop some form of auditing and/or
other on-going oversight is put into place, it is my hope that these
accrediting agencies can from the basis for an international PKI trust
infrastructure.  Although I am not an attorney, I believe that the
differences in the various legal systems throughout the world, together with
national sovereignty issues, are too great as to ever allow a prescriptive
set of standards to be put into place.

So instead of an international set of "thou-shalt"  laws or regulations
being passed, the basis for mutual trust will be much closer to the way that
a bond rating organization such as Standard and Poors operates.  In other
words, the accrediting agency will issue a non-liability bearing memorandum
of opinion about a CA's practices, and based on that opinion and the
recognition that the CA is at least a bona fide organization, individual
relying parties (or relying organizations) will decide for themselves
whether that CA's certificate form an adequate basis of trust for certain
classes of transactions, or not.

Now, how would this system operate in an individual-TLCA paradigm (to use
your terminology -- as good as any I've seen)?

Well, suppose I had three different types of transactions I might want to
decide whether to accept as a relying party.  Maybe one is a routine e-mail
attribution, not unlike what is presumably intended by those who use PGP to
sign their contributions.  They don't intend that their utterances be
interpreted as a legally binding contract, and I as a relying party don't
view that way either, except to make sure that someone isn't playing games
and impersonating someone else.

My second type of transaction might be intra- and intercorporate business
correspondence -- not formal purchase orders, bids, or other "EDI"
transactions -- just normal business correspondence that is routinely signed
to convey good faith in negotiations. Although not common, such
"transactions" have the potential to end up in court is there is ever a
serious disagreement about the intent of the parties.  another example of
the level of transaction might be to digitally sign a tax return, to file an
insurance claim, etc.

Finally, there is the really serious applications, e.g., for selling your
house, signing your will, or other big ticket items.  For businesses,
perhaps this level of transaction is the over-$100,000 (or maybe over $1
million) type of transaction.

Now, having analyzed my security/reliance requirements and reduced them down
to perhaps overly-simplistic essence, I might create three different
unpublished,, self-signed, TLCA certificates, each containing a unique
policy OID (unique to and known only by me).  I'll refer to those policies
as my Red, White, and Blue policies.

Now then, once I have reviewed the legal and technical aspects of say
VeriSign's Certificate Practice Statement in detail, I might conclude that
both their Class 1 and their Class 2 certificates satisfy my Red policy,
that their Class 3 certificate satisfies my White
policy, but that they don't yet have a class that would satisfy my Blue
category.

I could then cross certify VeriSign's certificates (unilaterally, without
necessarily contracting with VeriSign for this purpose), using policy
mapping plus a critical policy OID constraint to control which of VeriSign's
certificates I would accept.

Likewise, I might decide that Utah's licensed CAs would satisfy my Blue
criteria.

But going beyond the current status quo, sometime next year, Utah might
decide that the Washington State, Florida, MISSI, and German Government CA's
satisfy the criteria for a Utah licensed CA, and Utah might cross-certify
those other CAs, either unilaterally or bilaterally, again using policy
mapping.  Maybe they make up a series of policies, say Pearl, Ruby, and
Diamond.

And some other CA rating agency make up some other criteria, say
Classic/Green/Brass, Gold, and Platinum, etc., etc.

Assuming the various rating agencies invest the necessary legal and
technical effort into comparing the various policies and coming up with some
simplifying ratings, I would hope that I could eventually chain from my own
personal "Red" policy criteria to Utah's "Ruby" to MISSI's Gold policy, etc.

I may be asking a lot for the creation of these policy rating efforts, but I
think it is a lot more reasonable and feasible than having various CA's
actually undertake some level of liability for some other CAs actions, much
less some state agency or industry association.

In any case, assuming that these approximate correspondences can ultimately
be established, the use of an individual TLCA plus policy mapping and policy
constraints certainly appears to offer the necessary controls necessary to
implement a more or less automatic, lights-out approach to certificate
validation.  By switching contexts as to which self-signed TLCA certificate
is acceptable for a given type of transaction (perhaps based on the
transaction amount), all of the rest of the certificate validation process
should be capable of being completely automated and deterministic.

At least that is the challenge.  Now, I believe that what we ought to do is
hold up the detailed text to a critical examination along these lines, and
ask the nitty-gritty operational questions. For example, I haven't discussed
the role of policy parameters, and whether some form of mapping is needed
there.  How, for example, do we compare two reliance limit policy parameters
if one is in US dollars and the other is in French francs?

I'm sure there is more work to be done, but I think this is a good starting
point.

And by the way, I tend to believe that these kinds of examples _do_ belong
in the PKIX document. Too often, I believe, we tend to take out these kinds
of how-we-got-there steps, and only present the bare bones conclusions.  All
too often, that tends to make those who look at these issues later reinvent
the wheel, sometimes in a surprisingly different shape.

Bob

Date:         Fri, 9 Jan 1998 15:35:32 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Bob Jueneman wrote:

[details of Silvios patents deleted]

Since you are Novell Bob, perhaps you could find out about the intention
and interpretation of the Novell patent?

http://patent.womplex.ibm.com/details?patent_number=5687235
5687235 : Certificate revocation performance optimization

INVENTORS:
              Perlman; Radia J., Acton, MA
              Reed; Edwards E., Lindon, UT
              Carter; Tammy G., Pleasant Grove, UT
ASSIGNEES:
              Novell, Inc., Orem, UT
ISSUED:
              Nov. 11, 1997

                                  FILED:
                                       Oct. 26, 1995

ABSTRACT:   The present invention is an improved certificate revocation
process that improves the efficiency of an authentication exchange in a
public key distributed network system. Specifically, the present
invention includes a novel revocation service (RS) that, in response to
a unique request from a server node, selects certain revoked
certificates from a current CRL to include in its reply so as to consume
minimal system bandwidth

It would also be handy if someone from Entrust or Nortel could give some
information about their intentions concerning their CRL distribution
points patent.

Needless to say this is all going to have to be sorted out before the
IESG accepts the PKIX standards.
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 28 (????/----) (0001DE9E)

Date:         Fri, 9 Jan 1998 15:26:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Management protocols and base64 encoding
To: [email-masked]
Status:

Tomas Gustavsson wrote:
>
> In draft-ieft-pkix-ipki3cmp-06.txt there is specified how messages should be
> transported over email and http. For http is says:
>
> Content-Type: application/pkixcmp
> <<the ASN.1 DER-encoded PKIX-CMP message>>
>
> while it is base64 encoded for email. I would like to allow base64 encoding
> also for http based transports. One reason for this is that with some windows
> based web servers we have had problems returning binary data undamaged from
> cgi programs. It is not very hard to make automatic detection if the received
> data is base64 encoded or not.

I really don't think that the spec should attempt to vary the HTTP
specification.
HTTP permits base64 encoding but does not require clients to be able to
interpret it. We designed HTTP to be 8-bit clean and have been extreemly
definite about keeping it that way.

If your server cannot provide an 8-bit clean communication with a plug
in
application that is a bug that is your responsibility. The purpose of
IETF
standards is to standardize communications over the network where it is
very
difficult to change infrastructure.

Mangling a spec to provide backwards compatibility with internal
infrastructure that can be upgraded by the person with the problem has
never been accepted as important.

It appears that your problem is using CGI which was developed as a
solution for UNIX based systems on a Windows platform. The only
reason CGI was invented was because UNIX support for shared
libraries was incomplete at the time.

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 27 (????/----) (0001DE9D)

Date:         Fri, 9 Jan 1998 10:33:11 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Walter Enos <[email-masked]>
Subject:      [IETF-PKIX] (pure) Java implementations of PKIX?
To: [email-masked]
Status:

Are any Java implementations available today,
or are implementations planned to be available
once the standard is finalized?

I haven't seen any vendor announcements yet-
can anyone shed some light on this for me?
Thanks!
Walter
__________________
Walter Enos
904 Los Robles Avenue
Palo Alto, CA 94306
email:  [email-masked]

Date:         Fri, 9 Jan 1998 10:35:28 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

> From: Bob Jueneman <[email-masked]>
>
> If you recall, you [Warwick] were the one who convinced me of the elegance of the
> policy OID constraint approach to certificate chaining, pointing out that it
> allowed the user himself, (or his IT organization) to create a certificate
> which effectively serves as his own local (unpublished) TLCA and
> cross-certifies other CAs, without requiring access to some kind of a local
> database of trusted CAs to validate each certificate.  A suitable trusted
> smart card, a la Fortessa, containing a trusted public key or self-signed
> certifcate, could feasibly implement the relying party's trust policy
> without requiring a trusted operating system host.
>
> This way the RP has only his own public key to trust, and the IT
> organization doesn't have to run around the country or the world populating
> new trusted TLCA keys into client software every time a new CA pops up or a
> key is replaced. They merely post new certificates on an untrusted directory
> or repository, to be downloaded as needed.

I quite agree, and am surprised that this approach to PKI organization
has not been more widely publicized, or documented (as an informational
appendix or RFC, not as normative text) in PKIX.  Bob, this is the
clearest statement I've seen yet of the advantages of the "domain
administrator" (or "local TLCA") model - may I quote you?

We have been grappling with the problem of reconciling three PKI models
into a coherent concept of operations for a PKI to serve Federal Government
users:
 * single-rooted heirarchy (DMS / MISSI v1),
 * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI v2)
 * single-level certification with each user configuring a list of
    "trusted" CAs (the current web browser model)

The local-TLCA model, if supported by commercial product vendors, would
satisfy the needs of individual users to choose who they trust (and
also make trust decisions more explicit by requiring the user to issue
a cert to each CA in the list, and allow finer granularity of control,
if desired, by including name and policy constraints in the
user-generated certs).

It would also satisfy the needs of organizations to inject some
assurance into the PKI management process, and allow control of some
functions to be delegated to lower levels while retaining control over
other functions (such as organizational messaging, high-value
contracts, etc) at the organizational level.

Dave Kemp

Date:         Thu, 8 Jan 1998 14:51:37 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tomas Gustavsson <[email-masked]>
Subject:      [IETF-PKIX] Management protocols and base64 encoding
To: [email-masked]
Status:

In draft-ieft-pkix-ipki3cmp-06.txt there is specified how messages should be
transported over email and http. For http is says:

Content-Type: application/pkixcmp
<<the ASN.1 DER-encoded PKIX-CMP message>>

while it is base64 encoded for email. I would like to allow base64 encoding
also for http based transports. One reason for this is that with some windows
based web servers we have had problems returning binary data undamaged from
cgi programs. It is not very hard to make automatic detection if the received
data is base64 encoded or not.

Anyone else has any feelings about this?

Regards,
Tomas Gustavsson
Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corp.)
Email: [email-masked]
Tel: +46 8 477 7740
Fax: +46 8 477 7731

Date:         Thu, 8 Jan 1998 11:22:19 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      [IETF-PKIX] request for change of CertRepContent
To: [email-masked]
Status:

I wonder if this is the right time to request a change in ipki3cmp format
of the certification response message (being in the final call stage), but
it seems to be lacking one very useful information: CRLs needed to verify
certificates contained in the message.

The inclusion of CRLs would enable certificate verification software to
verify certificates without extra access to CRL repositories. The field can
be made optional, so that CAs are not required to keep CRLs after
publishing them, but in case they do keep CRLs this field may be used to
make certificate validation process faster.

The suggested format of CertRepContent is the following:

  CertRepContent ::= SEQUENCE {
      caPubs          [0] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
  ->  crls            [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL,
      -- CRLs corresponding to caPubs and certificates in response
      response            SEQUENCE OF CertResponse
  }

Any comments?

Regards,

Nada
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Wed, 7 Jan 1998 10:28:18 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
Comments: To: [email-masked]
To: [email-masked]
Status:

>>> Tomaz> Klobucar <[email-masked]> 01/07 7:01 AM >>>
>Although there was a long discussion about certificate policies on this
list
>I am still a bit bemused, especially about recognizing and supporting
>certificate policies extensions (critical or non-critical). I would
>appreciate if someone could explain the following case. Let us suppose
>that a CA has published two policies for signing bills in certain company.
>One is used for bills where amount is less than 1000$ and does not specify
>how private keys must be protected. The other policy specifies
>rules for keys which can be used to sign bills over 1000$. These keys must
be
>stored on smartcards. The CA then issues certificates where one of this
>certificate policies is flagged critical. Should signing applications and
>applications for validating signatures which claim to support these
policies
>check the amount in each bill during signing procedure or signature
>validation? Must applications be able to verify if the signing key is
properly
>stored?
>
>Regards, Tomaz

Tomaz, let me take a crack at this. Others may jump in if they disagree.

First of all , when you say that the CA has published policies for signing
bills, I assume that what you really mean is that the Controller or other
management official within the company has decided what the policy must be,
and that the CA and others are directed to implement that policy, whether
the CA is internal to the company or outsourced.

The CA therefore will issue certificates with either of two flavors of
policy OIDs -- either "gold" for high value transactions, or "brown" for low
value transactions.  More likely, there will be a "gold" OID and no OID.

The rule for the relying party's software is simple.  The application which
processes bills has to look at the amount involved, and then decide whether
the appropriate evidence exists to approve the transaction.  So far, this
has NOTHING to do with the certificate infrastructure -- this is a
requirement laid on the application software and the software
developers/purchasers by the Controller, not by the certificate policy.

Assuming that the transaction amount is over $1000, the application has to
instruct the crypto API as to what kind of digital signatures to accept,
i.e., what kind of certificates are acceptable. The crypto API could
reference a local database of acceptable certificates, of course, but I
believe that your question assumed the use of the PKIX/X.509 infrastructure
without any trusted databases.

The way I would solve that problem if I were implementing the code would be
to provide two different contexts or API calls, one of which would specify
one self-signed certificate, and one of which would specify another.

The first self-signed certificate, effectively issued by the MIS department
responsible for overseeing the implementation of the controller's policy,
would contain a "gold" policy OID constraint which is marked Critical, and
would cross-certify the normal corporate CA's root key, or perhaps some
external CA's certificate. By virtue of the policy OID constraint, only
certificates containing a matching policy OID would be deemed acceptable,
whether issued by the top level corporate CA or some subordinate CA.
Importantly, however, the certificate of the end-user who is signing the
bill would (must) contain the matching policy OID.  Because the original
policy OID constraint was marked Critical, the relying party's software
would be forced to check that all of the certificates in the chain contained
the appropriate policy OID attribute.

The other self-signed certificate would either contain a "brown" policy OID
constraint, which might or might not be marked Critical, or more likely it
would not contain a policy OID constraint at all.

By dynamically switching between these two contexts on a transaction by
transaction basis, the relying party's software can ensure that for a given
transaction, the right kind of digital signature/certificate chain was used,
and ergo the right kind of protection was being given for the private key.

But the other portion of your question addressed the enforcement of the
policy at the time of signing, and that is a different question entirely.

When the CA binds the end-user's public key in a certificate, then in the
case of a "gold" policy OID, the CA is duty bound to ensure that only those
key storage devices which conform to the policy can be used to generate,
store, or access the corresponding private keys.  How the CA determines
and/or ensures that fact is its own business, but is presumably specified as
part of the overall policy which is referenced by the policy OID.

In most cases this will probably involve a representation by the end-user to
the CA that the key in question is properly stored, never accessed in the
clear, etc., and that may suffice -- especially if misrepresenting the facts
to the CA is grounds for firing the employee! Ultimately, as the
infrastructure evolves, devices such as smart cards, and even software
implementations, may protect the keys in such a way as to prevent their
disclosure outside of the minimum acceptable environment.

So now the user -- the one who is signing the bills originally -- either has
two keys, a good one and a not so good one, or they only have one or the
other, perhaps depending on their status in the company.

If they only have one key, of course there isn't much of a problem.  If
someone tries to sign a transaction over $1000 and doesn't have the right
kind of key, the transaction won't validate at the other end, and after
couple of such instances he won't do that again, or else.

If he has two keys, and the signing application is supposed to be
sufficiently intelligent to switch between the two keys based on the amount
of the transaction, that is more complicated. The two context solution could
still be used, in this case switching between the two signing keys. But this
is still sort of a scout's honor type of solution -- the enforcement is done
by the verifying application based on the policy OID in the certificate, and
not by the signing application where it probably ought to be done.

That is why, in one of my previous messages, I urged that the constraints in
the certificate be interpreted by the SIGNING application as well, prior to
using the corresponding private key to sign something. That would prevent
the signing application from using an encryption key instead of a signing
key, for example. And if the policy OID constraint is marked critical, the
signing application ought to be in an appropriate context before using that
key.

So, for example, if the application sees an amount that is over $1000, it
would switch contexts, examine the certificate that goes with the key that
is about to be used for signing, and either accept or reject that particular
signing operation accordingly.

I hope this answers your question.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

Date:         Wed, 7 Jan 1998 14:12:20 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

At least with respect to the second patent that Al mentioned, before someone
automatically concludes that Dr. Micali's patent is valid, they ought to go
back through the PEM archives for the dialogue between Sead Muftic and
myself, probably in the 1995 time period, where we were discussing something
very similar to what that patent appears to cover.

Likewise, I'm a little surprised by the registration agent patent. I thought
that was a pretty well developed concept in the DMS architecture, as well as
being pretty obvious. but I haven't examined the claims in detail, so maybe
there is more there than meets the eye.

It isn't clear to me how careful a job was done of looking at unpatented
prior art prior to issuing several of these patents. Before I shelled out a
lot of money for licenses in this area, I might talk to a good attorney
about the possibility of attacking the validity of these patent(s). At the
same time, I don't mean to suggest that any kind of inappropriate behavior
occurred on Dr. Micali's part -- lots of cases in the past have involved two
or more inventors coming up with essentially the same invention
independently, at more or less the same time, in response to a common
perceived need.

Bob

>(Thanks to Bill Burr and his folks at NIST who "discovered" this in
>their Federal PKI working group efforts.)
>
>Folks,
>
>        I'm not a lawyer, and I don't play one on TV, either, so I'm hoping
>that there is no problem with this, but...
>
>        There are (at least) two US patents that may be of interest to
PKIX.
>Both are owned by Silvio Micali.
>
>        One, patent #5,420,927, issued May 30, 1995, and entitled "Method
for
>certifying public keys in a digital signature", claims to cover a method
>of using registration agents to identify users, validate their public
>keys, send their keys on to a certification authority for inclusion in a
>certificate, confirm that the user possesses the private key that goes
>with the public key, etc.
>
>        The other, patent # 5,666,416, issued September 9, 1997, and
entitled
>"Certificate revocation system", claims to cover a method of having a CA
>determine whether a certificate is valid; pass a message stating such to
>another party, and having that party respond to queries from others with
>information about the validity of the certificate.  The "invention"
>covered by this patent "...obviates use of certification revocation
>lists communicated between the certifying authority and the directory. "
>
>        Is there someone on the list who can say with certainty that PKIX
parts
>1 and 3 do not infringe on the first of these patents, and that OCSP
>does not infringe on the other one?
>
>        Thanks for any information,
>
>
>                        Al Arsenault
>        - speaking only for myself.  My opinions do not necessarily reflect
>those of my employer.
>
>P.S.  URLs for these patents are
>
>        http://patent.womplex.ibm.com/details?patent_number=5420927
>
>and
>
>        http://patent.womplex.ibm.com/details?patent_number=5666416

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

Date:         Tue, 6 Jan 1998 17:43:10 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

Warwick,

Thanks for taking the time to continue this highly interesting discussion.

>>
>>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
>>do I necessarily need that CA's permission to do so?  I think not,
although
>>it might be polite to inform them of what I am doing.  (In most cases, of
>>course, this would only happen after a contractual agreement, so this is
>>probably just a rhetorical point.)
[snip]
>
>Well, I don't think you want to go around issuing certificates for other
>CAs' public keys without their permission.  Firstly, it is unwise since you
>would have no basis of assurances re future validity, revocation
>notification, etc.  Secondly you could arguably be treading into
>intellectual property violation waters.  Therefore, I think that we should
>be espousing that CA-certificates ALWAYS be issued only within a
>contractual agreement.

Hmm.

I'm not entirely sure that I agree.

What is the moral or legal, as opposed to technical, difference between my
creating a certificate which incorporates the public key of a TLCA, e.g.,
VeriSign, or any other CA, vs. directly loading the very same public key or
self-signed certificate into my trusted cache?

If you recall, you were the one who convinced me of the elegance of the
policy OID constraint approach to certificate chaining, pointing out that it
allowed the user himself, (or his IT organization) to create a certificate
which effectively serves as his own local (unpublished) TLCA and
cross-certifies other CAs, without requiring access to some kind of a local
database of trusted CAs to validate each certificate.  A suitable trusted
smart card, a la Fortessa, containing a trusted public key or self-signed
certifcate, could feasibly implement the relying party's trust policy
without requiring a trusted operating system host.

This way the RP has only his own public key to trust, and the IT
organization doesn't have to run around the country or the world populating
new trusted TLCA keys into client software every time a new CA pops up or a
key is replaced. They merely post new certificates on an untrusted directory
or repository, to be downloaded as needed.

A closed user group might be a different matter. But even in the case of
SET, what is to prevent me as a relying party from creating my own
certificate which cross-certifies the SET hierarchy?

If all I am doing is selling dollar dish rags, I might be willing to accept
a SET certificate, a Verisign certificate, a MISSI certificate, (or even a
PGP certificate or whatever), and take the byusiness risk that one of those
CAs or hierarchies has a less- han sterling reputation. It is arguably
better than using nothing at all, e.g., a telephone crecit card number.

In particularly, I DON'T think that I have to go out and negotiate a
contract with each one of those CAs before I create such a
cross-certificate, or equivalently load a self-signed certificate into my
trusted cache. That is essentially the fundamental assumption basis for an
open PKI architecture.

PUBLISHING such a certificate outside of my close circle of friends might be
quite a different matter, of course. But there my concern would be whether
by publishing such a certificate I might be making myself liable for that
other CA's operational screw-ups, etc. I would look at the CA's Cetification
Practice Statement and other indicia before decding whether or not to trust
the ongoing CRL and other policy matters, just as I would before loading
their root key into my cache. In any case I can make that decision for
myself -- I don't need and don't want a standard to preclude my options
(although I doubt that was what you had in mind).

I am not persuaded by the intellectual property argument, either, but I
would like to hear an attorney like Michael Baum put forth a cogent legal
theory along those lines.  To my way of thinking, I am not publishing any
copywrited or trademarked work at all, except to the extent that I
incorporate the public key contained in the CA's certificate. Since the
public nature of the public key is its raison d'etre, and since the CA's
certificate cannot be used except by incorporating the public key in the
relying party's cache of trusted keys one way or the other, I don't see how
I have infringed or diminished their copyright, the CA's trademark, or their
good name in any way.

I understand that VeriSign includes a copyright notice within their
certificates, but I have tended to regard this as a chicken soup, "it cant'
hurt" type of preventative medicine cop out.  If there is a real legal issue
lurking there somewhere, I'd like to know about it, as I believe it might
apply by extension to the use of that certificate by any relying party. I
don't think that was VeriSign's intent.

Regards,

Bob

Date:         Wed, 7 Jan 1998 17:46:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] cross certification
To: [email-masked]
Status:

Dwight & Warwick,

        I'd like to add another view to the cross certification discussion.
Certificates don't necessarily imply trust.  They are primarily mechanisms
to support identification (although explicit authorization is also an
option), and this identification is often used as an input to an access
control decision.  So, when I certify a CA in another administrative
domain, the simple connotation is that I am relying on (trusting?) that CA
to identify subjects within that domain.  Having relied upon that CA for
that function, I can then proceed to make access control decisions based on
the subject identities from this other administrative domain.  If one
embeds authorization info into the certs and uses that for access control,
then life is more complex and certification policy extensions may also be
used to help control the authorization range afforded to the
cross-certified CA.  As Tina Turner so aptly said, "what's trust got to do
with it?"

Steve

Date:         Wed, 7 Jan 1998 14:56:31 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Arsenault, Al W." <[email-masked]>
Subject:      [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

(Thanks to Bill Burr and his folks at NIST who "discovered" this in
their Federal PKI working group efforts.)

Folks,

        I'm not a lawyer, and I don't play one on TV, either, so I'm hoping
that there is no problem with this, but...

        There are (at least) two US patents that may be of interest to PKIX.
Both are owned by Silvio Micali.

        One, patent #5,420,927, issued May 30, 1995, and entitled "Method for
certifying public keys in a digital signature", claims to cover a method
of using registration agents to identify users, validate their public
keys, send their keys on to a certification authority for inclusion in a
certificate, confirm that the user possesses the private key that goes
with the public key, etc.

        The other, patent # 5,666,416, issued September 9, 1997, and entitled
"Certificate revocation system", claims to cover a method of having a CA
determine whether a certificate is valid; pass a message stating such to
another party, and having that party respond to queries from others with
information about the validity of the certificate.  The "invention"
covered by this patent "...obviates use of certification revocation
lists communicated between the certifying authority and the directory. "

        Is there someone on the list who can say with certainty that PKIX parts
1 and 3 do not infringe on the first of these patents, and that OCSP
does not infringe on the other one?

        Thanks for any information,

                        Al Arsenault
        - speaking only for myself.  My opinions do not necessarily reflect
those of my employer.

P.S.  URLs for these patents are

        http://patent.womplex.ibm.com/details?patent_number=5420927

and

        http://patent.womplex.ibm.com/details?patent_number=5666416

Date:         Wed, 7 Jan 1998 15:01:21 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tomaz Klobucar <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
To: [email-masked]
Status:

Although there was a long discussion about certificate policies on this list
I am still a bit bemused, especially about recognizing and supporting
certificate policies extensions (critical or non-critical). I would
appreciate if someone could explain the following case. Let us suppose
that a CA has published two policies for signing bills in certain company.
One is used for bills where amount is less than 1000$ and does not specify
how private keys must be protected. The other policy specifies
rules for keys which can be used to sign bills over 1000$. These keys must be
stored on smartcards. The CA then issues certificates where one of this
certificate policies is flagged critical. Should signing applications and
applications for validating signatures which claim to support these policies
check the amount in each bill during signing procedure or signature
validation? Must applications be able to verify if the signing key is properly
stored?

Regards, Tomaz

Date:         Wed, 7 Jan 1998 09:59:16 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

-----Original Message-----
From: Gary Gaskell <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, 7 January 1998 9:43
Subject: Re: [IETF-PKIX] Cross-certification issues and terminology

:Gents,
:
:[Firstly, apologies if this does not contribute in a constructive way to
:your discussion, as I haven't read _all_ of the preceding discussions.
:Hopefully it will contribute ;-) ]
:
:1. I don't think we can say, "X.509 says it all", as that is why you are
:all working PKIX in the first place.  PKIX must take some lead if this is
:ever to be deployed;
:
Snip

:I hope this in some way contributes to your debate.

It adds to the usage examples of Xcerts, but I still do not see problem with
the defintion of a Xcert in X.509.

I believe the discussion should be about what we are trying to standardise
in PKIX, I dont belive we should be trying to standardise on a particular
use of Xcerts ( as the the deployment experience of large scale PKI's is
just too imature at this time).

:
:Cheers,
:
:Gary
:
:On Tue, 6 Jan 1998, Warwick Ford wrote:
:

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

Attachment converted: Lutefisk:smime.p7s 26 (????/----) (0001DE3F)

Date:         Wed, 7 Jan 1998 09:26:18 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Wednesday, January 07, 1998 8:34 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] NO SUBJECT
>
> Charles:
>
> At 06:08 AM 1/7/98 +1000, Charles Moore wrote:
> >:Could you please clarify exactly what "technical definition" you are
> >:referring to?  What document is it in?
> >
> >The X.509 standard, has more than sufficient definition to meet our
> >technical objective, in both syntax, normative and non-normative
> text.
>
> Unfortunately X.509 does not define "cross-certification" in an
> unambiguous
> or particularly helpful way.  We would not be pursuing this thread if
> it did.
        [Charles Moore]  Ok, whats the problem.

        Are you sure we are separating definition ( specification) from
issues relating to the use of the specification.

        Please explain the ambiguity from a specification perspective
(not the use of the specification).

        All of the discussion I have followed to date has been on how
one might use this specification to meet  one-or-more policies, all good
discussion, but not related to ambiguity of specification.

        Do you want to standardise on a specific use of
cross-certificates ( ie a standard policy statement, one or more) and if
so why?

> Warwick
>
> ---------------------------------------------------------------------
> Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>    [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
> ---------------------------------------------------------------------

Date:         Wed, 7 Jan 1998 09:08:24 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gary Gaskell <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

Gents,

[Firstly, apologies if this does not contribute in a constructive way to
your discussion, as I haven't read _all_ of the preceding discussions.
Hopefully it will contribute ;-) ]

1. I don't think we can say, "X.509 says it all", as that is why you are
all working PKIX in the first place.  PKIX must take some lead if this is
ever to be deployed;

2. Cross certification is very important and I anticipate that the use of
cross certification will be a primary issue in the successful deployment
of PKIX.
Why:
  a. because governments will never get organised soon enough, for a
     hierarchy to work;
  b. Because an imposed heirarchy would be too rigid;
  c. An organisation wants to be in control of who their
     employees trust and deal with

>From point c above, I think we can draw the main reason for the design and
deployment of cross CA certs.  If we mandate contracts are written and
signed, we could be putting an onerous burden on an organisation in the
set up of their IT infrastructure.

IMO points a and b are what detract significantly from Australia PKAF
work.

The scenario that I'm thinking of goes like:

Organisation Acme has an IT system where its employees can only interact
with people in other organisations if Acme has cross signed the CA public
keys of other organisations.  This gives Acme more control and a way of
enforcing their business policy.  As they may change their preferred
supplier daily, a contractual basis for cross signing may be too much.

And I presume we could leave it to the organisation (e.g. Acme) to check a
central (government or private) directory service for cert revocations,
and then add them to their own CRL.

IE. The norm for a cert path check may be:
a. retrieve cert
b. check its CA's signature
c. check that my organisation has a cross cert for this other organisation
d. check my organisation's CRL.

If not if appears that my organisation has not approved business
interactions with the other organisation.  I think this could also be
expanded to cross signing the public keys of a node in a hierarchy.  If
there was to be one true hierarchy, then the organisation can control
which parts of it are trustworthy by the organisations people.

I hope this in some way contributes to your debate.

Cheers,

Gary

On Tue, 6 Jan 1998, Warwick Ford wrote:

>Bob:
>
>At 10:40 AM 1/6/98 -0700, Bob Jueneman wrote:
>>But first let me ask your opinion regarding the creation of a cross-domain
>>certificate.  I haven't read the CMP proposal in any detail, but I'm not
>>sure that I understand why any protocol is particularly needed in this case.
>>
>>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
>>do I necessarily need that CA's permission to do so?  I think not, although
>>it might be polite to inform them of what I am doing.  (In most cases, of
>>course, this would only happen after a contractual agreement, so this is
>>probably just a rhetorical point.)  So why do I need a protocol? Can't I
>>just pick up the self-signed certificate via a trusted out-of-band, i.e.,
>>manual, process (which I would need to do in any case), extract the public
>>key, and include that key in my newly minted certificate? (Regardless of
>>whether a public key is created by an end-user, or by a CA, or even by the
>>issuing CA, some sort of trusted, out-of-band process is always required
>>prior to the binding, to ensure that the subject is who they claim to be,
>>and to provide proof of possession of the corresponding private key.)
>
>Well, I don't think you want to go around issuing certificates for other
>CAs' public keys without their permission.  Firstly, it is unwise since you
>would have no basis of assurances re future validity, revocation
>notification, etc.  Secondly you could arguably be treading into
>intellectual property violation waters.  Therefore, I think that we should
>be espousing that CA-certificates ALWAYS be issued only within a
>contractual agreement.
>
>As to the need for a protocol...  Technically, all you need is an agreed
>format for representing a certificate-signing request ... the most obvious
>approach is to use exactly the same format (and surrounding protocol, if
>required) as when an end-entity enrolls with a CA.  The Microsoft
>Certificate Server, for example, uses PKCS#10 for representing the
>information sent from a subject CA to issuing CA to have a CA-certificate
>issued.  CMP is essentially the same -- the "CrossCert" transaction is just
>a minor variant of the end-entity certificate-signing request.
>
>>Is the supposition behind CMP that a TLCA in one domain would request that
>>they be issued a certificate by a CA in another domain?  That doesn't seem
>>very likely or reasonable. So I think that I must misperceive the intent of
>>CMP -- perhaps it is only intended to address how subordinate CAs request a
>>certificate from a higher level (within the hierarchy) CA?
>
>I believe CMP provides nothing more than a protocol for one CA issuing a
>certificate to another CA, regardless, of domain or structure.  This is why
>Denis and I prefer the term "CA-certification" for what CMP does.  CMP does
>nothing to help solve the "hard problems" of cross-certification.
>
>>On another point, you comment that inter-domain certification might end up
>>with a [linked] hierarchical structure, or might not.
>>
>>I assume that you mean that a CA in one domain might unilaterally issue a
>>certificate to a CA in another domain, not necessarily the TLCA in that
>>domain. I can see that that might happen, and might actually be quite useful
>
>Yes, and your subsequent example is quite valid.  Raises some good points ....
>
>Warwick
>
>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
>

Cheers,

Gary

-----------------------------------------------------------
Gary Gaskell
Manager Secure Network Laboratory      Phone (07) 3864 1190
Information Security Research Centre   Fax   (07) 3221 2384
Queensland University of Technology
-----------------------------------------------------------

Date:         Tue, 6 Jan 1998 17:34:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

Charles:

At 06:08 AM 1/7/98 +1000, Charles Moore wrote:
>:Could you please clarify exactly what "technical definition" you are
>:referring to?  What document is it in?
>
>The X.509 standard, has more than sufficient definition to meet our
>technical objective, in both syntax, normative and non-normative text.

Unfortunately X.509 does not define "cross-certification" in an unambiguous
or particularly helpful way.  We would not be pursuing this thread if it did.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Tue, 6 Jan 1998 17:15:09 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

Bob:

At 10:40 AM 1/6/98 -0700, Bob Jueneman wrote:
>But first let me ask your opinion regarding the creation of a cross-domain
>certificate.  I haven't read the CMP proposal in any detail, but I'm not
>sure that I understand why any protocol is particularly needed in this case.
>
>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
>do I necessarily need that CA's permission to do so?  I think not, although
>it might be polite to inform them of what I am doing.  (In most cases, of
>course, this would only happen after a contractual agreement, so this is
>probably just a rhetorical point.)  So why do I need a protocol? Can't I
>just pick up the self-signed certificate via a trusted out-of-band, i.e.,
>manual, process (which I would need to do in any case), extract the public
>key, and include that key in my newly minted certificate? (Regardless of
>whether a public key is created by an end-user, or by a CA, or even by the
>issuing CA, some sort of trusted, out-of-band process is always required
>prior to the binding, to ensure that the subject is who they claim to be,
>and to provide proof of possession of the corresponding private key.)

Well, I don't think you want to go around issuing certificates for other
CAs' public keys without their permission.  Firstly, it is unwise since you
would have no basis of assurances re future validity, revocation
notification, etc.  Secondly you could arguably be treading into
intellectual property violation waters.  Therefore, I think that we should
be espousing that CA-certificates ALWAYS be issued only within a
contractual agreement.

As to the need for a protocol...  Technically, all you need is an agreed
format for representing a certificate-signing request ... the most obvious
approach is to use exactly the same format (and surrounding protocol, if
required) as when an end-entity enrolls with a CA.  The Microsoft
Certificate Server, for example, uses PKCS#10 for representing the
information sent from a subject CA to issuing CA to have a CA-certificate
issued.  CMP is essentially the same -- the "CrossCert" transaction is just
a minor variant of the end-entity certificate-signing request.

>Is the supposition behind CMP that a TLCA in one domain would request that
>they be issued a certificate by a CA in another domain?  That doesn't seem
>very likely or reasonable. So I think that I must misperceive the intent of
>CMP -- perhaps it is only intended to address how subordinate CAs request a
>certificate from a higher level (within the hierarchy) CA?

I believe CMP provides nothing more than a protocol for one CA issuing a
certificate to another CA, regardless, of domain or structure.  This is why
Denis and I prefer the term "CA-certification" for what CMP does.  CMP does
nothing to help solve the "hard problems" of cross-certification.

>On another point, you comment that inter-domain certification might end up
>with a [linked] hierarchical structure, or might not.
>
>I assume that you mean that a CA in one domain might unilaterally issue a
>certificate to a CA in another domain, not necessarily the TLCA in that
>domain. I can see that that might happen, and might actually be quite useful

Yes, and your subsequent example is quite valid.  Raises some good points ....

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Wed, 7 Jan 1998 06:08:59 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, 7 January 1998 0:12
Subject: Re: [IETF-PKIX] NO SUBJECT

:Charles:
:
:At 12:02 PM 1/6/98 +1000, Charles Moore wrote:
:>So
:>1. Leave the technical definition as is
:
:Could you please clarify exactly what "technical definition" you are
:referring to?  What document is it in?
:
:Do you mean bullet (g) in the PKIX Profile which says "cross-certification:
:Two CAs exchange the information necessary to establish cross-certificates
:between those CAs" ... kinda circular, maybe?

The X.509 standard, has more than sufficient definition to meet our
technical objective, in both syntax, normative and non-normative text.

How this mechanism can be used, does not need to be, and should not be in
PKIX, standardised as it is dependent on certificate policy.

:
:Warwick
:
:---------------------------------------------------------------------
:Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
:   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
:---------------------------------------------------------------------

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

Attachment converted: Lutefisk:smime.p7s 23 (????/----) (0001DE33)

Date:         Tue, 6 Jan 1998 14:47:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Patent on use of CRLs etc
To: [email-masked]
Status:

Bob Jueneman wrote:
>
> I couldn't read your attachment.  Could you provide a short summary of the
> patent?  Who was it issued to?

The Nortel and Novell Patents are both on the IBM patent server:

http://patent.womplex.ibm.com/details?patent_number=5699431
http://patent.womplex.ibm.com/details?patent_number=5687235

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 22 (????/----) (0001DE23)

Date:         Tue, 6 Jan 1998 14:39:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Patent on use of CRLs etc
To: [email-masked]
Status:

Also note patent 5687235.

        Phill

PS The patent I applied for covering motherhood, apple pie and the
American way was rejected as 'having no conceivable application'

Phillip Hallam-Baker wrote:
>
> Do we need to include a reference to US Patent 5699431 in the
> PKIX drafts?
>
> It appears it might cover much of the PKIX CRL infrastructure
> including partitioned CRLs.
>
> Is this likely to cause difficulty with the IESG?
>
>                 Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 21 (????/----) (0001DE22)

Date:         Tue, 6 Jan 1998 13:04:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      [IETF-PKIX] Patent on use of CRLs etc
To: [email-masked]
Status:

Do we need to include a reference to US Patent 5699431 in the
PKIX drafts?

It appears it might cover much of the PKIX CRL infrastructure
including partitioned CRLs.

Is this likely to cause difficulty with the IESG?

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 20 (????/----) (0001DE20)

Date:         Tue, 6 Jan 1998 11:44:15 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Patent on use of CRLs etc
Comments: To: [email-masked]
To: [email-masked]
Status:

I couldn't read your attachment.  Could you provide a short summary of the
patent?  Who was it issued to?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

>>> Phillip Hallam-Baker <[email-masked]> 01/06 11:04 AM >>>
Do we need to include a reference to US Patent 5699431 in the
PKIX drafts?

It appears it might cover much of the PKIX CRL infrastructure
including partitioned CRLs.

Is this likely to cause difficulty with the IESG?

                Phill

Date:         Tue, 6 Jan 1998 10:40:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] Cross-certification issues and terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

Warwick,

Separating the (cross-)certificate issuance issues from the certificate
retrieval issues is probably useful, although both problems will have to be
solved sooner or later. I also agree that there may be a requirement for a
cross-certificate within a simple hierarchy (i.e., with a single domain),
for performance or other reasons. And I haven't even begun to think through
the CRL and other issues involved in cross-domain certification -- I hope
that you have, and that it works.

But first let me ask your opinion regarding the creation of a cross-domain
certificate.  I haven't read the CMP proposal in any detail, but I'm not
sure that I understand why any protocol is particularly needed in this case.

If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
do I necessarily need that CA's permission to do so?  I think not, although
it might be polite to inform them of what I am doing.  (In most cases, of
course, this would only happen after a contractual agreement, so this is
probably just a rhetorical point.)  So why do I need a protocol? Can't I
just pick up the self-signed certificate via a trusted out-of-band, i.e.,
manual, process (which I would need to do in any case), extract the public
key, and include that key in my newly minted certificate? (Regardless of
whether a public key is created by an end-user, or by a CA, or even by the
issuing CA, some sort of trusted, out-of-band process is always required
prior to the binding, to ensure that the subject is who they claim to be,
and to provide proof of possession of the corresponding private key.)

Is the supposition behind CMP that a TLCA in one domain would request that
they be issued a certificate by a CA in another domain?  That doesn't seem
very likely or reasonable. So I think that I must misperceive the intent of
CMP -- perhaps it is only intended to address how subordinate CAs request a
certificate from a higher level (within the hierarchy) CA?

On another point, you comment that inter-domain certification might end up
with a [linked] hierarchical structure, or might not.

I assume that you mean that a CA in one domain might unilaterally issue a
certificate to a CA in another domain, not necessarily the TLCA in that
domain. I can see that that might happen, and might actually be quite useful
-- MISSI might certify a subordinate CA within its domain, let's say the
Utah National Guard, and the State of Utah might also certify that CA under
the provisions of the Utah Digital Signature Act. Rather than provoke a
constitutional crisis over the primacy of federal vs. state powers, a first
come, first served rule might be applied, and Utah would cross-certify the
Utah National Guard CA directly, bypassing higher-level CAs in the MISSI
hierarchy.  (It might well be that Utah would either require a higher
standard of performance for their licensed CAs than MISSI would necessarily
provide, or that the State simply wouldn't have the resources to audit and
otherwise ensure compliance with the Utah Act for other MISSI CAs. So
although they might certify the Utah National Guard CA, they would not
certify MISSI itself, nor the other CAs under the MISSI hierarchy.)

Let me see if I understand how the certificate validation process works in
this case. And I will conveniently ignore the issue of how the certificates
are actually located, whether they are all in one ubiquitous directory, or
have to be retrieved from various sites is a small detail, at least for now.

So consider the case where a relying party has loaded the root key of the
Utah TLCA, and wants to only deal with CAs that are licensed under the Utah
Act. A purchase order is received, signed by the Supply Officer of Bravo
Company, First Chemical Weapons Battalion, Utah National Guard, whose
certificate is issued by the UNG CA directly (for the sake of argument).

If the relying party's software just climbs the certificate tree blindly, it
would tend to look for the next level certificate, which let's say is issued
by the US Army CA to the Utah National Guard. But climbing that particular
tree isn't going to be useful, because Utah hasn't certified the MISSI TLCA.

So somehow the relying party's software has to know that it should preload
and verify the Utah certificate which certifies the Utah National Guard CA's
certificate.  Then, when the RP's software encounters the UNG's certificate,
it can exclaim "Eureka! I already have verified this public key, and so
everything is hunky-dory."

That's OK in concept, but God is in the niggling details:

1.  How does the RP software know that that particular cross-certificate is
going to be needed?  Does it have to preload and verify every certificate
issued by Utah? That might not be too bad in the case of Utah, but what if
it were New York or Illinois? The software might have to maintain thousands
of keys in its stack.

2.  It isn't sufficient to just (pre-)validate the public key of the Utah
National Guard -- presumably the RP software has to keep track of all of the
policy OID and other constraints that might be applied, from the Utah TLCA
on down, and then check that the end-user certificate issued by the UNG
satisfies those criteria.

I am increasingly beginning to believe that it will be necessary to store
prevalidated certificates in a locally-trusted working directory. Whether
the most efficient implementation of the search argument for finding a
certificate in the directory should be the DN of the subject, or perhaps a
hash of the public key, remains to be determined.

How this should impact OCSP, and/or how nonrepudiation should best be
provided in this environment also requires further study, I believe.

Bob

>Bob:
>
>This is another interesting (and unquestionably useful) view on the meaning
>of "cross-certification".  It is different to what I had been referring to
>as "inter-domain certification" because, to my mind, inter-domain
>certification might end up with a hierarchical structure or might not.
>
>It is now clear that there are at least 3 quite different problems being
>addressed, all of them being declared as the "cross-certification" problem,
>but that there is no "cross-certification" panacea.  I therefore suggest we
>retire the term "cross-certification" for the moment and focus on the
>various problems and the characteristics of their solutions.
>
>I believe the "problems" identified thus far are:
>
>(a) The mechanical problem of having one CA issue a cert for another CA
>(regardless of domain, PKI structure, etc.).  This is the problem solved by
>the CMP CrossCert transaction or similar enrollment protocols.  As pointed
>out by Denis Pinkas, this is probably best called "CA-certification" for
>consistency with the X.509 term "CA-certificate".
>
>(b) The problem of establishing a link between two domains (typically two
>organizations) whereby a CA in one domain issues a certificate for the
>cert-signing key of a CA in another domain.  This raises the issues of
>assessment of trustworthiness, establishment of binding agreements,
>liability apportionment, X.509 protection mechanisms such as name
>constraints and policy-mapping, transitivity (on to further domains), etc.
>(I have been using the term "inter-domain certification" for this.)
>
>(c) The problem of finding a cert chain given that, in the general case,
>the overall structure of CAs comprises hierarchies, with inter-hierarchy
>links.  This raises the issues of availability of information from
>directories, and the capabilities of certificate-using products to perform
>the necessary searching and traversal.
>
>I do not believe the (b) and (c) problem domains generally lead to a common
>solution, nor that there is a particularly strong need to seek such a
>common solution.  For example, when a CA in domain A issues a certificate
>for a CA in domain B, the result could still be a hierarchy (if A is
>certifying the TLCA of B, and A is the only domain that does so), in which
>case the advantages of hierarchical cert-finding are still apparent.
>Conversely, within one domain, one might have a basic hierarchical
>structure but allow (for chain-shortening, performance purposes)
>certification links across the hierarchy (both the Fed Govt and Canadian
>Govt architectures have recognized the potential need for this).
>
>Warwick

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

Date:         Tue, 6 Jan 1998 08:28:53 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

Charles:

At 12:02 PM 1/6/98 +1000, Charles Moore wrote:
>So
>1. Leave the technical definition as is

Could you please clarify exactly what "technical definition" you are
referring to?  What document is it in?

Do you mean bullet (g) in the PKIX Profile which says "cross-certification:
Two CAs exchange the information necessary to establish cross-certificates
between those CAs" ... kinda circular, maybe?

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Tue, 6 Jan 1998 12:02:22 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

I am not sure why things have to be made more complicated than needed.

A) First Separate out the technical issues from the policy issues.
B) Address the technical issues here, leave the policy issues for the
policy/business decisions.

With the above, cross certification at least with the current standard
is straight forward.
All of the discussed uses of cross-certificates are ok, it all depends
on the policy under which the cross-certificate is certified.

So
1. Leave the technical definition as is
2. Let the certificate policy make statements about the rules and
meanings of any cross-certificate.
Let the policy have flexibility to support what people what to put
labels on such as inter-domain certification or other terms.

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Tuesday, January 06, 1998 10:44 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] NO SUBJECT
>
> Bob:
>
> This is another interesting (and unquestionably useful) view on the
> meaning
> of "cross-certification".  It is different to what I had been
> referring to
> as "inter-domain certification" because, to my mind, inter-domain
> certification might end up with a hierarchical structure or might not.
>
> It is now clear that there are at least 3 quite different problems
> being
> addressed, all of them being declared as the "cross-certification"
> problem,
> but that there is no "cross-certification" panacea.  I therefore
> suggest we
> retire the term "cross-certification" for the moment and focus on the
> various problems and the characteristics of their solutions.
        [Charles Moore]  One problem, but many policies, and there are
more than these.

> I believe the "problems" identified thus far are:
>
> (a) The mechanical problem of having one CA issue a cert for another
> CA
> (regardless of domain, PKI structure, etc.).  This is the problem
> solved by
> the CMP CrossCert transaction or similar enrollment protocols.  As
> pointed
> out by Denis Pinkas, this is probably best called "CA-certification"
> for
> consistency with the X.509 term "CA-certificate".
        [Charles Moore]  It is just cross-certification, nothing more.
Whether CMP crossCerts messages are useful for this or any other Xcert
is a different issue.

> (b) The problem of establishing a link between two domains (typically
> two
> organizations) whereby a CA in one domain issues a certificate for the
> cert-signing key of a CA in another domain.  This raises the issues of
> assessment of trustworthiness, establishment of binding agreements,
> liability apportionment, X.509 protection mechanisms such as name
> constraints and policy-mapping, transitivity (on to further domains),
> etc.
> (I have been using the term "inter-domain certification" for this.)
        [Charles Moore]  Its the same as above just that the policies on
cross certification are different

> (c) The problem of finding a cert chain given that, in the general
> case,
> the overall structure of CAs comprises hierarchies, with
> inter-hierarchy
> links.  This raises the issues of availability of information from
> directories, and the capabilities of certificate-using products to
> perform
> the necessary searching and traversal.
        [Charles Moore]  I believe this is a orthogonal problem that
applies to all cases.

> I do not believe the (b) and (c) problem domains generally lead to a
> common
> solution,
        [Charles Moore]  I am not sure I understand, they both can
produce a solution, but in all cases there is a need to know the
policies/rules

> nor that there is a particularly strong need to seek such a
> common solution.
        [Charles Moore]  If this means common code/rules I agree in the
specific and also the general case.

> For example, when a CA in domain A issues a certificate
> for a CA in domain B, the result could still be a hierarchy (if A is
> certifying the TLCA of B, and A is the only domain that does so), in
> which
> case the advantages of hierarchical cert-finding are still apparent.
> Conversely, within one domain, one might have a basic hierarchical
> structure but allow (for chain-shortening, performance purposes)
> certification links across the hierarchy (both the Fed Govt and
> Canadian
> Govt architectures have recognized the potential need for this).
        [Charles Moore]  I am not sure I understand the specific
relevance, the PKI will have many different structures, the technical
services such as
        cross-certification must support ( and I believe it does) any
structure.
        Some of the structures will have advantages over others in given
situations.

Date:         Mon, 5 Jan 1998 19:43:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

Bob:

This is another interesting (and unquestionably useful) view on the meaning
of "cross-certification".  It is different to what I had been referring to
as "inter-domain certification" because, to my mind, inter-domain
certification might end up with a hierarchical structure or might not.

It is now clear that there are at least 3 quite different problems being
addressed, all of them being declared as the "cross-certification" problem,
but that there is no "cross-certification" panacea.  I therefore suggest we
retire the term "cross-certification" for the moment and focus on the
various problems and the characteristics of their solutions.

I believe the "problems" identified thus far are:

(a) The mechanical problem of having one CA issue a cert for another CA
(regardless of domain, PKI structure, etc.).  This is the problem solved by
the CMP CrossCert transaction or similar enrollment protocols.  As pointed
out by Denis Pinkas, this is probably best called "CA-certification" for
consistency with the X.509 term "CA-certificate".

(b) The problem of establishing a link between two domains (typically two
organizations) whereby a CA in one domain issues a certificate for the
cert-signing key of a CA in another domain.  This raises the issues of
assessment of trustworthiness, establishment of binding agreements,
liability apportionment, X.509 protection mechanisms such as name
constraints and policy-mapping, transitivity (on to further domains), etc.
(I have been using the term "inter-domain certification" for this.)

(c) The problem of finding a cert chain given that, in the general case,
the overall structure of CAs comprises hierarchies, with inter-hierarchy
links.  This raises the issues of availability of information from
directories, and the capabilities of certificate-using products to perform
the necessary searching and traversal.

I do not believe the (b) and (c) problem domains generally lead to a common
solution, nor that there is a particularly strong need to seek such a
common solution.  For example, when a CA in domain A issues a certificate
for a CA in domain B, the result could still be a hierarchy (if A is
certifying the TLCA of B, and A is the only domain that does so), in which
case the advantages of hierarchical cert-finding are still apparent.
Conversely, within one domain, one might have a basic hierarchical
structure but allow (for chain-shortening, performance purposes)
certification links across the hierarchy (both the Fed Govt and Canadian
Govt architectures have recognized the potential need for this).

Warwick

At 01:52 PM 1/5/98 -0700, Bob Jueneman wrote:
>Warwick,
>
>I certainly agree with the need to clarify the terminology.
>
>
>To my way of thinking, one of the most important distinctions between an
>interdomain cross-certificate and an "ordinary" certificate lies in the
>potential one-to-many relationship of the subject to the issuer that
>significantly complicates the certificate retrieval mechanism, by requiring
>both bottom-up and top-down processing.
>
>Since I may not have a correct understanding of the model, let me at least
>describe what I am envisioning:
>
>A stand-alone, hierarchical domain exists that consists of a top-level CA,
>one or more subordinate CAs whose certificates are either signed by the
>top-level CA or by a higher-level subordinate CA, and a multiplicity of
>end-user's whose certificates are signed by a subordinate CA.
>
>Although not absolutely necessary, I am envisioning that the public key of
>the top-level CA will be incorporated in a self-signed certificate for
>compatibility of distribution as well as to allow the inclusion of various
>attributes (e.g., expiration dates, DNs, etc.) in a standard form.
>
>Given an end-user's certificate, it is possible to at least identify the
>name of the issuing CA by looking at the issuerName field of the end-user's
>certificate. Hopefully the location of that certificate can also be derived,
>at least indirectly if not directly.  By applying this mechanism
>recursively, it is possible to climb the chain of certificates up to the
>top-level CA, whose self-signed certificate serves as a 'stopper" to stop
>the search.  If the top-level CA's public key is included in the cache of
>trusted keys for that application, then the chain is validated, if not,
>punt.
>
>Within the hierarchy, certificates have a one to many relationship between
>the issuer and multiple subjects. But cross-domain certificates introduce
>the possibility that a given subject's public key may be signed by multiple
>issuers, i.e., though the creation of a multiplicity of certificates which
>include the public key of that top-level CA within that domain.
>
>Since an X.509 certificate cannot contain multiple issuers, and even if it
>could there would be no effective way to coordinate the issuance of such a
>multiple issuer certificate, the tree-climbing algorithm for certificate
>retrieval effectively breaks at this point.
>
>Instead, the introduction of a cross-domain certificate provides an
>alternative means of distributing trusted root keys to relying parties
>within a particular community of interest -- one that is more flexible and
>extensible than merely including the root keys in code, for example.
>
>In effect, this provides a mechanism for implementing Dwight Arthur's view
>of the world -- a community of relying parties, perhaps influenced or
>dictated by an organization's IT department, distributes a single trusted
>root key for that particular community through an out-of-band mechanism.
>That particular domain makes up a hierarchy, although in the case of a
>single user who operates his own CA, the hierarchy has a depth of one level.
>
>Those end users whose chain of certificates can be verified by checking the
>chain up to the top-level trusted CA (modulo whatever policy OID and other
>path validation mechanisms may be imposed) can assumed to be trusted by
>anyone whose has chosen or implemented that top-level CA as their trusted
>root.
>
>End users who may be issued certificates under the aegis of another
>top-level CA, but one that is trusted by the relying party (or more likely,
>by the relying party's IT department as a function of organization policy,
>including contractual or other agreements) can be automatically accepted if
>some CA in the relying party's hierarchy (usually, but not necessarily, the
>top level CA in the domain) cross-certifies the other domain though the
>issuance of a certificate which includes the public key of the foreign
>domain's top-level CA.
>
>>From a certificate processing standpoint, the ultimate end-user's
>certificate is still processed from the bottom up, all the way to the
>self-signed certificate that represents the top-level CA in the foreign
>domain.  But as a result of the cross-domain certification, and perhaps as a
>result of preprocessing all of the cross-domain certificates issued by the
>relying party's own top-level CA, the foreign CA's public key can now be
>considered trusted, just as though it had been conveyed directly via a
>secure out-of-band mechanism.
>
>In addition, all of the existing policy OID and other constraint mechanisms
>can be imposed to control the extent to which transitive trust extends to
>subordinate CAs and their end-users.
>
>That's at least what I mean by cross-certification.  I'm not quite sure
>whether that is what other people have implied by the term. In particular,
>my use of the term cross-certification does NOT mean the simple
>certification of subordinate CA by a higher-level CA in a simple hierarchy.
>
>Bob

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 5 Jan 1998 13:52:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
Comments: To: [email-masked]
To: [email-masked]
Status:

Warwick,

I certainly agree with the need to clarify the terminology.

To my way of thinking, one of the most important distinctions between an
interdomain cross-certificate and an "ordinary" certificate lies in the
potential one-to-many relationship of the subject to the issuer that
significantly complicates the certificate retrieval mechanism, by requiring
both bottom-up and top-down processing.

Since I may not have a correct understanding of the model, let me at least
describe what I am envisioning:

A stand-alone, hierarchical domain exists that consists of a top-level CA,
one or more subordinate CAs whose certificates are either signed by the
top-level CA or by a higher-level subordinate CA, and a multiplicity of
end-user's whose certificates are signed by a subordinate CA.

Although not absolutely necessary, I am envisioning that the public key of
the top-level CA will be incorporated in a self-signed certificate for
compatibility of distribution as well as to allow the inclusion of various
attributes (e.g., expiration dates, DNs, etc.) in a standard form.

Given an end-user's certificate, it is possible to at least identify the
name of the issuing CA by looking at the issuerName field of the end-user's
certificate. Hopefully the location of that certificate can also be derived,
at least indirectly if not directly.  By applying this mechanism
recursively, it is possible to climb the chain of certificates up to the
top-level CA, whose self-signed certificate serves as a 'stopper" to stop
the search.  If the top-level CA's public key is included in the cache of
trusted keys for that application, then the chain is validated, if not,
punt.

Within the hierarchy, certificates have a one to many relationship between
the issuer and multiple subjects. But cross-domain certificates introduce
the possibility that a given subject's public key may be signed by multiple
issuers, i.e., though the creation of a multiplicity of certificates which
include the public key of that top-level CA within that domain.

Since an X.509 certificate cannot contain multiple issuers, and even if it
could there would be no effective way to coordinate the issuance of such a
multiple issuer certificate, the tree-climbing algorithm for certificate
retrieval effectively breaks at this point.

Instead, the introduction of a cross-domain certificate provides an
alternative means of distributing trusted root keys to relying parties
within a particular community of interest -- one that is more flexible and
extensible than merely including the root keys in code, for example.

In effect, this provides a mechanism for implementing Dwight Arthur's view
of the world -- a community of relying parties, perhaps influenced or
dictated by an organization's IT department, distributes a single trusted
root key for that particular community through an out-of-band mechanism.
That particular domain makes up a hierarchy, although in the case of a
single user who operates his own CA, the hierarchy has a depth of one level.

Those end users whose chain of certificates can be verified by checking the
chain up to the top-level trusted CA (modulo whatever policy OID and other
path validation mechanisms may be imposed) can assumed to be trusted by
anyone whose has chosen or implemented that top-level CA as their trusted
root.

End users who may be issued certificates under the aegis of another
top-level CA, but one that is trusted by the relying party (or more likely,
by the relying party's IT department as a function of organization policy,
including contractual or other agreements) can be automatically accepted if
some CA in the relying party's hierarchy (usually, but not necessarily, the
top level CA in the domain) cross-certifies the other domain though the
issuance of a certificate which includes the public key of the foreign
domain's top-level CA.

>From a certificate processing standpoint, the ultimate end-user's
certificate is still processed from the bottom up, all the way to the
self-signed certificate that represents the top-level CA in the foreign
domain.  But as a result of the cross-domain certification, and perhaps as a
result of preprocessing all of the cross-domain certificates issued by the
relying party's own top-level CA, the foreign CA's public key can now be
considered trusted, just as though it had been conveyed directly via a
secure out-of-band mechanism.

In addition, all of the existing policy OID and other constraint mechanisms
can be imposed to control the extent to which transitive trust extends to
subordinate CAs and their end-users.

That's at least what I mean by cross-certification.  I'm not quite sure
whether that is what other people have implied by the term. In particular,
my use of the term cross-certification does NOT mean the simple
certification of subordinate CA by a higher-level CA in a simple hierarchy.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

>>> Warwick Ford <[email-masked]> 01/05 6:09 AM >>>
Dwight:

In my score-keeping on the terminology issue, I have thus far seen support
for at least two totally different interpretations of the term
"cross-certification", then several different shades of meaning beyond that.

I would contend that "cross-certification" is NOT a well-defined term and
suggest we move to (and clearly define) more precise terms such as
"CA-certification" and "inter-domain certification".  I was giving the list
another few days after the break to make sure that all inputs are in,
before making a concrete proposal.

Regards,
Warwick

At 04:47 PM 1/4/98 -0500, Dwight Arthur wrote:
>On trust and cross certification:
>
>I believe that there is a persistent misperception among technologists
>in this field that an RP will trust someone because of the
>certificate(s) that person can produce. On the contrary I would suggest
>that in many cases the RP represents an enterprise that causes a
>certificate to be granted because of a pre-existing relationship of
>trust. In other words, trust leads to certificates, certificates do not
>lead to trust.
>
>If my enterprise operates a system which we have agreed to make
>accessible to you, it is because we already have some reason to trust
>you, such as a contractual relationship with your employer, or
>collateral that you have deposited with us, or maybe a line of credit
>that you have identified and we have verified.
>
>The certificate plays an important role: it allows my system to validate
>your identity at the time that you access it, and allows you to create
>"digital signatures" as lasting verifiable indications that you commit
>yourself and/or your enterprise to various transactions. In order to
>achieve these benefits without the overhead and expense of personally
>issuing certificates to everyone I trust, I will rely in some cases on
>CAs operated by others to issue the certificates. To be able to validate
>these certificates, I may require some relationship with the external CA
>that may require cross-certification (although there may be other
>simpler ways such as bilateral exchange of keys).
>
>BUT IN NO CASE does the fact that I cross certify an external CA make me
>willing to trust any and all certs issued by that CA. All it does is
>that when I receive a signature from someone I am inclined to trust, it
>provides me with a path for validation of the signture, a method to
>determine that the private key is apparently free of compromise to this
>point, and perhaps a pointer into a directory from which other relevant
>data might be retrieved.
>
>What will, however, be quite useful in the future will be a certificate
>granted by my trade association, or by the CPA firm that audits the
>organization that operates the CA, or maybe some other body stating that
>the CA's CPS meets my trade association's requirements for accreditation
>at some level and that the CPA's scheduled and unscheduled audits
>demonstrate an acceptable degree of operational compliance with the
>policies specified in the CPS. If I find this certificate revoked I will
>definitely consider withholding trust from holders of certificates
>issued by the disaccredited (discredited ?) CA. Despite the fact that I
>have good reason (other than the cert) to trust the subject party, the
>discreditation (?) may signal that the cert is no longer a reliable
>indicator that the person holding it is in fact the person I trust.
>
>Question: it the CPA-to-CA certificate a cross-certificate under the
>recently circulated definitions of terms? I do not recall any mention of
>accreditation.
>
>-Dwight Arthur
>
>
>
>On 12/19/97, Russ Housley wrote:
>> Mack:
>>
>> I understand your issues, and in the banking community, there may be very
>> limited corss certification.
>>
>> I was simply trying to point out that the issuance of a cross certificate
>> from CA_a to CA_b need not cause every certificate issued by CA_b become
>> valid to the community that consider CA_a to be a trusted root.  If there
>> is an easily identified subset of CA_b's community and CA_a trusts CA_b
>> correctly validate the membership in that subset, then cross
certification
>> is an appropriate mechanism.  Trust is the center of this issue.  You
>> correctly point out that bankers like to minimize the number of people
(and
>> orgianizations) that they need to trust.  It greatly simplifies the risk
>> analysis and risk management.
>>
>> Russ
>>
>> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote:
>> >For: IETF-PKIX Mailing list
>> >
>> >From: "Russ Housley"<[email-masked]>
>> >
>> >> 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".))
>> >
>> >An example, the trusted relationships between UNIX nodes.  One can
>> >make the point that the Rhost kind of trust is similar to the
>> >cross-certification model.  Rhost type of trust has done nothing
>> >but get lots of people into lots and lots of trouble.
>> >
>> >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."
>> >
>> >Some people think banks trust each other through their Am Bnks Ass
>> >number (like on the checks).  Anyone who has gotten a bounced check
>> >knows this is not the case.  Knowing the "naming" and "addressing"
>> >(name constraints!) does not increase the level of trust.
>> >
>> >Keeping naming constraints current - or even manageable - is the
>> >full time task for lots of people in the mainframe world.
>> >Keeping that trust (usually in one place - like RACF or ACF2)
>> >is a full time job that often goes horribly wrong.
>> >
>> >
>> >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?
>> >
>> >-   -    -    -    -    -    -    -    -    -    -    -    -
>> >Mack Hicks (415) 278-7230  -- Interactive Banking Division
>> >425 1st St m/s3671, SF CA 94105 <[email-masked]>
>> >
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 5 Jan 1998 09:55:13 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames
Comments: To: [email-masked]
To: [email-masked]
Status:

Paul, I think that the only reasonable vieww would be to assume that the CA
is binding the public key to the gestalt, i.e., the totality,  of all of the
attributes contained in the certificate, including the DN and any alt names.
 If we start trying to pick apart different meanings for this, that and the
other attrbute when used in combination with other attributes, the
combinatoric explosion of semantic possibilities will quickly become
impossible to deal with.

So I believe that the CA is certifying each name individually, AND as a
group. Remember, it is perfectly possible, meaningful, and correct, for the
CA to issue multiple certificates to the same DN, and/or the same alt name,
for various purposes.

What the legal implications of a digital signature issued by
"[email-masked]" might be would be a different issue.

Bob

>
>>My guess would be that
>>the CA is vouching for the binding between each name in a certificate
>>and the remaining contents of the certificate.
>
>Each name individually, or as a group? "The rest of this cert applies to
>either the DN xxx,yyy or the email address [email-masked]" or "The rest of
>this cert applies to DN xxx,yyy, but only when also thought of as
>[email-masked]"?
>
>>It's probably a
>>distinction without a difference to ask whether the CA is vouching for
>>a binding between name A and name B - if both are bound to the same
>>public key, (in the same cert or in separate otherwise identical certs)
>>then they are implicitly equally valid, and it doesn't make much sense
>>to ask which name is "definitive".
>
>To me, this means "each name individually". I'm fine with this answer (and
>with the other), but neither is clearly stated in the doc.
>
>I can see a reason why "as a group" could be a logical choice. You might
>issue one cert for the combination of a DN of "o=FooCo, cn=Chris Smith" and
>a subjectAltName of "[email-masked]", and a different cert for  DN of
>"o=FooCo, cn=Kim Tong" and a subjectAltName of "[email-masked]". Or,
>the DNs might be the same (with an ou and no cn) but with different
>subjectAltNames.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date:         Mon, 5 Jan 1998 09:58:13 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] X509 newcomer
To: [email-masked]
Status:

        Hi!

        I work for a router company and I am researching using X509
certificates in our box.  I am just starting to learn about X.509
certificates. I have read the draft draft-ietf-pkix-ipki-part1-06.txt.
I have the ITU-T recommendation for X509 and Amendment 4.

        I have a couple of questions I was hoping someone on this list
could answer.

        1. The draft states it is part of a multipart standard.
What/where are the other parts? Are there any other specifications for
using certificates?

        2. Are there any white papers/drafts/specs/books out there that I can
read which would give me an understanding of the operational procedures
for using X509 certificates?

        3. Any other information a beginner should know?

        Thank you very much for any information you can provide.

        - Gina

--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Date:         Mon, 5 Jan 1998 08:09:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

Dwight:

In my score-keeping on the terminology issue, I have thus far seen support
for at least two totally different interpretations of the term
"cross-certification", then several different shades of meaning beyond that.

I would contend that "cross-certification" is NOT a well-defined term and
suggest we move to (and clearly define) more precise terms such as
"CA-certification" and "inter-domain certification".  I was giving the list
another few days after the break to make sure that all inputs are in,
before making a concrete proposal.

Regards,
Warwick

At 04:47 PM 1/4/98 -0500, Dwight Arthur wrote:
>On trust and cross certification:
>
>I believe that there is a persistent misperception among technologists
>in this field that an RP will trust someone because of the
>certificate(s) that person can produce. On the contrary I would suggest
>that in many cases the RP represents an enterprise that causes a
>certificate to be granted because of a pre-existing relationship of
>trust. In other words, trust leads to certificates, certificates do not
>lead to trust.
>
>If my enterprise operates a system which we have agreed to make
>accessible to you, it is because we already have some reason to trust
>you, such as a contractual relationship with your employer, or
>collateral that you have deposited with us, or maybe a line of credit
>that you have identified and we have verified.
>
>The certificate plays an important role: it allows my system to validate
>your identity at the time that you access it, and allows you to create
>"digital signatures" as lasting verifiable indications that you commit
>yourself and/or your enterprise to various transactions. In order to
>achieve these benefits without the overhead and expense of personally
>issuing certificates to everyone I trust, I will rely in some cases on
>CAs operated by others to issue the certificates. To be able to validate
>these certificates, I may require some relationship with the external CA
>that may require cross-certification (although there may be other
>simpler ways such as bilateral exchange of keys).
>
>BUT IN NO CASE does the fact that I cross certify an external CA make me
>willing to trust any and all certs issued by that CA. All it does is
>that when I receive a signature from someone I am inclined to trust, it
>provides me with a path for validation of the signture, a method to
>determine that the private key is apparently free of compromise to this
>point, and perhaps a pointer into a directory from which other relevant
>data might be retrieved.
>
>What will, however, be quite useful in the future will be a certificate
>granted by my trade association, or by the CPA firm that audits the
>organization that operates the CA, or maybe some other body stating that
>the CA's CPS meets my trade association's requirements for accreditation
>at some level and that the CPA's scheduled and unscheduled audits
>demonstrate an acceptable degree of operational compliance with the
>policies specified in the CPS. If I find this certificate revoked I will
>definitely consider withholding trust from holders of certificates
>issued by the disaccredited (discredited ?) CA. Despite the fact that I
>have good reason (other than the cert) to trust the subject party, the
>discreditation (?) may signal that the cert is no longer a reliable
>indicator that the person holding it is in fact the person I trust.
>
>Question: it the CPA-to-CA certificate a cross-certificate under the
>recently circulated definitions of terms? I do not recall any mention of
>accreditation.
>
>-Dwight Arthur
>
>
>
>On 12/19/97, Russ Housley wrote:
>> Mack:
>>
>> I understand your issues, and in the banking community, there may be very
>> limited corss certification.
>>
>> I was simply trying to point out that the issuance of a cross certificate
>> from CA_a to CA_b need not cause every certificate issued by CA_b become
>> valid to the community that consider CA_a to be a trusted root.  If there
>> is an easily identified subset of CA_b's community and CA_a trusts CA_b
>> correctly validate the membership in that subset, then cross certification
>> is an appropriate mechanism.  Trust is the center of this issue.  You
>> correctly point out that bankers like to minimize the number of people (and
>> orgianizations) that they need to trust.  It greatly simplifies the risk
>> analysis and risk management.
>>
>> Russ
>>
>> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote:
>> >For: IETF-PKIX Mailing list
>> >
>> >From: "Russ Housley"<[email-masked]>
>> >
>> >> 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".))
>> >
>> >An example, the trusted relationships between UNIX nodes.  One can
>> >make the point that the Rhost kind of trust is similar to the
>> >cross-certification model.  Rhost type of trust has done nothing
>> >but get lots of people into lots and lots of trouble.
>> >
>> >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."
>> >
>> >Some people think banks trust each other through their Am Bnks Ass
>> >number (like on the checks).  Anyone who has gotten a bounced check
>> >knows this is not the case.  Knowing the "naming" and "addressing"
>> >(name constraints!) does not increase the level of trust.
>> >
>> >Keeping naming constraints current - or even manageable - is the
>> >full time task for lots of people in the mainframe world.
>> >Keeping that trust (usually in one place - like RACF or ACF2)
>> >is a full time job that often goes horribly wrong.
>> >
>> >
>> >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?
>> >
>> >-   -    -    -    -    -    -    -    -    -    -    -    -
>> >Mack Hicks (415) 278-7230  -- Interactive Banking Division
>> >425 1st St m/s3671, SF CA 94105 <[email-masked]>
>> >
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Sun, 4 Jan 1998 16:47:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dwight Arthur <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
Comments: cc: Mack Hicks <[email-masked]>, Russ Housley <[email-masked]>
To: [email-masked]
Status:

On trust and cross certification:

I believe that there is a persistent misperception among technologists
in this field that an RP will trust someone because of the
certificate(s) that person can produce. On the contrary I would suggest
that in many cases the RP represents an enterprise that causes a
certificate to be granted because of a pre-existing relationship of
trust. In other words, trust leads to certificates, certificates do not
lead to trust.

If my enterprise operates a system which we have agreed to make
accessible to you, it is because we already have some reason to trust
you, such as a contractual relationship with your employer, or
collateral that you have deposited with us, or maybe a line of credit
that you have identified and we have verified.

The certificate plays an important role: it allows my system to validate
your identity at the time that you access it, and allows you to create
"digital signatures" as lasting verifiable indications that you commit
yourself and/or your enterprise to various transactions. In order to
achieve these benefits without the overhead and expense of personally
issuing certificates to everyone I trust, I will rely in some cases on
CAs operated by others to issue the certificates. To be able to validate
these certificates, I may require some relationship with the external CA
that may require cross-certification (although there may be other
simpler ways such as bilateral exchange of keys).

BUT IN NO CASE does the fact that I cross certify an external CA make me
willing to trust any and all certs issued by that CA. All it does is
that when I receive a signature from someone I am inclined to trust, it
provides me with a path for validation of the signture, a method to
determine that the private key is apparently free of compromise to this
point, and perhaps a pointer into a directory from which other relevant
data might be retrieved.

What will, however, be quite useful in the future will be a certificate
granted by my trade association, or by the CPA firm that audits the
organization that operates the CA, or maybe some other body stating that
the CA's CPS meets my trade association's requirements for accreditation
at some level and that the CPA's scheduled and unscheduled audits
demonstrate an acceptable degree of operational compliance with the
policies specified in the CPS. If I find this certificate revoked I will
definitely consider withholding trust from holders of certificates
issued by the disaccredited (discredited ?) CA. Despite the fact that I
have good reason (other than the cert) to trust the subject party, the
discreditation (?) may signal that the cert is no longer a reliable
indicator that the person holding it is in fact the person I trust.

Question: it the CPA-to-CA certificate a cross-certificate under the
recently circulated definitions of terms? I do not recall any mention of
accreditation.

-Dwight Arthur

On 12/19/97, Russ Housley wrote:
> Mack:
>
> I understand your issues, and in the banking community, there may be very
> limited corss certification.
>
> I was simply trying to point out that the issuance of a cross certificate
> from CA_a to CA_b need not cause every certificate issued by CA_b become
> valid to the community that consider CA_a to be a trusted root.  If there
> is an easily identified subset of CA_b's community and CA_a trusts CA_b
> correctly validate the membership in that subset, then cross certification
> is an appropriate mechanism.  Trust is the center of this issue.  You
> correctly point out that bankers like to minimize the number of people (and
> orgianizations) that they need to trust.  It greatly simplifies the risk
> analysis and risk management.
>
> Russ
>
> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote:
> >For: IETF-PKIX Mailing list
> >
> >From: "Russ Housley"<[email-masked]>
> >
> >> 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".))
> >
> >An example, the trusted relationships between UNIX nodes.  One can
> >make the point that the Rhost kind of trust is similar to the
> >cross-certification model.  Rhost type of trust has done nothing
> >but get lots of people into lots and lots of trouble.
> >
> >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."
> >
> >Some people think banks trust each other through their Am Bnks Ass
> >number (like on the checks).  Anyone who has gotten a bounced check
> >knows this is not the case.  Knowing the "naming" and "addressing"
> >(name constraints!) does not increase the level of trust.
> >
> >Keeping naming constraints current - or even manageable - is the
> >full time task for lots of people in the mainframe world.
> >Keeping that trust (usually in one place - like RACF or ACF2)
> >is a full time job that often goes horribly wrong.
> >
> >
> >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?
> >
> >-   -    -    -    -    -    -    -    -    -    -    -    -
> >Mack Hicks (415) 278-7230  -- Interactive Banking Division
> >425 1st St m/s3671, SF CA 94105 <[email-masked]>
> >

Date:         Sun, 4 Jan 1998 21:57:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
To: [email-masked]
Status:

Alan Buffett
01/04/98 09:57 PM

subscribe

Date:         Sat, 3 Jan 1998 12:22:14 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] OCSP Change Request
To: [email-masked]
Status:

Steve,

At 12:56 PM 12/31/97 +0000, Stephen Farrell wrote:
>Hi Mike,
>
>> >1. The standard response message should include a MessageId field. This
>> >allows the client to reference a response previously received which
>> >contains a path deemed unacceptable by the OCSP client. Note that this
>> >does not affect caching of responses. (A HREF would also suffice.)
>>
>> A MessageId field sounds like a useful request extension.  It would however
>> predictably extend the complexity of an OCSP server such it must maintain
>> this state information in addition to, for example, nonce information.
>
>I agree that MessageId is a request extension, but would like it to
>be a standard part of the response. I can see that it introduces some
>state into a server which supports the request extension, however,
>that statefulness is required in order to produce a "next" path
>for the same request.

Would it be sufficient for your needs that MessageID be present in the
response if present in the request?

>
>> >2. The standard response should include the base64 encoding of the entire
>> >path and set of CRLs used to verify the certificate. There is very little
>> >overhead involved as the OCSP server must possess all the relevant
>> >items.
>>
>> I agree the OCSP server may have this information on hand, but its
>> inclusion in the default case would be overkill for environments with
>> well-defined trust paths.  Also, I hadn't seen OCSP as an alternate CRL
>> retrieval mechanism.  In some instances OCSP deployment, there may not be
>> any CRLs to send back.
>
>I guess we're assuming different environments. I'd like that the
>OCSP server and its clients needn't necessarily share well-defined
>trust paths.
>
>How about if the standard response were to contain the full certification
>path used by the OCSP server with a way of using the extension mechanism
>for the client to ask for a copy of the CRLs used?

I would expect in most instances the full certification path would be
redundant information.  SSL and SMIME clients already have means of
receiving (and do receive) this information as an aspect of those security
protocols.  What value is there in receiving what I already have stored on
my machine?

I would like to look at some details of how this is actually going to work
in practice first.  How do you see chaining working?  Are cross
certificates involved?  How is each signature in the chain validated?
>
>> >3. A request extension should be defined which means "give me the next
>> >path for response <<MessageId>>". The response should contain an
>> >alternate certification path (+ CRLs) for the initial request. Of
course the
>> >second response contains a different MessageId so that iteration is
>> >supported. Again this response can be cached without problems. (Or
>> >nothing is needed if a HREF is present.)
>>
>> Might I ask that a draft of this proposed use of OCSP extensibility be
>> drawn up, roughly in line with the briefing of this approach to extensions
>> as discussed in D.C.?
>
>Fair enough. I'll try to do that in the next week or so.

OK.

>
>Meanwhile, I think it'd be worthwhile addressing the issue below on
>the list.
>
>> >In addition I'd note that the OCSP server should be chosen by (e.g.
>> >configured into) the OCSP client. Using a cert extension to name the OCSP
>> >server seems to open up security holes - e.g. it would allow the OCSP
server
>> >to masquerade as a CA to any of its clients..
>>
>> The contents of the certificate would be trusted to the extent the
>> signature on the certificate is trusted.
>
>I guess I basically don't like the situation where a certificate
>contains the location of the OCSP server - it seems too much like making
>the OCSP server into a root CA for the client (unless the OCSP server
>actually is a root CA for the client, which is maybe what you had in
>mind).

An OCSP server is simply another means of acquiring the same information we
would otherwise acquire via CRLs, albeit in a more timely fashion.  It is
to a large degree equivalent to a URL in CRLDistributionPoints locating a
CRL on a particular Web server.

>
>How do you actually see this working? Do you in fact expect that certs
>will contain the location of the OCSP server? If so, how does a client
>know that it should trust the named OCSP server? Maybe I'm just
>misreading the draft, but I'd like to see this spelt out.

The use of AuthorityInfoAccess in end-entity certificate maps to the
well-defined notion of CRLDistributionPoints.  Now, if one doesn't trust
the CRLDistributionPoints asserted by the issuer of a certificate, one is
free to configure one's client to acquire this same information elsewhere.
Similarly, if one doesn't trust the AuthorityInfoAccess content a CA places
into a certificate, local configuration of the client can override.

Mike

Date:         Thu, 1 Jan 1998 15:57:43 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
To: [email-masked]
Status:

Dave:

At 02:35 PM 12/31/97 -0500, David P. Kemp wrote:
>Warwick (and Bob),
>  You are correct; I did not make a distinction between "recognize"
>and "support".  A hypothetical implementation might recognize a particular
>extension but not, for some reason, claim for compliance purposes to
>support it.  Would the following rule be more suitable?
>
>  "If an implementation claims PKIX-compliant support for a particular
>   extension, where the scope of "support" is specified in the
>   extension definition, then when processing that extension the value
>   of the critical flag SHALL be ignored."
>
>
>In the case of certificatePolicies, "recognize" or "support" means that
>the application must support both the certificatePolicies extension
>{ id-ce 32 } itself and at least one of the policies (specified by
>the policyIdentifier field) contained in the extension.

No, I don't think this solves the whole problem.  I think John is right in
pointing out a design weakness in X.509, with respect to the definition of
the Certificate Policies extension.  Fact of the matter is that "Critical
Certificate Policies" extension and "Noncritical Certificate Policies"
extension really should be two different extension types, since they have
quite different semantics.  Use of the criticality indicator to signify
different behaviour is not a good thing.

In fact, there is an even bigger problem ... I have run across scenarios
where you might want to have both a "Critical Certificate Policies"
extension and a "Noncritical Certificate Policies" extension in the one
cert, and that, of course, is not permitted.

In retrospect, I feel we should have defined two extension types (they can
both have the same syntax) -- say, "Certificate Policies Restriction" and
"Supported Certificate Policies".  I am unsure, however, if it would be a
good thing to try to fix this in X.509 at this stage.  (I can certainly
raise this as a new defect at the January X.500 meeting if the PKIX group
thinks this a good idea.)

Warwick
-------------

>> From: John Pawling <[email-masked]>
>>
>> Dave,
>>
>> X.509, Sec 12.4.3, certificate check, bullet 6 states:
>> "d) If the certificate policies extension is present and is flagged
>> critical, compute the intersection of the policies in that extension and
the
>> authority-constrained-policy-set and put the result as the new value of
>> authority-constrained-policy-set. Check that the intersection of
>> authority-constrained-policy-set and user-constrained-policy-set is
non-empty."
>>
>> If certificate-processing software followed your proposed rule, then it
>> wouldn't be allowed to use the value of the certificate policies extension
>> critical flag as part of the certification path validation process
specified
>> in X.509, Sec 12.4.3.  Therefore, your statement is contradictory to X.509
>> and should not be added to PKIX I.
>
>
>I submit that this contradiction is a red flag that a design inconsistency
>exists in X.509.
>
>A CA has three options with respect to including a particular extension in
>a certificate:  not present, non-critical, and critical.
>
>An application has two options: claim support for an extension or not claim
>support.
>
>The processing of a particular extension by an application may have the
>following outcomes:
>
>                 |           Application:
>      Cert:      | Not supported     Supported
>                 |----------------|-------------
>    absent       |     N/A        |    N/A
>                 |                |
>    non-critical |    Ignore      |  Process
>                 |                |
>    critical     |  Reject cert   |  Process
>
>
>The path validation procedure described in section 12.4.3 introduces
>a third column to processing model:
>
>                 |---------------
>    absent       |     N/A
>                 |
>    non-critical |   Process-A
>                 |
>    critical     |   Process-B
>
>
>The use of a single flag for two independent purposes (managing
>compatibility with non-supporting applications, and selecting different
>processing in supporting applications) sounds like a mistake.
>
>Is there really a need for the phrase "and is flagged critical" to be
>included in certificate checks paragraph d)?  If not, it should be
>removed from X.509.
>
>If there is an operational requirement for both certificatePolicies
>that are used as input to authority-constrained-policy-set, and
>policies that are present in a cert but not used as input to a-c-p-s,
>then two different extensions should be defined to specify the two
>different processing procedures.  My suspicion is that there is no such
>operational requirement.
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 30 Jan 1998 16:17:45 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Usage
Comments: To: [email-masked]
To: [email-masked]
Status:

I think we agree in spirit, but the devil is in the details

>From the standpoint of the export police, everything that is not
explicitly allowed is forbidden, so saying something is meaningless
doesn't quite go far enough. "Meaningless" doesn't imply "forbidden",
but perhaps it should, at least with respect to compliance with current
US export law and the import/usage laws of some countries as well.

I really wasn't thinking about turnign on say Encipher Only and
Digital Signature in the same key usage flag -- I was more concerned that
turning on Digital Signaturedidn't necessarily turn off Encipher.

Since turning on nothing and/or leaving the key usage flag out
entirely is pemitted, it is a little hard to argue that turning on one
bit (Digital Signature) suddenly means that something that was
permitted previously (Encipher) is no longer permitted.

Conformance with X.509 really isn't the issue, it is conformance
with the export/import guidleines.

I want to think just a lttle bit more about it, but at present I believe
the Critical flag is not particularly germane to the argument --
neither the subject nor the CA care particularly what use the recipient
makes of the public key, unless the subject would not be able to
decrypt a message sent to him using a public key that
was limited to being used for signature validation. But a country with
a usage constraint, e.g., France, might care.

One example of where public key encryption is used without
keyAgreement being set is in the SET protocol, where the account
number is encrypted directly using strong RSA encryption and a 56-bit
DES key is also encrypted -- i.e., a mixed usage.  The SET designers
had to get a special exemption for that usage, and were succesful
only because of the overall system context.

Bob

>>> Simonetti David <[email-masked]> 01/30 11:22 AM >>>
Let me take that back...

If I were designing an application, my application would only look for
the encipherOnly and decipherOnly key usages if the keyAgreement bit was
set.  I would only be looking for the keyAgreement bit if I was
attempting to execute a key agreement.

Thus, assuming a critical Key Usage extension, my application should not
allow any form of encryption-type processing unless either the
keyEncipherment bit or keyAgreement bit is set.  Then, the statement in
X.509 of the bits being meaningless with usages other than keyAgreement
is quite accurate.  Having them set with digitalSignature would not mean
anything; they would be ignored, and as long as keyAgreement or
keyEncipherment is not set, the key could never be used for encryption
purposes (assuming X.509-compliance).

Dave S.

Simonetti David wrote:
>
> Bob,
>
> X.509 defines encipherOnly and decipherOnly to be meaningful only when
> used with keyAgreement, and states "meaning with other key usage bit set
> is undefined".  I read into this as:  using these two key usages with
> any bit other than keyAgreement set is an invalid use resulting in
> certificate rejection.
>
> Dave S.
>
> Bob Jueneman wrote:
> >
> > Dave, that makes sense.
> >
> > But I would like to further clarify within your paragraph the distinction between
> > Encipher Only or Decipher Only (with or without key agreement), and Digital
> > Signature (with or without Nonrepudiation).
> >
> > In order to obtain a more enlightened approach to export controls, applications
> > and operating systems would like to enforce key usages so that a public key
> > that is intended to used to validate a digital signature cannot be used to
> > encrypt data, either directly, or via a key exchange key.
> >
> > Ideally, the combination of Encipher Only with either Digital Signature or
> > Nonrepudiation should be made an invalid state.  It would be interesting to
> > know if any existing protocols would break in that case.  If that isn't
> > acceptable, the next best thing would be for PKIX  to deprecate such a
> > usage, but that might not be acceptable either. At a minimum, however, we
> > ought to point out the potentially unfavorable export treatment any application
> > making use of such a key usage would receive. The combination of
> > Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.
> >
> > Of course keys that don't have any restrictive key usages will receive the
> > most general, i.e., from an export considerations standpoint, most restrictive
> > treatment, and that probably ought to be pointed out as well.
> >
> > Bob
> >
> > >Tim,
> > >
> > >I have proposed the following text be added to the profile to further
> > >clarify these two key usages.  I don't know whether or not my proposal
> > >was accepted.  I truely believe this text should be added to X.509.
> > >
> > >"The encipherOnly and decipherOnly key usages are intended to provide
> > >support for key agreement schemes where separate shared secret keys are
> > >used in each direction of communication.  In such a scheme, a user has
> > >more than one set of key pairs and bits 7 (encipherOnly) and 8
> > >(decipherOnly) are used to distinguish between the two types.  The
> > >originator of a message would use the recipient's public key certificate
> > >with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
> > >encryption key.  The recipient would use the originator's certificate
> > >with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
> > >encryption key.  Typically the originator would pass his or her own
> > >certificate with bits 4 and 8 along with the message."
> > >
> > >Regards,
> > >
> > >Dave S.
> > >
> > >Tim Dierks wrote:
> > >>
> > >> Could someone explain to me what the following paragraph means (section
> > >> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
> > >>
> > >>       When the decipherOnly bit is asserted and the keyAgreement bit is
> > >>       also set, the subject public key may be used only for deciphering
> > >>       data while performing key agreement.  The meaning of the
> > >>       decipherOnly bit is undefined in the absence of the keyAgreement
> > >>       bit.
> > >>
> > >> When would one use a public key to decipher a key agreement? Does this have
> > >> something to do with signatures? Whats more, I thought key agreement
> > >> referred to Diffie-Hellman and similar algorithms, which I don't easily
> > >> conceive of as doing signatures or encipherment. What's up?
> > >>
> > >> Thanks,
> > >>  - Tim
> > >>
> > >> Tim Dierks - [email-masked] - www.consensus.com
> > >>   Director of Engineering - Consensus Development
> > >>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Hal Lockhart <[email-masked]>
Date:         Fri, 30 Jan 1998 16:56:38 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] draft question
To: [email-masked]
Status:

At 12:19 PM 1/30/98 -0500, Gina DePlanche wrote:
>        I have a question regarding section 7.2.1 of the internet draft
>X.509 Certificate and CRL Profile (draft-ietf-pkix-ipki-part1-06.txt)
>
>        This section discusses using RSA with MD2, MD5 or SHA-1.
>
>        My question is regarding the RSA portion. My understanding is
>that RSA has 2 algorithms: RC4-40 and RC4-128. Is this the RSA section
>7.2.1 is referring to?

No.

RSA refers to the RSA public key algorithm, the patent to which is held by
RSA Data Security Inc. (RSADSI).  RSADSI also holds intellectual property
rights to a number of other algorithms, including the RC4 secret key
algorithm.

Other than their common origin, there is no relationship between RSA and RC4.

Regards,

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum technology, Solutions
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Approved-By: [email-masked]
Date:         Fri, 30 Jan 1998 12:19:33 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] draft question
To: [email-masked]
Status:

        I have a question regarding section 7.2.1 of the internet draft
X.509 Certificate and CRL Profile (draft-ietf-pkix-ipki-part1-06.txt)

        This section discusses using RSA with MD2, MD5 or SHA-1.

        My question is regarding the RSA portion. My understanding is
that RSA has 2 algorithms: RC4-40 and RC4-128. Is this the RSA section
7.2.1 is referring to? If so, how are the two algorithms distinguished
from the one object identifier (eg. md5WithRSAEncryption)?

        If I'm way off base, could someone please point me in the right
direction?

        Thanks for the help!

        - Gina

--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Approved-By:  Simonetti David <[email-masked]>
Date:         Fri, 30 Jan 1998 13:22:24 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Key Usage
To: [email-masked]
Status:

Let me take that back...

If I were designing an application, my application would only look for
the encipherOnly and decipherOnly key usages if the keyAgreement bit was
set.  I would only be looking for the keyAgreement bit if I was
attempting to execute a key agreement.

Thus, assuming a critical Key Usage extension, my application should not
allow any form of encryption-type processing unless either the
keyEncipherment bit or keyAgreement bit is set.  Then, the statement in
X.509 of the bits being meaningless with usages other than keyAgreement
is quite accurate.  Having them set with digitalSignature would not mean
anything; they would be ignored, and as long as keyAgreement or
keyEncipherment is not set, the key could never be used for encryption
purposes (assuming X.509-compliance).

Dave S.

Simonetti David wrote:
>
> Bob,
>
> X.509 defines encipherOnly and decipherOnly to be meaningful only when
> used with keyAgreement, and states "meaning with other key usage bit set
> is undefined".  I read into this as:  using these two key usages with
> any bit other than keyAgreement set is an invalid use resulting in
> certificate rejection.
>
> Dave S.
>
> Bob Jueneman wrote:
> >
> > Dave, that makes sense.
> >
> > But I would like to further clarify within your paragraph the distinction between
> > Encipher Only or Decipher Only (with or without key agreement), and Digital
> > Signature (with or without Nonrepudiation).
> >
> > In order to obtain a more enlightened approach to export controls, applications
> > and operating systems would like to enforce key usages so that a public key
> > that is intended to used to validate a digital signature cannot be used to
> > encrypt data, either directly, or via a key exchange key.
> >
> > Ideally, the combination of Encipher Only with either Digital Signature or
> > Nonrepudiation should be made an invalid state.  It would be interesting to
> > know if any existing protocols would break in that case.  If that isn't
> > acceptable, the next best thing would be for PKIX  to deprecate such a
> > usage, but that might not be acceptable either. At a minimum, however, we
> > ought to point out the potentially unfavorable export treatment any application
> > making use of such a key usage would receive. The combination of
> > Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.
> >
> > Of course keys that don't have any restrictive key usages will receive the
> > most general, i.e., from an export considerations standpoint, most restrictive
> > treatment, and that probably ought to be pointed out as well.
> >
> > Bob
> >
> > >Tim,
> > >
> > >I have proposed the following text be added to the profile to further
> > >clarify these two key usages.  I don't know whether or not my proposal
> > >was accepted.  I truely believe this text should be added to X.509.
> > >
> > >"The encipherOnly and decipherOnly key usages are intended to provide
> > >support for key agreement schemes where separate shared secret keys are
> > >used in each direction of communication.  In such a scheme, a user has
> > >more than one set of key pairs and bits 7 (encipherOnly) and 8
> > >(decipherOnly) are used to distinguish between the two types.  The
> > >originator of a message would use the recipient's public key certificate
> > >with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
> > >encryption key.  The recipient would use the originator's certificate
> > >with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
> > >encryption key.  Typically the originator would pass his or her own
> > >certificate with bits 4 and 8 along with the message."
> > >
> > >Regards,
> > >
> > >Dave S.
> > >
> > >Tim Dierks wrote:
> > >>
> > >> Could someone explain to me what the following paragraph means (section
> > >> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
> > >>
> > >>       When the decipherOnly bit is asserted and the keyAgreement bit is
> > >>       also set, the subject public key may be used only for deciphering
> > >>       data while performing key agreement.  The meaning of the
> > >>       decipherOnly bit is undefined in the absence of the keyAgreement
> > >>       bit.
> > >>
> > >> When would one use a public key to decipher a key agreement? Does this have
> > >> something to do with signatures? Whats more, I thought key agreement
> > >> referred to Diffie-Hellman and similar algorithms, which I don't easily
> > >> conceive of as doing signatures or encipherment. What's up?
> > >>
> > >> Thanks,
> > >>  - Tim
> > >>
> > >> Tim Dierks - [email-masked] - www.consensus.com
> > >>   Director of Engineering - Consensus Development
> > >>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Simonetti David <[email-masked]>
Date:         Fri, 30 Jan 1998 12:55:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Key Usage
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

Bob,

X.509 defines encipherOnly and decipherOnly to be meaningful only when
used with keyAgreement, and states "meaning with other key usage bit set
is undefined".  I read into this as:  using these two key usages with
any bit other than keyAgreement set is an invalid use resulting in
certificate rejection.

Dave S.

Bob Jueneman wrote:
>
> Dave, that makes sense.
>
> But I would like to further clarify within your paragraph the distinction between
> Encipher Only or Decipher Only (with or without key agreement), and Digital
> Signature (with or without Nonrepudiation).
>
> In order to obtain a more enlightened approach to export controls, applications
> and operating systems would like to enforce key usages so that a public key
> that is intended to used to validate a digital signature cannot be used to
> encrypt data, either directly, or via a key exchange key.
>
> Ideally, the combination of Encipher Only with either Digital Signature or
> Nonrepudiation should be made an invalid state.  It would be interesting to
> know if any existing protocols would break in that case.  If that isn't
> acceptable, the next best thing would be for PKIX  to deprecate such a
> usage, but that might not be acceptable either. At a minimum, however, we
> ought to point out the potentially unfavorable export treatment any application
> making use of such a key usage would receive. The combination of
> Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.
>
> Of course keys that don't have any restrictive key usages will receive the
> most general, i.e., from an export considerations standpoint, most restrictive
> treatment, and that probably ought to be pointed out as well.
>
> Bob
>
> >Tim,
> >
> >I have proposed the following text be added to the profile to further
> >clarify these two key usages.  I don't know whether or not my proposal
> >was accepted.  I truely believe this text should be added to X.509.
> >
> >"The encipherOnly and decipherOnly key usages are intended to provide
> >support for key agreement schemes where separate shared secret keys are
> >used in each direction of communication.  In such a scheme, a user has
> >more than one set of key pairs and bits 7 (encipherOnly) and 8
> >(decipherOnly) are used to distinguish between the two types.  The
> >originator of a message would use the recipient's public key certificate
> >with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
> >encryption key.  The recipient would use the originator's certificate
> >with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
> >encryption key.  Typically the originator would pass his or her own
> >certificate with bits 4 and 8 along with the message."
> >
> >Regards,
> >
> >Dave S.
> >
> >Tim Dierks wrote:
> >>
> >> Could someone explain to me what the following paragraph means (section
> >> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
> >>
> >>       When the decipherOnly bit is asserted and the keyAgreement bit is
> >>       also set, the subject public key may be used only for deciphering
> >>       data while performing key agreement.  The meaning of the
> >>       decipherOnly bit is undefined in the absence of the keyAgreement
> >>       bit.
> >>
> >> When would one use a public key to decipher a key agreement? Does this have
> >> something to do with signatures? Whats more, I thought key agreement
> >> referred to Diffie-Hellman and similar algorithms, which I don't easily
> >> conceive of as doing signatures or encipherment. What's up?
> >>
> >> Thanks,
> >>  - Tim
> >>
> >> Tim Dierks - [email-masked] - www.consensus.com
> >>   Director of Engineering - Consensus Development
> >>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Fri, 30 Jan 1998 09:54:46 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Usage
Comments: To: [email-masked]
To: [email-masked]
Status:

Dave, that makes sense.

But I would like to further clarify within your paragraph the distinction between
Encipher Only or Decipher Only (with or without key agreement), and Digital
Signature (with or without Nonrepudiation).

In order to obtain a more enlightened approach to export controls, applications
and operating systems would like to enforce key usages so that a public key
that is intended to used to validate a digital signature cannot be used to
encrypt data, either directly, or via a key exchange key.

Ideally, the combination of Encipher Only with either Digital Signature or
Nonrepudiation should be made an invalid state.  It would be interesting to
know if any existing protocols would break in that case.  If that isn't
acceptable, the next best thing would be for PKIX  to deprecate such a
usage, but that might not be acceptable either. At a minimum, however, we
ought to point out the potentially unfavorable export treatment any application
making use of such a key usage would receive. The combination of
Decpither Only (with your interpretation) and either digital Signature aor Nonrepudiation would also be subject to the same constraints.

Of course keys that don't have any restrictive key usages will receive the
most general, i.e., from an export considerations standpoint, most restrictive
treatment, and that probably ought to be pointed out as well.

Bob

>Tim,
>
>I have proposed the following text be added to the profile to further
>clarify these two key usages.  I don't know whether or not my proposal
>was accepted.  I truely believe this text should be added to X.509.
>
>"The encipherOnly and decipherOnly key usages are intended to provide
>support for key agreement schemes where separate shared secret keys are
>used in each direction of communication.  In such a scheme, a user has
>more than one set of key pairs and bits 7 (encipherOnly) and 8
>(decipherOnly) are used to distinguish between the two types.  The
>originator of a message would use the recipient's public key certificate
>with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
>encryption key.  The recipient would use the originator's certificate
>with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
>encryption key.  Typically the originator would pass his or her own
>certificate with bits 4 and 8 along with the message."
>
>Regards,
>
>Dave S.
>
>Tim Dierks wrote:
>>
>> Could someone explain to me what the following paragraph means (section
>> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
>>
>>       When the decipherOnly bit is asserted and the keyAgreement bit is
>>       also set, the subject public key may be used only for deciphering
>>       data while performing key agreement.  The meaning of the
>>       decipherOnly bit is undefined in the absence of the keyAgreement
>>       bit.
>>
>> When would one use a public key to decipher a key agreement? Does this have
>> something to do with signatures? Whats more, I thought key agreement
>> referred to Diffie-Hellman and similar algorithms, which I don't easily
>> conceive of as doing signatures or encipherment. What's up?
>>
>> Thanks,
>>  - Tim
>>
>> Tim Dierks - [email-masked] - www.consensus.com
>>   Director of Engineering - Consensus Development
>>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Richard Salz <[email-masked]>
Date:         Fri, 30 Jan 1998 09:39:51 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Richard Salz <[email-masked]>
Subject:      [IETF-PKIX] Please, enough linebreak discussion
To: [email-masked]
Status:

If you want the MIME WG's, you know where to find them. :)

Look, Bob Juenemann once again is having problems sending out well-formed
messages.  Messages should be word-wrapped between 72 and 78 columns,
or use a fancier mime type.  The latter isn't happening and the author
apparently finds it too tedious to do the former.  Seems to me the tradeoff
is pretty simple -- inconvenience one person, or inconvenience many
potential readers.  (No real skin off my nose, I can just delete them
without bothering to read past the first screenful of ugliness.)

I didn't know MIME was a pre-requisite for participating here.  Did I
miss something?
        /r$

Approved-By:  Simonetti David <[email-masked]>
Date:         Fri, 30 Jan 1998 09:26:59 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Simonetti David <[email-masked]>
Organization: BAH
Subject:      Re: [IETF-PKIX] Key Usage
To: [email-masked]
Status:

Tim,

I have proposed the following text be added to the profile to further
clarify these two key usages.  I don't know whether or not my proposal
was accepted.  I truely believe this text should be added to X.509.

"The encipherOnly and decipherOnly key usages are intended to provide
support for key agreement schemes where separate shared secret keys are
used in each direction of communication.  In such a scheme, a user has
more than one set of key pairs and bits 7 (encipherOnly) and 8
(decipherOnly) are used to distinguish between the two types.  The
originator of a message would use the recipient's public key certificate
with bits 4 (keyAgreement) and 7 (encipherOnly) to create a key
encryption key.  The recipient would use the originator's certificate
with bits 4 (keyAgreement) and 8 (decipherOnly) to create the key
encryption key.  Typically the originator would pass his or her own
certificate with bits 4 and 8 along with the message."

Regards,

Dave S.

Tim Dierks wrote:
>
> Could someone explain to me what the following paragraph means (section
> 4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?
>
>       When the decipherOnly bit is asserted and the keyAgreement bit is
>       also set, the subject public key may be used only for deciphering
>       data while performing key agreement.  The meaning of the
>       decipherOnly bit is undefined in the absence of the keyAgreement
>       bit.
>
> When would one use a public key to decipher a key agreement? Does this have
> something to do with signatures? Whats more, I thought key agreement
> referred to Diffie-Hellman and similar algorithms, which I don't easily
> conceive of as doing signatures or encipherment. What's up?
>
> Thanks,
>  - Tim
>
> Tim Dierks - [email-masked] - www.consensus.com
>   Director of Engineering - Consensus Development
>   Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  "Phillip H. Griffin" <[email-masked]>
Date:         Fri, 30 Jan 1998 08:42:04 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Doug Beattie wrote:
>
> I use Outlook and it looks fine.  I POP my mail off of a POP mail server, not through the Exchange mail server at GTE.  Maybe that makes some difference.
>
> Doug

Maybe. I must select "Wrap long lines" on the "View" pull down
menu of the Netscape 3.0 action bar to force your one line to
display properly as formatted multiple lines. Notice that when
using "Reply to all", that your one line has but a single ">"
in front of "I". Not sure what it looks like when you get it.

Phil

Approved-By:  Doug Beattie <[email-masked]>
Date:         Fri, 30 Jan 1998 08:02:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Doug Beattie <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

I use Outlook and it looks fine.  I POP my mail off of a POP mail server, not through the Exchange mail server at GTE.  Maybe that makes some difference.

Doug

-----Original Message-----
From:   Bob Jueneman [SMTP:[email-masked]]
Sent:   Wednesday, January 28, 1998 9:48 PM
To:     [email-masked]
Subject:        Re: [IETF-PKIX] Line break problem

Thanks, Sam, but I have received a sufficient number of
responses from people using Eudora, Microsoft Outlook,
elm, pine, and other programs to convince me that the problem
is at my end.  Until we can resolve the problem, I guess I'll have
to go back to using manual carriage returns.

Thanks for the feedback, people, and my apologies for wasting
your time and bandwidth.

Bob
>
>
>>>> Sam Schaen <[email-masked]> 01/28 8:44 PM >>>
>In Communicator 4.0x, there is a "wrap long lines" option that needs to be checked to avoid
>the problem described.

Approved-By: [email-masked]
Date:         Thu, 29 Jan 1998 07:55:52 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Bob:

Groupwise wrapped it just fine.

Michael

>>> Bob Jueneman <[email-masked]> 01/28/98 05:05PM >>>
Two people have recently complained that my messages create line lengths
that are too long, and hard to read. This used to be a problem with GroupWise,
and I had to manually insert line breaks, but the problem was solved some time ago
at our gateway.

So either it is back, or something else is going on.

So far, the two people that have complained are using NetScape Communicator, and
both are outside the US, which makes me wonder whether there is a NetScape (export-version) problem.

So let me test this. This paragraph is written as one long line, and should be automatically line wrapped and broken. If it is not, and if you are using anything other than Communicator please let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send me mail for the same problem.)

Likewise, if someone is using Netscape Communicator 3.01 in a non-US version who is NOT having any particular difficulty reading this paragraph, please let me know as well.

I'd like to fix it, but don't know what's wrong.

Bob
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
!

Approved-By:  Tim Dierks <[email-masked]>
Date:         Thu, 29 Jan 1998 17:15:49 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject:      [IETF-PKIX] Key Usage
To: [email-masked]
Status:

Could someone explain to me what the following paragraph means (section
4.2.1.3 of draft-ietf-pkix-ipki-part1-06)?

      When the decipherOnly bit is asserted and the keyAgreement bit is
      also set, the subject public key may be used only for deciphering
      data while performing key agreement.  The meaning of the
      decipherOnly bit is undefined in the absence of the keyAgreement
      bit.

When would one use a public key to decipher a key agreement? Does this have
something to do with signatures? Whats more, I thought key agreement
referred to Diffie-Hellman and similar algorithms, which I don't easily
conceive of as doing signatures or encipherment. What's up?

Thanks,
 - Tim

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

From: [email-masked]
Date: Fri, 30 Jan 1998 2:15:39 +0000
To: [email-masked]
Cc: [email-masked]
Subject: TLS Extended Key Usage
Status:

####################################################
This message was not delivered to
[email-masked] 
TFS Admin was informed with a copy of this message
Sender was informed with a copy of this message
####################################################
I'd like to suggest that the word "Web" be stricken from the following
descriptions (in section 4.2.1 of draft-ietf-pkix-ipki-part1-06.txt), as
HTTP and the WWW is only one of many uses for TLS.

   id-kp-serverAuth              OBJECT IDENTIFIER ::=   {id-kp 1}
   -- TLS Web server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   --                         keyEncipherment or keyAgreement
   --
   id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}
   -- TLS Web client authentication
   -- Key usage bits that may be consistent: digitalSignature and/or
   --                            keyAgreement
   --

Thanks,

 - Tim Dierks

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By: [email-masked]
Date:         Thu, 29 Jan 1998 15:57:34 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject:      [IETF-PKIX] TLS Extended Key Usage
Comments: cc: "ietf-tls (Transport Layer Security WG)" <[email-masked]>
To: [email-masked]
Status:

I'd like to suggest that the word "Web" be stricken from the following
descriptions (in section 4.2.1 of draft-ietf-pkix-ipki-part1-06.txt), as
HTTP and the WWW is only one of many uses for TLS.

   id-kp-serverAuth              OBJECT IDENTIFIER ::=   {id-kp 1}
   -- TLS Web server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   --                         keyEncipherment or keyAgreement
   --
   id-kp-clientAuth              OBJECT IDENTIFIER ::=   {id-kp 2}
   -- TLS Web client authentication
   -- Key usage bits that may be consistent: digitalSignature and/or
   --                            keyAgreement
   --

Thanks,

 - Tim Dierks

Tim Dierks - [email-masked] - www.consensus.com
  Director of Engineering - Consensus Development
  Developer of SSL Plus: SSL 3.0 Integration Suite

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 29 Jan 1998 14:14:59 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

At 01:37 PM 1/29/98 -0500, David P. Kemp wrote:
>That is an example of where the "gotcha" rule on IMPLICIT tagging
>applies :-)
>
>X.680 section 28.6:

Um, we're not using X.680, we're using X.208. Is that what X.208 says as well?

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 29 Jan 1998 13:37:41 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

> From: Nilsson Hans <[email-masked]>
>
> I think there are some errors on page 107 and 108 in the PKIX-1 draft
> for the coding of the subjectAltName:
>
> Where it says
> rfc822name
> a1 1a
> IA5String
> 16 18 65 73 65..
>
> it should read
>
> rfc822name
> 81 18
> 65 73 65...
>
> since the Certificate Extensions module specifies IMPLICIT tage. Hence
> IMPLICIT tags must be used for selecting the rfc822name choice in the
> subjectAltName extension
>
> The same error then also exists for the uniformResourceIdentifier, a6 16
> 16 14 68... when then should read
> 86 14 68...
>
> Can please some ASN.1/DER expert confirm or prove me wrong?
>
> Hans Nilsson
> AU-System, Stockholm, Sweden

That is an example of where the "gotcha" rule on IMPLICIT tagging
applies :-)

X.680 section 28.6:

  The tagging construction specifies explict tagging if any of the
  following holds:
    a) ..
    b) ..
    c) the "Tag Type" alternative is used an the value of TagDefault for
       the module is "IMPLICIT TAGS" or "AUTOMATIC TAGS", but the type
       defined by "Type" is a choice type, open type, or a DummyReference.

so even in an IMPLICIT TAGS module, GeneralName (a CHOICE) is encoded
using explicit tagging, as shown in the PKIX-1 example.

Approved-By:  Tolga Acar <[email-masked]>
Date:         Thu, 29 Jan 1998 13:16:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tolga Acar <[email-masked]>
Subject:      Re: [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

-- Tolga

>>> Nilsson Hans <[email-masked]> 1/29/98 10:26:43 >>>
>Where it says
>rfc822name
>a1 1a
>IA5String
>16 18 65 73 65..

>it should read

>rfc822name
>81 18
>65 73 65...

This seems fine to me, though i'm not an expert.
a1 stands for "context-specific 1' and '1a' is the length of the underlying item, i.e., IA5String. Thus, IMPLICIT tagging used, where the underlying tag is IA5String, and the derived tag is 'context-specific [1]'.
Similar thing goes for the second argument --- uniformResourceIdentifier.
So, this should read:
subjectAltNameValue := SEQUENCE {
    rfc822name                        [1] IA5String,  -- "escert....." of length 1a octets
    uniformResourceIdentifier   [6] IA5String   -- "http:...." of length 16 octets }

>since the Certificate Extensions module specifies IMPLICIT tage. Hence
>IMPLICIT tags must be used for selecting the rfc822name choice in the
>subjectAltName extension

Approved-By:  Nilsson Hans <[email-masked]>
Date:         Thu, 29 Jan 1998 18:26:43 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nilsson Hans <[email-masked]>
Subject:      [IETF-PKIX] Errors in PKIX-1 coding examples?
To: [email-masked]
Status:

I think there are some errors on page 107 and 108 in the PKIX-1 draft
for the coding of the subjectAltName:

Where it says
rfc822name
a1 1a
IA5String
16 18 65 73 65..

it should read

rfc822name
81 18
65 73 65...

since the Certificate Extensions module specifies IMPLICIT tage. Hence
IMPLICIT tags must be used for selecting the rfc822name choice in the
subjectAltName extension

The same error then also exists for the uniformResourceIdentifier, a6 16
16 14 68... when then should read
86 14 68...

Can please some ASN.1/DER expert confirm or prove me wrong?

Hans Nilsson
AU-System, Stockholm, Sweden

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Thu, 29 Jan 1998 10:14:43 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
Comments: To: [email-masked]
To: [email-masked]
Status:

David, there seem to be two problems going on, and it is affecting more than just a few people.

First, something has apparently happened to our mail gateway, which used to insert carriage returns on outgoing Internet mail. I'm trying to find out what happened, and get it fixed.

Second, it appears that people using Netscape Communicator (and/or some other programs) may not be aware of the automatic line wrap capability it apparently has, or haven't turned it on.

This whole problem is of course a very irritating example of incompatible standards and approaches.  From my perspective, I would greatly prefer to control my own line wrapping, by resizing the display window and choosing the default font however I like, rather than being at the mercy of someone else's notion of what screen size and resolution looks nice.  I hate it when people write messages using little tiny lines, tiny little fonts, or great big fonts for that matter -- it's too hard to read. I also hate it when lines that were automatically broken neatly now roll over to the next line because of the line quoting conventions. Seems to me that we should have gotten away from 80 column cards and 72 column Fortran lines a long, long time ago -- I'll bet that a some of the people reading this list may never have even seen a punched card!

>From my perspective, I would  prefer to use a single > character at the beginning of the _paragraph_ to indicate quoted text, and let the line wrapping flow naturally at the _recipient's_ end. But a substantial percentage of the Internet community doesn't seem to see it that way, and I can't roll that stone up the hill by myself.

All I know is that life is too short to spend it manually inserting carriage returns after every so many characters, so I have to solve the problem somehow. Maybe we should all go back to using typewriters with little bells, and a carriage return bar that has to be thrown at the end of the line.  It would probably improve my right arm's muscle tone, too!

I promise this is last message on this topic to this list.

Bob

>>>> David P. Kemp <[email-masked]> 01/29 8:51 AM >>>
>>
>> So far, the two people that have complained are using NetScape Communicator, and
>> both are outside the US, which makes me wonder whether there is a NetScape (export-
>version) problem.
>>
>> So let me test this. This paragraph is written as one long line, and should be automatically line
>wrapped and broken. If it is not, and if you are using anything other than Communicator please
>let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send
>me mail for the same problem.)
>>
>
>Bob,
>  I'm using the Sun mail tool on a Solaris system, and your messages
>come through without line breaks.  It's easy enough to fix, since
>all Sun text windows have a "format" option that wraps at 72 characters.
>
>As you see above from the inclusion characters (>), your message had
>line breaks before:
>
> > So far, ..
> > both are outside the US ...
> >
> > So let me test this ...
>
>and that last paragraph is one long line.
>
>Regards,
> dpk

Approved-By:  Nilsson Hans <[email-masked]>
Date:         Thu, 29 Jan 1998 18:19:30 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nilsson Hans <[email-masked]>
Subject:      [IETF-PKIX] Calculation of Subjet Key Identifier
To: [email-masked]
Status:

In PKIX-1, 4.2.1.2 it is stated that:

"The hash shall be calculated over the value (excluding tag and length)
of the subject public key field in the certificate."

I have been told that there is a recommendation by Netscape that the
SHA-1 digest shall be computed over the full DER-encoded
SubjectPublicKeyInfo value, i.e. including the SEQUENCE tag, length,
AlgorithmIdentifier and SubjectKey.

Could someone please clarify and tell what the "common practice" is?

Hans Nilsson
AU-System
Stockholm, Sweden

Approved-By:  Santoni Adriano <[email-masked]>
Date:         Thu, 29 Jan 1998 09:12:00 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] R: [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

Thank you.
  Adriano

> -----Messaggio originale-----
> Da:   Mark Shuttleworth [SMTP:[email-masked]]
> Inviato:      mercoled“ 28 gennaio 1998 18.09
> A:    [email-masked]
> Oggetto:      Re: [IETF-PKIX] Character sets definitions/descriptions:
> where             online?
>
> > Anybody wants to kindly point me to some site(s) where the exact and
> > clear description of the character sets PrintableString,
> VisibleString,
> > TeletexString (or T61String), IA5String, BMPString...and such, can
> be
> > found?
>
> ISO water torture, as Peter Gutmann puts it ;)
>
> Best place I've found is his X.509 Style Guide, which you can get to
> from
> his collection of security links:
>
>   http://www.cs.auckland.ac.nz/~pgut001/links.html
>
> Now bear in mind that asking for an "exact and clear" description of
> something as painful as your chosen topic of enquiry is like asking
> for
> enjoyable dentistry.  But at least it's an interesting read.
>
> --
> Mark Shuttleworth
> Thawte Consulting

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 28 Jan 1998 19:47:34 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
Comments: To: [email-masked]
To: [email-masked]
Status:

Thanks, Sam, but I have received a sufficient number of
responses from people using Eudora, Microsoft Outlook,
elm, pine, and other programs to convince me that the problem
is at my end.  Until we can resolve the problem, I guess I'll have
to go back to using manual carriage returns.

Thanks for the feedback, people, and my apologies for wasting
your time and bandwidth.

Bob
>
>
>>>> Sam Schaen <[email-masked]> 01/28 8:44 PM >>>
>In Communicator 4.0x, there is a "wrap long lines" option that needs to be checked to avoid
>the problem described.

Approved-By:  "H. Richard Schwarz" <[email-masked]>
Date:         Wed, 28 Jan 1998 20:58:15 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "H. Richard Schwarz" <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Sam,

I tried this option at 72 characters and cannot get it to work. The
lines still string well beyone the page boundaries on the screen. Any
ideas?

Dick Schwarz

Sam Schaen wrote:

> In Communicator 4.0x, there is a "wrap long lines" option that needs
> to be checked to avoid the problem described.
>
> Bob Jueneman wrote:
>
> > Two people have recently complained that my messages create line
> lengths
> > that are too long, and hard to read. This used to be a problem with
> GroupWise,
> > and I had to manually insert line breaks, but the problem was solved
> some time ago
> > at our gateway.
> >
> > So either it is back, or something else is going on.
> >
> > So far, the two people that have complained are using NetScape
> Communicator, and
> > both are outside the US, which makes me wonder whether there is a
> NetScape (export-version) problem.
> >
> > So let me test this. This paragraph is written as one long line, and
> should be automatically line wrapped and broken. If it is not, and if
> you are using anything other than Communicator please let me know. (I
> would suggest that you copy the list, so that umpty-thousand people
> don't send me mail for the same problem.)
> >
> > Likewise, if someone is using Netscape Communicator 3.01 in a non-US
> version who is NOT having any particular difficulty reading this
> paragraph, please let me know as well.
> >
> > I'd like to fix it, but don't know what's wrong.
> >
> > Bob

Approved-By:  "H. Richard Schwarz" <[email-masked]>
Date:         Wed, 28 Jan 1998 20:52:59 +0000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "H. Richard Schwarz" <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Bob,

This is a problem that I have been noticing more often lately. I am
using the U.S. version of NetScape Communicator Version 4.01a. Yes
indeed, it is a problem - but not just with email received from you or
this group.

Dick Schwarz

Bob Jueneman wrote:

> Two people have recently complained that my messages create line
> lengths
> that are too long, and hard to read. This used to be a problem with
> GroupWise,
> and I had to manually insert line breaks, but the problem was solved
> some time ago
> at our gateway.
>
> So either it is back, or something else is going on.
>
> So far, the two people that have complained are using NetScape
> Communicator, and
> both are outside the US, which makes me wonder whether there is a
> NetScape (export-version) problem.
>
> So let me test this. This paragraph is written as one long line, and
> should be automatically line wrapped and broken. If it is not, and if
> you are using anything other than Communicator please let me know. (I
> would suggest that you copy the list, so that umpty-thousand people
> don't send me mail for the same problem.)
>
> Likewise, if someone is using Netscape Communicator 3.01 in a non-US
> version who is NOT having any particular difficulty reading this
> paragraph, please let me know as well.
>
> I'd like to fix it, but don't know what's wrong.
>
> Bob

Approved-By:  Sam Schaen <[email-masked]>
Date:         Wed, 28 Jan 1998 19:44:45 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sam Schaen <[email-masked]>
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

In Communicator 4.0x, there is a "wrap long lines" option that needs to be checked to avoid the problem described.

Bob Jueneman wrote:

> Two people have recently complained that my messages create line lengths
> that are too long, and hard to read. This used to be a problem with GroupWise,
> and I had to manually insert line breaks, but the problem was solved some time ago
> at our gateway.
>
> So either it is back, or something else is going on.
>
> So far, the two people that have complained are using NetScape Communicator, and
> both are outside the US, which makes me wonder whether there is a NetScape (export-version) problem.
>
> So let me test this. This paragraph is written as one long line, and should be automatically line wrapped and broken. If it is not, and if you are using anything other than Communicator please let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send me mail for the same problem.)
>
> Likewise, if someone is using Netscape Communicator 3.01 in a non-US version who is NOT having any particular difficulty reading this paragraph, please let me know as well.
>
> I'd like to fix it, but don't know what's wrong.
>
> Bob

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 28 Jan 1998 17:24:58 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

I took a look at RFC 2104, which defines HMAC. The RFC suggests defining
the length of a truncated output by appending the legnth to the algorithm name,
e.g.,  HMAC-SHA-1-96.  I am told that SET uses HMAC-SHA-1-160, but
that no OID has been assigned.

Truncation appears to be a somewhat mixed blessing. In the particular case we are
talking about, if there is no chance that both the password and the hash can be
diddled with simultaneously, then presumably the Birthday Attack would not apply.

But in general I hate to rely on that kind of finesse analysis -- it is too easy to overlook
something.  I tend to reach for a bigger hammer and squash the sucker once and for all.

If it were up to me, and I didn't have the time to do a more detailed analysis (and I don't),
I would be inclined to use HMAC-SHA-1-128, and define an OID for that.  That would
be sufficient to defeat any Birthday Attack even if a plain-vanilla hash were being used,
and it would still provide the presumed advantages of truncation. It may or may not be
overkill, but at least it is a harmless overkill.

Carlisle, I would suggest that you review this issue with Paul van Oorshot.

Bob
>
>>>> Phillip Hallam-Baker <[email-masked]> 01/27 3:57 PM >>>
>> Note that these OIDs refer to a truncated HMAC where only the first
>> 96 bits of the outer hash output are used - this truncation is described
>> as a security advantage (it wasn't done solely to cram the MAC into
>> the IPSEC packets).
>
>The security advantage is small but significant. First note that the
>Bithday attack collision mode is not relevant since all that matters
>is the propability of collision between a specific password and a trial,
>collisions between the trials are irrelevant, hence 96 bits is more
>than enough for security.
>
>Omitting part of the MAC value means that it is not possible to crack
>a single MAC by exhaustive search, there is simply not enough
>information present. Given a single MAC the best the attacker can
>do is to derrive a large set of possible candidates (2^44 in this case).
>Narrowing the choice requires a further exhastive attack of these
>candidates against another MAC value.
>
>Oh well back to work...
>
>        Phill

Approved-By:  Amit Kapoor <[email-masked]>
Date:         Wed, 28 Jan 1998 16:32:01 -0000
Reply-To: "[email-masked]" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Amit Kapoor <[email-masked]>
Organization: Secant
Subject:      Re: [IETF-PKIX] Line break problem
To: [email-masked]
Status:

Hi Bob,

        Might I recommend that you test with the complaining people instead of
        copying the entire list.

        Appreciate it.

Amit
(BTW, I see it as a single line and I am using Microsoft Outlook)

-----Original Message-----
From:   Bob Jueneman [SMTP:[email-masked]]
Sent:   Thursday, January 29, 1998 12:06 AM
To:     [email-masked]
Subject:        [IETF-PKIX] Line break problem

Two people have recently complained that my messages create line lengths
that are too long, and hard to read. This used to be a problem with
GroupWise,
and I had to manually insert line breaks, but the problem was solved some
time ago
at our gateway.

So either it is back, or something else is going on.

So far, the two people that have complained are using NetScape
Communicator, and
both are outside the US, which makes me wonder whether there is a NetScape
(export-version) problem.

So let me test this. This paragraph is written as one long line, and should
be automatically line wrapped and broken. If it is not, and if you are
using anything other than Communicator please let me know. (I would suggest
that you copy the list, so that umpty-thousand people don't send me mail
for the same problem.)

Likewise, if someone is using Netscape Communicator 3.01 in a non-US
version who is NOT having any particular difficulty reading this paragraph,
please let me know as well.

I'd like to fix it, but don't know what's wrong.

Bob

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 28 Jan 1998 17:05:48 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] Line break problem
Comments: To: [email-masked], [email-masked]
To: [email-masked]
Status:

Two people have recently complained that my messages create line lengths
that are too long, and hard to read. This used to be a problem with GroupWise,
and I had to manually insert line breaks, but the problem was solved some time ago
at our gateway.

So either it is back, or something else is going on.

So far, the two people that have complained are using NetScape Communicator, and
both are outside the US, which makes me wonder whether there is a NetScape (export-version) problem.

So let me test this. This paragraph is written as one long line, and should be automatically line wrapped and broken. If it is not, and if you are using anything other than Communicator please let me know. (I would suggest that you copy the list, so that umpty-thousand people don't send me mail for the same problem.)

Likewise, if someone is using Netscape Communicator 3.01 in a non-US version who is NOT having any particular difficulty reading this paragraph, please let me know as well.

I'd like to fix it, but don't know what's wrong.

Bob

Approved-By:  "Phillip H. Griffin" <[email-masked]>
Date:         Wed, 28 Jan 1998 18:46:11 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Phillip H. Griffin" <[email-masked]>
Organization: Griffin Consulting
Subject:      Re: [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

Santoni Adriano wrote:
>
> Anybody wants to kindly point me to some site(s) where the exact and
> clear description of the character sets PrintableString, VisibleString,
> TeletexString (or T61String), IA5String, BMPString...and such, can be
> found?
> TIA to all good guys,
>   Adriano

Hi Santoni,

The ASN.1 standards define the types that you refer to above. In
particular, you should look under "Restricted Character String
Types" in X.680. Note tha PrintableString is a subset of the
visible US ASCII characters, or simply a subset of ASN.1 type
VisibleString. BMPString is used for national language support,
and contains 2-byte Unicode characters. A new ASN.1 type named
UTF8String contains all of BMPString and more. It allows the
US ASCII characters to be transmitted as a single byte, and also
supports 2 and 3 byte characters.

These types, generally, are based on the ISO 646:1991, and
ISO/IEC 10646-1, for ASN.1 1994, and an older version of
ISO 646 (1971?) for ASN.1 1990 (X.208), which is commonly
used in IETF works.

For more detailed information, I suggest that you consult X.680.
IESG/IETF expertise can be obtained from Harald Alvestrand, at
[email-masked], who is very much involved in
standards activities related to character sets.

Phil
--
Phillip H. Griffin         Griffin Consulting
[email-masked]        ASN.1-SET-Java-Security
919.828.7114               1625 Glenwood Avenue
919.832.7008 [mail]        Raleigh, North Carolina 27608 USA
------------------------------------------------------------
          Visit  http://www.fivepointsfestival.com
------------------------------------------------------------

Approved-By: [email-masked]
Date:         Wed, 28 Jan 1998 19:09:21 +0200
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mark Shuttleworth <[email-masked]>
Subject:      Re: [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

> Anybody wants to kindly point me to some site(s) where the exact and
> clear description of the character sets PrintableString, VisibleString,
> TeletexString (or T61String), IA5String, BMPString...and such, can be
> found?

ISO water torture, as Peter Gutmann puts it ;)

Best place I've found is his X.509 Style Guide, which you can get to from
his collection of security links:

  http://www.cs.auckland.ac.nz/~pgut001/links.html

Now bear in mind that asking for an "exact and clear" description of
something as painful as your chosen topic of enquiry is like asking for
enjoyable dentistry.  But at least it's an interesting read.

--
Mark Shuttleworth
Thawte Consulting

Approved-By:  Rowland Smith <[email-masked]>
Date:         Wed, 28 Jan 1998 12:15:20 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Rowland Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

At 11:51 AM 1/28/98 -0500, Scott Guthery wrote:
>BER - Basic Encoding Rules
>DER - Distinguished Encoding Rules
>CER - Canonical Encoding Rules
>PER - Packed Encoding Rules
>
>All ways of represending ASN.1 structures as bytes.
>
>Check out Burton Kaliski's note "A Layman's Guide to a Subset
>of ASN.1, BER and DER" for a good introduction.

The ITU-T standards document X.690 contains the complete specifications for
the Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), and X.691 contains the complete
specification for the Packed Encoding Rules (PER).

Later,

>Cheers, Scott
>
>-----Original Message-----
>From: Gina DePlanche <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Wednesday, January 28, 1998 11:41 AM
>Subject: [IETF-PKIX] DER vs BER
>
>
>>        Hi!
>>
>>        I've seen the acronyms BER and DER used in the PKIX drafts and
>>rfcs. Could someone tell me if there is a difference between these, and
>>where I could find it?  From what I can see, it looks like RFC1778
>>defined the encoding that should be used for LDAP.
>>
>>        Thanks,
>>        Gina
>>
>>
>>--
>>Gina M. DePlanche               |       OpenROUTE Networks, Inc.
>>[email-masked]               |       A subsidiary of Proteon, Inc.
>>(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
>>Fax: (508) 836-5347             |       01581-1799  MailStop #23
>>
>
>

--------------------------------------------------------------------------
Rowland Smith                                 Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                               Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

Approved-By:  Scott Guthery <[email-masked]>
Date:         Wed, 28 Jan 1998 11:51:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Scott Guthery <[email-masked]>
Subject:      Re: [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

BER - Basic Encoding Rules
DER - Distinguished Encoding Rules
CER - Canonical Encoding Rules
PER - Packed Encoding Rules

All ways of represending ASN.1 structures as bytes.

Check out Burton Kaliski's note "A Layman's Guide to a Subset
of ASN.1, BER and DER" for a good introduction.

Cheers, Scott

-----Original Message-----
From: Gina DePlanche <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, January 28, 1998 11:41 AM
Subject: [IETF-PKIX] DER vs BER

>        Hi!
>
>        I've seen the acronyms BER and DER used in the PKIX drafts and
>rfcs. Could someone tell me if there is a difference between these, and
>where I could find it?  From what I can see, it looks like RFC1778
>defined the encoding that should be used for LDAP.
>
>        Thanks,
>        Gina
>
>
>--
>Gina M. DePlanche               |       OpenROUTE Networks, Inc.
>[email-masked]               |       A subsidiary of Proteon, Inc.
>(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
>Fax: (508) 836-5347             |       01581-1799  MailStop #23
>

Approved-By:  Tolga Acar <[email-masked]>
Date:         Wed, 28 Jan 1998 09:44:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tolga Acar <[email-masked]>
Subject:      Re: [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

The BER and DER are not the same thing. You can find a good explanation of them in  "A Layman's Guide to a Subset of ASN.1, BER, and DER" by RSA Labs, (Burt Kaliski). That doc. can be downloaded from the RSA DSI's www page.

-- Tolga

Approved-By: [email-masked]
Date:         Wed, 28 Jan 1998 06:18:18 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] DER vs BER
To: [email-masked]
Status:

        Hi!

        I've seen the acronyms BER and DER used in the PKIX drafts and
rfcs. Could someone tell me if there is a difference between these, and
where I could find it?  From what I can see, it looks like RFC1778
defined the encoding that should be used for LDAP.

        Thanks,
        Gina

--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Approved-By:  Santoni Adriano <[email-masked]>
Date:         Wed, 28 Jan 1998 17:17:49 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] Character sets definitions/descriptions: where online?
To: [email-masked]
Status:

Anybody wants to kindly point me to some site(s) where the exact and
clear description of the character sets PrintableString, VisibleString,
TeletexString (or T61String), IA5String, BMPString...and such, can be
found?
TIA to all good guys,
  Adriano

Approved-By: [email-masked]
Date:         Wed, 28 Jan 1998 09:56:57 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

Charles, you're pointing out an area where the X.509 group has already
agreed that text clarifying exactly the points you raise is required in
the base standard. The ASN.1 is fine, but there is no accompanying text.
Defect Report DR185 is on this specific topic. It was discussed at the
July meeting of X.509 in Helsinki and the resolution of the defect is
that clarifying text will be added to the base standard. The X.509
meeting occurs in Phoenix tomorrow and there is a Draft Technical
Corrigendum that after tomorrow's meeting, should be issued for ballot.
I'll make sure that the  text of that DTC is passed to the PKIX group so
that comments on the specific text can be provided.
------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  January 26, 1998 5:31 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross Certification - Terminology
>
><<File: smime.p7s>>
>
>-----Original Message-----
>From: David P. Kemp <[email-masked]>
>To: [email-masked] <[email-masked]>
>Date: Tuesday, 27 January 1998 1:15
>Subject: Re: [IETF-PKIX] Cross Certification - Terminology
>
>
>:> From: Charles Moore <[email-masked]>
>:>
>:> If we must, I would suggest the following:
>:>
>:> Cross-Certificates
>:> CAs may cross-certify each other, that is each issue the other a
>certificate
>:> and combine the two certificates in a single directory attribute called a
>:> crossCertificatePair. This crossCertificatePair attribute, supports
>chains
>:> of trust that run in both directions and implement trust models that
>begin
>:> at the CA which issued the users certificate, rather than trust models
>where
>:> trust originates from a common "root". A crossCertificatePair, includes
>two
>:> certificates, forward and reverse.  The subject of  the forward
>certificate
>:> is the issuer of the reverse certificate and vice-versa.
>:
>:
>:Inter-domain certification is not necessarily bilateral, i.e. it does
>:not always result in a crossCertificatePair.
>
>The relevant definition is
>CertificatePair    ::= SEQUENCE {
> forward   [0] Certificate OPTIONAL,
> reverse   [1] Certificate OPTIONAL}
>
>I believe that there are optionals  here, the specification does not force a
>particular solution.
>
>snip.
>
>
>
>

Approved-By:  [email-masked]
Date:         Tue, 27 Jan 1998 23:23:04 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Patrick M. Mulrooney" <[email-masked]>
Subject:      [IETF-PKIX] ADMIN: Posting update - Please read
To: [email-masked]
Status:

Folks,

In order to defeat the "spammers" posting junk mail to the IETF-PKIX
mailing list, the list has been changed such that only those subscribed
to the list can post to the list.

In order to accommodate those who may post to the IETF-PKIX list from an
e-mail address (or addresses) other than that on which they are
subscribed to the list, an IETF-PKIX-SUBMIT list has been also created.
IETF-PKIX list subscribers in this category should also register to the
IETF-PKIX-SUBMIT list. To do this send the command
"subscribe IETF-PKIX-SUBMIT <full name>" to [email-masked]
This command should be repeated for each alternate posting From: address.

You may then post to the IETF-PKIX list from either the address registered
to the IETF-PKIX list, or from any of the addresses registered to the
IETF-PKIX-SUBMIT list.

You cannot post to the  IETF-PKIX-SUBMIT list and all messages posted to
IETF-PKIX-SUBMIT will be rejected.

In all cases, you will receive e-mail from the IETF-PKIX list only at the
address registered to the IETF-PKIX list. If this is also the only address
from which you post to the IETF-PKIX list, you do not need to register to
the IETF-PKIX-SUBMIT list.

Any e-mail posted to the IETF-PKIX list from an address not registered on
either list will be forwarded to the IETF-PKIX list owners. They will decide
how to dispose of it based on the content.

--
Postmaster
Tandem Computers

Date:         Tue, 27 Jan 1998 19:11:02 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Pawluk, Jean" <[email-masked]>
Subject:      [IETF-PKIX] Mailing List  Cleanup - Please read...
To: [email-masked]
Status:

Please

If anyone is sending mail to the following addresses would you please
remove
them from your e-mail address list(s) . Some of the people have new
addresses and have been deleted from the IETF-PKIX list for quite a
while.

The following are not on the IETF-PKIX mailing list and we cannot trace
who is sending them. They are no longer valid and so they are being
rejected by the mailservers and we are bombarded with error messagesas
the list owners:

 [email-masked]
 [email-masked]
 [email-masked]
 nsyfrig @wppost.depaul.edu
 [email-masked]
 [email-masked]
 [email-masked]
 [email-masked]

Thanks
   Jeanne

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the
IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX list.

> delete IETF-PKIX [email-masked]
[email-masked] is not subscribed to the IETF-PKIX
list.

Date:         Tue, 27 Jan 1998 19:57:21 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "maruyama@IBMUS"@US.IBM.COM
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

                   Status Distribution January 27, 1998 17:32:32

The message regarding "Re: [IETF-PKIX] cross-certification" sent on January 27,
1998 17:32:32 was sent by

Status Recipient
          Type                To
          Native Name         [email-masked]
          Foreign Native Name [email-masked]\n\n\nINTERNET

Recipients

Status Reporters
          Type                From
          Name Domain         NOTES
          Native Name         maruyama@IBMUS
          Foreign Native Name maruyama\nIBMUS\n\n
          Last Name           maruyama

Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Recipient user name maruyama@IBMUS not unique.  Several matches
found in Name & Address Book.

Date:         Tue, 27 Jan 1998 11:06:01 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

>I see two simple alternatives, and feel we should adopt one of them
>before these documents are published as proposed standards:
>
>(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
>X.509-defined term "CA-certificate"; or
>
>(b) Explicitly define the term "cross-certificate" to be the same as the
>term "CA-certificate" (as defined in X.509).

I prefer (a).

Russ

Date:         Tue, 27 Jan 1998 15:58:55 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Guess if I'm going to send private notes, I ought to check the addressee list!  Oh, well, it isn' the first time, and probably won't be the last.

>>> Bob Jueneman <[email-masked]> 01/27 3:30 PM >>>
Private note, to avoid ambarrassing myself too much.

...

Date:         Tue, 27 Jan 1998 17:57:03 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

> Note that these OIDs refer to a truncated HMAC where only the first
> 96 bits of the outer hash output are used - this truncation is described
> as a security advantage (it wasn't done solely to cram the MAC into
> the IPSEC packets).

The security advantage is small but significant. First note that the
Bithday attack collision mode is not relevant since all that matters
is the propability of collision between a specific password and a trial,
collisions between the trials are irrelevant, hence 96 bits is more
than enough for security.

Omitting part of the MAC value means that it is not possible to crack
a single MAC by exhaustive search, there is simply not enough
information present. Given a single MAC the best the attacker can
do is to derrive a large set of possible candidates (2^44 in this case).
Narrowing the choice requires a further exhastive attack of these
candidates against another MAC value.

Oh well back to work...

        Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 39 (????/----) (0001E322)

Date:         Tue, 27 Jan 1998 15:42:49 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

I wasn't necessarily rejecting your argument, I just hadn't thought through the issues enough to be convinced yet.  Your example at least provides a concrete business scenario to consider.

You might consider expanding/expounding on this a little more, to address three possible applications -- (1) recognition and acceptance of company B by company A prior to sending an encrypted message, (2) recognition and acceptance (automatically, lights out) of company B's signature (or one of their employee's), and (3) acceptance of company B's certs, allowing B's employee's free access to A's corporate network.

Do you really see a company's CA getting involved in NDA's and similar business arrangements? Still seems like a stretch, to me.

Bob>
>
>
>>>> Carlisle Adams <[email-masked]> 01/27 2:55 PM >>>
>Hi Bob,
>
>>----------
>>From:  Bob Jueneman[SMTP:[email-masked]]
>>Sent:  Tuesday, January 27, 1998 2:55 PM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] cross-certification
>>
>>3.  I'm not sure that I completely buy Carlisle's argument about need,
>>likelyhood, or even the desirability of one CA requesting a cross-certificate
>>from another CA, as it still requires out-of-band validation of the
>>correctness or the attributes and proof-of-possession of the private key,
>
>I'm a bit surprised at this comment.  Think about this kind of
>cross-certification as analogous to the establishment of a
>non-disclosure agreement (NDA).  Two companies are interested in sharing
>confidential information between specific individuals about specific
>topics.  The process typically begins with one company approaching the
>other and saying, "I'd like to do business with you.  Would you mind if
>we both sign an NDA before we start?"  Once the NDA is in place,
>information can begin to flow.
>
>Here, the cross-certification is similar to (or perhaps, in the new
>world of PKIs, an important part of) the NDA process.  In such a model
>it is entirely natural that a CA in one company would send a
>cross-certification request to, and receive a cross-certification
>response from, a CA in the other company (in fact, the certification
>would probably be mutual).  Yes, they would do the out-of-band exchange;
>yes, they would validate correctness of attributes; yes they would
>verify proof-of-possession.  This would be part of normal business
>practice.
>
>Your preferred model (in which issuers create cross-certificates without
>any involvement from the subjects) is appropriate for some environments
>and must, of course, be accommodated.  However, the model above, it
>seems to me, is appropriate (or even necessary) for other environments.
>I don't think it will be as rare or esoteric as you seem to imply...
>
>>but if the process which works for subordinate CAs also works for
>>cross-certificates I am not opposed to it being included in the certificate
>>management protocols.
>
>Great.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------

Date:         Tue, 27 Jan 1998 15:25:20 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

Right you are. Chalk it up to a brain hiccup. :-)  Somehow I was thinking that the issuer/serial pointed to the CA's certificate, whereas obviously it points to the subject's certificate.

So assuming that IBM in the previous example has (and discloses) two certificates, one from Canada and one from Singapore, and both have the same public key, then it is indeterminate as to which domain E2 and E3 belong to. If they publish a chain of certificate they could go either way. or conceivably include the bifurcated links up to two different TLCAs.

On the other hand, although it is a bit messy, if two different keys are involved (perhaps diferentiated by an issuerKeyID for convenience), then barring another hiccup I believe the domains are determinate.

In either case, I believe that the two domain path validation logic I described still works.  Do you see anything else wrong?

Bob

>> From: "Bob Jueneman" <[email-masked]>
>>
>> Although two certificates exist for IBM, and therefore there might be
>> some ambiguity, there is no ambiguity at all as to which domain E2 and
>> E3 belong to, as that is determined by the issuer and serial number.
>> Since that points to one and only one certificate, and since that
>> certificate in turn has an issuer and serial number, which domain E2
>> and E3 belong to is crystal clear -- Canada.
>
>Nope.
>
>The issuer/serialNumber can uniquely identify a particular cert belonging
>to (say) E2, but it does not uniquely identify either the issuer's (IBM's)
>cert or E2's domain.
>
>E2 belongs to whatever domain he chooses.  If E2 has a cert issued by
>IBM, and IBM has two certs (issued by Singapore and Canada) both of
>which are available to E2 and which have the same subject name and
>public key, then E2 can configure his S/MIME user agent to 1) generate
>cert paths starting at either root when sending messages, and 2) trust
>any number of roots (Canada, Singapore, VeriSign, Entrust, GTE, Thawte,
>etc) when validating received messages.
>
>E3 can make a similar choice of domain membership, and it does not have
>to be the same as E2's.   There may be external administrative restrictions
>on how E2 and E3 configure their domain membership, but nothing in PKIX
>forces them to belong to, say, Canada.
>
>
>> Thanks for all the fish, guys.  This has been a fun discussion.
>
>Likewise.

Date:         Tue, 27 Jan 1998 15:30:21 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Private note, to avoid ambarrassing myself too much.

Carlisle, it serves me right for jumping into this without having read the documents in detail.  But is the use of CertificatePair, and in general the directory operations you are discussing, part of the CMP specification?

I wasn't aware that the PKIX group had yet gotten around to specing directory entries, schemas, etc.

In any case I don't believe that it is necessarily wise to assume that a relying party will be able to access a directory outside of her own local domain.

Am I stepping on it here?

Bob

>>> Carlisle Adams <[email-masked]> 01/27 2:34 PM >>>
Hi Bob,

One comment...

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 2:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>If instead of looking up the issuer name in the directory, we looked up the
>subject name in the subjexct's own directory, and if ALL of the issuers of
>all of the certificates for that subject were to deposit their certificates
>in that directory, perhaps keyed somehow by the domain or TLCA of the various
>issuer hierarchies, then  instead of following the subject/issuer chain in
>the certificate, we could follow the various chains in the _directory_,
>instead.
>
>But that would require that the subject of all certificates be responsible
>for publishing their own certificates, even if they had no relationship to
>the issuer of the certificate.
>
>I explicitly DON'T want to assume that level of cooperation, because I want
>my local IT group to be able to cross-certify some public CA's root key (or
>for that matter, some subordinate CA's key, or even an end-user's key, if
>necessary for efficiency's sake) without ANY involvement by that CA (or
>end-user) at all.

Note that a cross-certificate can be published by the subject in the
"forward" parameter of a CertificatePair in the subject's directory
entry AND / OR can be published by the issuer in the "reverse" parameter
of a CertificatePair in the issuer's directory entry.  It is not
actually necessary to force issuers to be the publishers of
cross-certificates in their own entries, or to force subjects to be the
publishers of cross-certificates in their own entries.  Either scenario
can be used and, in fact, publishing in BOTH places (when possible and
appropriate) will allow greater flexibility in the path construction /
validation logic.

In other words, the path processing logic should not make an assumption
about where cross-certificates will be found (i.e., only subject's entry
or only issuer's entry).  It should be able to look in both places
before giving up.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 16:55:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Bob,

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 2:55 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>3.  I'm not sure that I completely buy Carlisle's argument about need,
>likelyhood, or even the desirability of one CA requesting a cross-certificate
>from another CA, as it still requires out-of-band validation of the
>correctness or the attributes and proof-of-possession of the private key,

I'm a bit surprised at this comment.  Think about this kind of
cross-certification as analogous to the establishment of a
non-disclosure agreement (NDA).  Two companies are interested in sharing
confidential information between specific individuals about specific
topics.  The process typically begins with one company approaching the
other and saying, "I'd like to do business with you.  Would you mind if
we both sign an NDA before we start?"  Once the NDA is in place,
information can begin to flow.

Here, the cross-certification is similar to (or perhaps, in the new
world of PKIs, an important part of) the NDA process.  In such a model
it is entirely natural that a CA in one company would send a
cross-certification request to, and receive a cross-certification
response from, a CA in the other company (in fact, the certification
would probably be mutual).  Yes, they would do the out-of-band exchange;
yes, they would validate correctness of attributes; yes they would
verify proof-of-possession.  This would be part of normal business
practice.

Your preferred model (in which issuers create cross-certificates without
any involvement from the subjects) is appropriate for some environments
and must, of course, be accommodated.  However, the model above, it
seems to me, is appropriate (or even necessary) for other environments.
I don't think it will be as rare or esoteric as you seem to imply...

>but if the process which works for subordinate CAs also works for
>cross-certificates I am not opposed to it being included in the certificate
>management protocols.

Great.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 10:14:04 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Eric Hughes <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

<x-rich>>>>>

<excerpt>Certainly I was unaware of the Novell patent in this area (CRL
processing) until I heard about it from Phillip Halem-Baker, despite the
fact that two of the inventors sit not more than 100 feet from me -- the
patent originated prior to my joining Novell.

</excerpt><<<<<<<<

Do you have a patent number for this?

TIA.

Eric
</x-rich>

Date:         Tue, 27 Jan 1998 16:43:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

> From: "Bob Jueneman" <[email-masked]>
>
> Although two certificates exist for IBM, and therefore there might be
> some ambiguity, there is no ambiguity at all as to which domain E2 and
> E3 belong to, as that is determined by the issuer and serial number.
> Since that points to one and only one certificate, and since that
> certificate in turn has an issuer and serial number, which domain E2
> and E3 belong to is crystal clear -- Canada.

Nope.

The issuer/serialNumber can uniquely identify a particular cert belonging
to (say) E2, but it does not uniquely identify either the issuer's (IBM's)
cert or E2's domain.

E2 belongs to whatever domain he chooses.  If E2 has a cert issued by
IBM, and IBM has two certs (issued by Singapore and Canada) both of
which are available to E2 and which have the same subject name and
public key, then E2 can configure his S/MIME user agent to 1) generate
cert paths starting at either root when sending messages, and 2) trust
any number of roots (Canada, Singapore, VeriSign, Entrust, GTE, Thawte,
etc) when validating received messages.

E3 can make a similar choice of domain membership, and it does not have
to be the same as E2's.   There may be external administrative restrictions
on how E2 and E3 configure their domain membership, but nothing in PKIX
forces them to belong to, say, Canada.

> Thanks for all the fish, guys.  This has been a fun discussion.

Likewise.

Date:         Tue, 27 Jan 1998 16:34:52 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Bob,

One comment...

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 2:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>If instead of looking up the issuer name in the directory, we looked up the
>subject name in the subjexct's own directory, and if ALL of the issuers of
>all of the certificates for that subject were to deposit their certificates
>in that directory, perhaps keyed somehow by the domain or TLCA of the various
>issuer hierarchies, then  instead of following the subject/issuer chain in
>the certificate, we could follow the various chains in the _directory_,
>instead.
>
>But that would require that the subject of all certificates be responsible
>for publishing their own certificates, even if they had no relationship to
>the issuer of the certificate.
>
>I explicitly DON'T want to assume that level of cooperation, because I want
>my local IT group to be able to cross-certify some public CA's root key (or
>for that matter, some subordinate CA's key, or even an end-user's key, if
>necessary for efficiency's sake) without ANY involvement by that CA (or
>end-user) at all.

Note that a cross-certificate can be published by the subject in the
"forward" parameter of a CertificatePair in the subject's directory
entry AND / OR can be published by the issuer in the "reverse" parameter
of a CertificatePair in the issuer's directory entry.  It is not
actually necessary to force issuers to be the publishers of
cross-certificates in their own entries, or to force subjects to be the
publishers of cross-certificates in their own entries.  Either scenario
can be used and, in fact, publishing in BOTH places (when possible and
appropriate) will allow greater flexibility in the path construction /
validation logic.

In other words, the path processing logic should not make an assumption
about where cross-certificates will be found (i.e., only subject's entry
or only issuer's entry).  It should be able to look in both places
before giving up.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 13:31:40 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

>
>The IANA has registered OIDs for HMAC mechanisms as used by IPSEC:
>
>  ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers
>
>iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
>isakmpOakley(1) HMAC-md5(1)  [1.3.6.1.5.5.8.1.1]
>iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
>isakmpOakley(1) HMAC-SHA(2)  [1.3.6.1.5.5.8.1.2]
>
>The reference in the IANA document [Thayer] is missing, but it refers
>to the IPSEC document roadmap, which in turn references "The Use of
>HMAC-SHA-1-96 within ESP and AH",
>
>  ftp://ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt
>
>which in turn references RFC 2104 "HMAC: Keyed Hashing for Message
>Authentication", the actual algorithm description.
>
>Note that these OIDs refer to a truncated HMAC where only the first
>96 bits of the outer hash output are used - this truncation is described
>as a security advantage (it wasn't done solely to cram the MAC into
>the IPSEC packets).

As usual when adopting a standard intended for one purpose for another completely different one, you need to be careful to ensure that the standards are meeting the same needs.

Although I haven't followed the use of HMAC in IPSEC, I would have serious reservations about the use of ANY hash algorithm that is only 96 bits long, unless I had wralked though all of the possible attack scenarios very carefully.

The problem, of course, is that a Birthday Problem attack on a 96 bit hash only requires on the order of 2^48 calculations to defeat it.  Although there may be a security advantage in doing some truncation (e.g., to protect against attempts to extract the secret salt), 96 bits is far too short for comfort.

If we can't find anything else, we should write up and use a varient of HMAC that is somewhere between 128 and 140 bits long, I believe.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date:         Tue, 27 Jan 1998 15:13:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Bob Jueneman wrote:
>
> It would be interesting to know whether the IETF and particularly the
> IESG share this assumption.

The IESG only reflects the consensus of the IETF as a whole. Time and
time again we have polled the plenary (the best method we have to
gauge the "sense" of the IETF) on issues important to the IETF. We
also have the POISED working group, which defines the standards
process, which also deals with this issue.

Personal opinions of individual IESG members can influence discussions
(we are only human), however on important policy matters we are tasked
to go with the community perspective making use of our best technical
judgment.

It is my experience that the sense of the community is formed in a
large part by how patent holders in this space have behaved in the
past.

Let me propose that we terminate this discussion here. If people feel
one way or the other about IETF intellectual property policies, the
place to raise it is in the POISED working group.

                                -Jeff
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 38 (????/----) (0001E321)

Date:         Tue, 27 Jan 1998 14:48:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

> From: Bob
>
> > From: Carlisle
> >
> >This seems to be two votes in favor of HMAC-SHA-1 and no disagreements
> >so far.  I don't mind specifying this as the mandatory parameter in
> >PasswordBasedMac, but let me repeat Nada's question:
> >
> >>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
> >>anybody have a pointer to some document specifying it?
> >
> >I need this as soon as possible (i.e., within the next day or two).  If
> >an OID doesn't exist, should PKIX define one?
>
> I don't know the OID, but I believe that one was defined for SET, if
> someone has that spec.
>
> Bob

The IANA has registered OIDs for HMAC mechanisms as used by IPSEC:

  ftp://ftp.isi.edu/in-notes/iana/assignments/smi-numbers

iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
isakmpOakley(1) HMAC-md5(1)  [1.3.6.1.5.5.8.1.1]
iso(1) org(3) dod(6) internet(1) security(5) mechanism(5) ipsec(8)
isakmpOakley(1) HMAC-SHA(2)  [1.3.6.1.5.5.8.1.2]

The reference in the IANA document [Thayer] is missing, but it refers
to the IPSEC document roadmap, which in turn references "The Use of
HMAC-SHA-1-96 within ESP and AH",

  ftp://ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-01.txt

which in turn references RFC 2104 "HMAC: Keyed Hashing for Message
Authentication", the actual algorithm description.

Note that these OIDs refer to a truncated HMAC where only the first
96 bits of the outer hash output are used - this truncation is described
as a security advantage (it wasn't done solely to cram the MAC into
the IPSEC packets).

Date:         Tue, 27 Jan 1998 12:55:15 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

Dave, you've made some insightful comments. I'll therefore elaborate on my lengthy> message to
>Al and Hal.
>
>>>> "David P. Kemp" <[email-masked]> 01/27 11:16 AM >>>
>> From: Hal Lockhart <[email-masked]>
>>
>> I grant the wording is hard to follow, but the idea is simple.  Just ask
>> the question" Is the issuer attribute a back pointer?  If yes, its
>> hierarchical, if no, its a cross-cert.
>>
>> Hal
>
>
>I thought it sounded simple too, until I drew the diagram and realized
>that the issuer field in the subordinate CA's certificate didn't solve
>anything - it's always a back pointer to something.
>
>Start with top-level CAs 0 and 1 again, or call them "Canada" and
>"Singapore":
>
>                          CA0 "Canada"
>                            \
>      CA1 "Singapore" ----> CA2 "IBM"
>      /                    /  \
>     E1                   E2   E3
>
>
>The problem is that CA2 has two certificates with the same public key
>and possibly the same subject name (IBM), but with different issuer
>names.  Each Relying Party can choose which of CA0 or CA1 to use as
>a trust anchor when validating E3's cert; for each choice there is an
>available cert with CA2 as the subject and a valid back-pointing
>issuer field.

The key verb in that paragraph is the "has" in the first sentence.

I agree that somewhere in the universe there exist the two certificates you mention, but I also believe that there is a significant difference in the state of knowledge of the relying parties who are "in" (trust) the Canada domain vs. the Singapore domain.

If you buy my argument that unilateral cross-certification _may_ at least, be completely transparent and even oblivious to the CA and end-users within the domain that is being cross-certified, then to use your example, IBM and the users E2 and E3 may be completely ignorant of the Singapore domain, or any corss-certification between Singapore and Canada.  In particular, if user E2 sends an S/MIME message to the PKIX list and includes E2's complete certificate chain, then that chain will contain certificates for E2, IBM, and Canada, period.

If E3 is the relying party, there is obviously no problem, for E3 has a common root in Canada (and also a common subordinate CA, IBM, for that matter).

But if E1 is the relying party, things are different.  E1 knows about Singapore, but she doesn't know anything about Canada. When she tries to find and validate E2's certificate in the Singapoore hierarchy, she doesn't find it, so she has to climb _E2's_ chain, leading to IBM.  Then, using my suggested algorithm she finds that Singapore has cross-certified IBM, and so the validation is successful.
>
>You have to invoke politics to determine which domain IBM belongs to,
>and therefore which cert is the cross-cert.  There doesn't seem to be
>any way around that.

>One possible solution is for both Singapore and Candada to agree that
>CA2's real name is "C=CA, O=IBM".  Any cert with CA2 as the subject
>which didn't follow name subordination would be defined as a cross-cert.
>But it doesn't seem useful to go through the process of labelling a
>particular certificate as a cross-cert if there is no difference in
>the path validation procedure as a result of assigning that label.

"Politics" in this case is the simple "eye-of-the-beholder" rule.  Although two certificates exist for IBM, and therefore there might be some ambiguity, there is no ambiguity at all as to which domain E2 and E3 belong to, as that is determined by the issuer and serial number. Since that points to one and only one certificate, and since that certificate in turn has an issuer and serial number, which domain E2 and E3 belong to is crystal clear -- Canada.  It doesn't, and shouldn't, have anything to do with country of origin or other naming conventions. (Entrust might have been a better example than IBM -- clearly Entrust might have a branch office in Singapore that might nonetheless be a member of the Canadian hierarchy.)
>
>I'm starting to believe that if the term "cross-certification" is used
>to mean anything more limited and specific than "CA-certification",
>then the description of the difference belongs *only* in Part 4.
>
>For purposes of Part 1 and Part 3, they are synonymous unless someone
>can come up with a concrete example where the difference has an
>observable effect on 1) certificate contents, 2) path validation rules,
>or 3) management protocol operations.  This is, in fact, a Good Thing.
>It means that X.509/PKIX is general enough to support the
>political/operational act of "cross-certification" without requiring
>any special-purpose syntax or protocol operations.

You may have a point here.

I believe that:

1.  There is no observable difference in the certificate contents per se (one certificate at a time, at least), so X.509 would not seem to be impacted.  That's obviously good.

2.  There is a considerable difference in the relying party's path validation rules. Those
rules will presumably need to be rewritten to handle the two independent hierarchy/directory/domain case as I previously described, assuming others accept this approach.

3.  I'm not sure that I completely buy Carlisle's argument about need, likelyhood, or even the desirability of one CA requesting a cross-certificate from another CA, as it still requires out-of-band validation of the correctness or the attributes and proof-of-possession of the private key, but if the process which works for subordinate CAs also works for cross-certificates I am not opposed to it being included in the certificate management protocols.

Thanks for all the fish, guys.  This has been a fun discussion.

Bob

Date:         Tue, 27 Jan 1998 12:16:36 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

I think we are getting somewhere, but there seem to be three separate problems to be addressed:

1.  Proper understanding trust relationships being discussed,

2.  Representing that trust relatiionship in some meaningful, parseable, and hopefully concise English definition, and

3.  Figuring out what to do about the nasty problems of certificate retrieval and public key validation in a mesh network.

>Intellectually, I believe that there is a difference between a
>"CA-certificate" issued to a CA in the same hierarchy, and a
>"cross-certificate" issued to a CA (maybe a Root CA/TopLevelCA/whatever)
>in another hierarchy.

Quite so. and the difference, of course, is who is doing the issuing, and who the relying parties are.

My primary interest (AKA bias, AKA blind spot?) in the use of cross-certificates is to support a model which allows a user or her IT organization to simply represent which independent hierarchical domains of trust they choose to give credence to.  So my primary mental model is a bottom-up, followed by multiple top-down models, controlled and modulated as required by policyOID and/or other validation path constraints.

I would be quite wary of ANY certification authority (other than my own) which cross-certifies some other CA hierarchy, unless they can assure me that they have applied the same policy mapping and other CPS constraints to that other hierarchy, and can assure me that they are equivalent.

I have no problem if the Government of Canada wishes to instruct those users over which it has either moral or legal authority, e.g., government employees within the Ministry of Defence, that they should trust the certificates issued by the Government of Singapore as effectively the equivalent of the certificates issued by the Government of Canada.  It is certainly their right to do so.

However, it would be quite another thing to assert that if I decide to trust the certificate issued by the Government of Canada, I must or at least should trust the certificate issued by the Government of Singapore.

I don't have anything against Singapore, particularly, but they obviously have a much different legal system than what I am used to, and they are sufficiently far away both in distance in culture that I would not even think of extending to them the same degree of trust I would give Canada, a country which I have visited multiple times, and whose citizens, culture, and legal system I am quite familiar with.  This is the obvious problem with transitive trust, writ large when it comes to cross-certification.
>
>For example:  at the RSA Conference two weeks ago, John Ryan of Entrust
>announced that the Government of Canada (which uses Entrust) and the
>Government of Singapore (which also uses Entrust) will soon
>cross-certify.  It seems to me that that's a valid use of the term - it
>strikes me that:
>
>        Scenario A:  the Top-Level CA of the Government of Canada issues a
>CA-certificate to a subordinate CA for Revenue Canada, or some other
>government department
>
>        Scenario B:  the Top-Level CA of the Government of Canada issues a
>cross-certificate to the Top-Level CA of the Government of Singapore,
>permitting validation of communications among some end-users supported
>by the two governments under certain conditions
>
>are two different things, that ought to be recognized as such.  While it
>may or may not be directly reflected in the certificate, the degree of
>control exerted by the issuing CA over the certificate's recipient is
>very different, and relying parties should be able to take this into
>account.
>
Agreed.
>
>So, how do we define this?  Let's start with Denis' suggestion:
>
>>Cross-certificate: A CA-certificate issued by one CA for another CA that
>>is either in a different naming hierarchy and/or in a different
>>organizational structure.
>
>I think this is okay, but I'd rather see "organizational structure"
>replaced with "domain", which I think is a much more flexible term.

Naming hierarchy is obviously much too narrow.  If I decide that I like Verisign's policies relating to their Class 3 certificates used for web servers and code signing, I may decide to trust all of their Class 3 certificate, regardless of the lack of any name constraints or other relationship.

Likewise, organizational structure doesn't work, for there isn't any organization in common.  The issue is more one of policy, and perhaps contractual agreements.  "Domain" comes closer, but tends to imply a more rigid degree of authoritative control, a la DMS, that is probably warranted in the commercial environment.  So far I haven't come up with a one-word English description. [Maybe we should adopt, and if necessary bastardize, the German word "bund," loosely meaning "association," but without the legal meaning that association might have in English. But please, all you German linguists, don't jump all over me. It's probably a bad idea.]
]>
>Bob Jueneman wrote:
>
>1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
>subject community or hierarchy) if the certificate containing the
>distinguished name of the entity listed in the subject attribute was
>issued by the same CA (distinguished name) whose distinguished name
>appears in the issuer attribute in the same certificate.
>
>I'm not sure I fully understand this (I went so far as to try
>diagramming the sentence), but it seems to only allow two-level
>hierarchies; e.g., a Top-Level CA and then one subordinate CA.  It seems
>to fall apart if you try to build (Top-Level CA, CA, subordinate CA)
>structures.  Bob:  is there anything you can do to clarify this?

Sorry, Al. I wrote that one about three times, and had some trouble understanding it myself.  But I was not trying to differentiate between a CA and a subordinate CA, but only between subordinate certificates vs. TLCA and cross-certificates.  So from my point of view your structure is wrong -- it should be TLCA, subordinate CA, subordinate CA..

What I was trying to do in economical language was to define what all of us would understand is meant by a certificate being in a given hierarchy, decended from a TLCA.  The essense of the hierarchy is the chaining relationship between the name of issuer of a certificate and the issuer name that is recorded in the certificate itself.  They are obviously the same in the case of a certificate issued  by a higher level CA to a subordinate CA in the same hierarchy, whereas they are not the same in the case of a cross-certificate. This becomes clearer if you think about starting at the bottom with an end-user certificate and climbing the tree for that chain.

In a single hierarchy, there is a one to many relationship between issuers and subjects, but for any given subject, there is only one issuer.  Given a certificate for some subordinate entity (CA or end-user), I should be able to extract the issuer name from that certificate, look up that distinguished name in a directory or other repository and thereby find the CA's own certificate, issued by the next higher level CA.  And applying that procedure recursively, I should be able to climb the tree from the bottom up, until I come to a self-signed certificate which is issued by the TLCA.

Presumably this is not the case for a cross-certified certificate.

It occurs to me that this may be a major difference between what I am assuming and what I understand (perhaps incorrectly) that some others may be doing.

If instead of looking up the issuer name in the directory, we looked up the subject name in the subjexct's own directory, and if ALL of the issuers of all of the certificates for that subject were to deposit their certificates in that directory, perhaps keyed somehow by the domain or TLCA of the various issuer hierarchies, then  instead of following the subject/issuer chain in the certificate, we could follow the various chains in the _directory_, instead.

But that would require that the subject of all certificates be responsible for publishing their own certificates, even if they had no relationship to the issuer of the certificate.

I explicitly DON'T want to assume that level of cooperation, because I want my local IT group to be able to cross-certify some public CA's root key (or for that matter, some subordinate CA's key, or even an end-user's key, if necessary for efficiency's sake) without ANY involvement by that CA (or end-user) at all.

On the other hand, I AM willing to assume that I operate my own local (or virtual) and perhaps TRUSTED (by me) directory, and that all of the certificates created by my own TLCA are deposited in that directory.

Within MY hierarchy, anchored at the top by a TLCA I trust, and within my directory, all of the certificates appear to be perfectly normal. The subject to issuer names chain correctly, and even the issuer names plus serial numbers are correct.

And within the single hierarchy of the end-user whose certificate is being validated, the certificates also appear normal, and chain correctly.

The difficulty comes in knowing when to hop off of one chain and onto another, i.e., recognizing that a cross-certificate exists in the absence of the normal issuer plus serial number chaining.

I therefore proposed the following algorithm for validating a certificate across two hierarchies, the relying party's domain and the subject's domain.:

For simplicity, let's assume that the subject has provided an entire chain of certificates along with his digital signature, leading back to his own TLCA, but that I the relyuing party have not directly included that TLCA's key in my cache of trusted root keys.  (If the subject has not provided the entire chain, then it may be necessary to find the various certificates within the subject's hierarchy/directory, or from some other repository, hinted at somehow. But this is a more or less irrelevant detail for the present argument.)

1.  Given the subject's name, I look for a certificate corresponding to that name in my own directory, perhaps aided by a hint such as a hash of the public key. If I find a certificate for that subject name and key, I know that the subject's certificate is valid because I previously put it in my trusted directory, but I can also climb the certificate tree within my own hierarchy/directory and revalidate the chain if I wish. In either case  the validation process has concluded successfully.

2.  If I don't find the subject's name and public key in my hierarchy/directory, I must extract the issuer name from the certificate provided to me. Then, using that issuer name as a subject name, I repeat step (1), first looking in _my_ hierarchy/directory to see if I have already processed a cross-certificate for that CA. If I have, I can stop and the validation is successful; if not, I must continue up the _subject's_ certificate chain.

3. If I encounter a self-signed certificate in the subject's chain of certificates, signifying a TLCA for the subject's hierarchy, and I cannot find a corresponding subject name and key in my own hierarchy/directory, then the validation process has failed for lack of a common or cross-certified root key.

Note that this process does not require that I go all the way up to the subject's TLCA before stopping. I can cross-certify some intermediate CA in the process, if necessary for efficiency, or perhaps because I trust that CA, but not necessarily other CA's higher up in that CA's chain. (I previously described a scenario involving the Utah National Guard, which might be certified by both the State of Utah and the Department of Defense.  As a resident of Utah I might trust the Utah NG, but not the entire DOD chain of CAs.)

It might be worth making another observation, to the effect that the above algorithm does NOT support transitive cross-certification.  I first look in my own hierarchy, and if I don't find a certificate I climb the subject's hierarchy. At no time will I encounter a cross-certificate issued by some intermediate party.  So if my IT organization issues a cross-certificate to the Government of Canada, I would accept all of the CAs and end-users certified by Canada, but I would never encounter a cross-certificate issued by Canada to Singapore. If I encountered an end-user's certificate from Singapore, I would end up checking my hierarchy and the Singapore hierarchy, but I would never encounter the Canadian cross-cert.  I believe that is appropriate behavior, since transitive cross-certification seems altogether too scary.

Hal Lockhardt said:

>However, this now brings us to the engineering problem that somebody tried
>to discuss a week or two back. Namely: how do we find all the certs we
>need?  If the cross cert is required to point to a cert in our chain, we
>are all set, but what if the relationship is more indirect?  Stealing
>David's pictures:
>
>                                          CA0
>                         (2)                \
>                                  CA1 ----> CA2
>                                 /         /   \
>                                E1        E2   E3
>
>Assuming E1 has the CA1 cert, this case is easy, but
>
>                                          CA0
>               (3)                          \
>                       CA1 ----> CA1a ----> CA2
>                       /                   /   \
>                      E1                  E2   E3
>
>This requires a combination of bottom-up and top-down processing.  This is
>further complicated if we have to protect against loops.

I believe that the above algorithm solves this problem, and is loop free in the case of well-formed hierarchies. If either of the two domains does in fact contain a loop, then either standard traverse-marking or counter technicques can be used to terminate processing.

Finally, to respond to Denis point:

>> 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user)
>
>Bob,
>
>If you take a look at part 3,section 3.5, we have "cross-certification:
>An requesting CA provides to a responding CA ..." this means that the
>end-entity CANNOT be an end-user.
>
I would respectfully suggest that it is the quoted definition and/or the protocol that is broken, not the cross-certificate model.

Although perhaps appropriate in the limited context (which I would argue was really addressing subordinate CA certificates, and not cross-certificates), in the general cross-certification case I reject the notion that there is necessarily any requesting/responding relationship between CAs at all.

Therefore I as the cross-certifiying CA am perfectly free to certify any entity's name and public key I choose, whether a CA or an end-user, within my own hierarchy/directory/domain.

Sorry for the length of this  -- comments came in faster than I could type!

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date:         Tue, 27 Jan 1998 14:02:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

>On the other hand, I suspect that 99% of the contributors to this list
>are not patent experts, and in many if not most cases, may have little
>or no knowledge of the patents currently held by their employer.

I don't know that Novell made any concerted effort to get its version
of CRL processing adopted as an IETF standard.

The real problem is when the patent authors are involved, allowing
of course for the problem that a person may no longer work for the
assignee but still be bound by an NDA.

> The world-wide system of patent protection is based on the assumption
>that by providing the creator of an invention the right to make a
>reasonable return on his work for a limited amount of time, the
>public will ultimately benefit from their labors, and hence the
>public good will be enhanced.

That may be the *World* approach to patent law, the US approach is
very different. The term 'intellectual property' tends to be
interpreted in terms of 'rights' with a sort of 'land rush' mentality
in which the first (white) person to stake a claim gets to take
the Indian's land.

Unlike other patent offices the US PTO does not have an outside
review period. as a result it has allowed a number of ludicrous
patent grants, the term 'patently obvious' frequently comming to
mind. It does not even manage to check its own issued patents
for prior art, let alone the current litterature.

The consensus view of patents in the IETF would most likely be
that they are a form of government taxation on invention akin
to a compulsory lottery. Most are forced to participate, to
grab patents so that they can trade them with other people who
have patents they need access to.

This is why I was asking what people intend to do with their
patents, the IESG has a history of playing hardball. Not letting
a standard pass until the patent holders reliquish their rights
being a common one. Have a look at the 'Intelecutal Property'
statements on the IETF home page.

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 37 (????/----) (0001E31F)

Date:         Tue, 27 Jan 1998 13:40:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi,

It seems the indenting didn't show up properly last time, so it might be
hard for others to distinguish what Bob said from what I said.  Let's
try this again...

>----------
>From:  Carlisle Adams
>Sent:  Tuesday, January 27, 1998 12:01 PM
>To:    'Bob Jueneman'
>Subject:       RE: [IETF-PKIX] cross-certification
>
>Hi Bob,
>
>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 5:00 PM
>To:    Carlisle Adams; [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>Carlisle, for the record I continue to have a problem with what appears to be
>the basic premise regarding unilateral cross-certification, i.e., that it
>necessarily needs to be requested by the subject of the certificate at all.
>But perhaps I am not reading the text correctly.
>
>You are reading the text correctly.  But that basic premise is there for a
>very simple reason.  If the subject is not involved in this decision (i.e.,
>if the issuer decides entirely on its own to create a cross-certificate for
>that subject) AND if the issuer is the one responsible for publishing the
>cross-certificate once its created, then there is no need for a protocol.
>There is nothing whatsoever in that exercise that needs to be specified in
>CMP.
>
>What we're trying to cover is the case in which the subject *does* ask for
>the cross-certificate.  In this situation, there needs to be a protocol
>specified (so that the subject knows *how* to ask, and the issuer knows how
>to respond).
>
>If my IT organization decides to bestow corporate trust on some TLCA, and
>does so by means of a unilateral cross-certificate (outside of the TLCA's
>hierarchy), I don't expect the TLCA being so recognized to initiate or even
>participate in the creation of the certificate, either by participation in a
>protocol or through any legal or business arrangements, necesarily.
>
>And for that reason, I'm not sure why it would make sense to depart from the
>general pattern of haivng the CA who issues the certificate be responsible
>for publishing it.  Surely the issuing CA would still be responsbile for
>publishing any6 CRLs, so why be inconsistent?
>
>Again, you and Nada agree here and I'm not hearing opposing views from the
>list.  Therefore, I will relax the constraint that the subject (the
>requester) is the one who publishes.  As it turns out, the better solution is
>already accommodated in the protocol:  if the requester cares who publishes
>(and where), then it should use the PKIPublicationInfo parameter.  I will add
>a note to the effect that if this optional parameter is omitted in the
>request, then the issuer is the one who publishes the resulting certificate.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
>

Date:         Tue, 27 Jan 1998 11:40:15 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

>Hi Bob, Nada,
>
>>----------
>>From:  Bob Jueneman[SMTP:[email-masked]]
>>Sent:  Monday, January 26, 1998 8:44 PM
>>To:    [email-masked]
>>Subject:       Re: [IETF-PKIX] mandatory PasswordBasedMac
>>
>>Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather
>>than triple-DES MAC for password protection.
>>
>>Although the use of triple-DES for password authentication may be approved
>>for export from the US, proving beyond a reasonable doubt that that is all
>>that it is used for may pose substantial difficulties. In addition, the use
>>of triple-DES may also cause significant _import_ restrictions, e.g., into
>>France, Russia, and some other countries.
>>
>>As a general principle, we should not be using an encryption algorithm,
>>especially a symmetric algorithm, when a safer, less controversial algorithm
>>is available and more than adequate for the purpose.
>
>This seems to be two votes in favor of HMAC-SHA-1 and no disagreements
>so far.  I don't mind specifying this as the mandatory parameter in
>PasswordBasedMac, but let me repeat Nada's question:
>
>>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
>>anybody have a pointer to some document specifying it?
>
>I need this as soon as possible (i.e., within the next day or two).  If
>an OID doesn't exist, should PKIX define one?

I don't know the OID, but I believe that one was defined for SET, if someone has that spec.

Bob

Date:         Tue, 27 Jan 1998 11:28:29 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mike Smith <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
Comments: cc: [email-masked], [email-masked], [email-masked]
To: [email-masked]
Status:

Bob (et al) :

My understanding of cross certificates is kind of basic:  If I am a CA and wish to incorporate the certificates issued by  another CA into my trust domain, then  I would execute a contract with that CA then issue a CA-certificate  to that CA.  I would impose some limitation on levels of issuers below the contracted CA and  no trust for CAs above or without contract.  This would bring all of "my" certificate subscribers (including those of the cross-certified CAs) still to me to validate certs for relying on those certs issued by a CA to whom I have issued an issuer cert.  The draw back in this scenario is that I do not have any contractual business relationship with those subscribers of the CA I brought into my "trust" domain, so I assume liability to my reliant party community for the identity and usage of those certs.  Hopefully, my contract with the cross-certified CA indemnifies me sufficiently from their errors (or fraud).

The schemes for "cross-certifying" that some vendors have implemented where a "lateral" cross cert is issued for a CA outside my "hierarchy" of trust (do not end at the same root as mine) are more "scary" when they also bring in all the "lateral" cross-certifications of those CAs as well.  I have a hard time recognizing with whom I need contracts and indemnity with.  IIt may be just the one CA relationship who will indemnify me from all of the errors, omissions and fraud of all of their cross-certified CAs (and their's and so on) that they bring to my domain of trust.

I think that a workable situation might be with correspondent Ca contracts for identity of the other CA's clients just in order to establish a new contract and business realtionship with each individual on whose identity I need to rely.  I can have correspondent CA relationships established and certificate status or CRL checks with those correspondents without automatically bringing in all of their subscribers without establishing those subscriber buisiness relationships.  These correspondnet relationships do not entail merging the domains of trust (or CRLs, ARLs, etc.) and are backed by the correspondent contracts.

I know this is a different model than that of a "Public" CA wishing to enable its subscribers to communicate with other CA's subscribers.  My current focus is on design and implementation of a "Corporate" PKI within an extranet environment over the public nets to do commerce.  With this different focus, my comments may be particular to the corporate, eComemrce model and not the public infrastructure.

In the corporate model, I need business agreements with those I do business with.  If I have a contract with you as a CA, then I need recourse against you for problems caused by "your" customers.  If I need to do business with "your" customers and you do not wish to indemnify me, then I need to establish a relatinship with them myself.

Do you concur?

michael

>>> Bob Jueneman <[email-masked]> 01/26/98 05:11PM >>>
Dave,

>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed. Certificate definitions should certainly not depend on the container used to hold them!

>
>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".
>
>If we could come up with a simple and consensus-agreed definition
>which could be quickly inserted into CMP, that would be ideal.
>Can you write such a definition?  (I can't.)

How's this:

1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate.

2.  A Top-Level Certification Authority certificate is by definition a self-signed certificate, i.e., one in which the issuer and subject distinguished names are identical.  A TLCA normally issues certificates to subordinate CAs and/or end-entities which contain the TLCA's name as the issuer.

3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) which is neither a subordinate  certificate as defined by (1), nor a TLCA certificate as defined by (2).  I.e., the name of the issuing CA in the certificate in question is _not_ the same as that contained in the issuer attribute of any certificates issued to the subject entity by the TLCA in that hierarchy.

Bob

>
>In the meantime, I agree with you that there appears to be a meaningful
>difference between a CA-cert and a cross-cert, even if we can't define
>what it is.  For that reason, I agree that it would be undesirable
>to change "cross-certificate" to "CA-certificate" in PKIX documents.
>Option (a) was better than option (b), but doing nothing is better
>still.

Option (a) would be better than (b), since most of the discussion in the PKIX documents seems to revolve around the issuance of subordinate CA certificate rather than what I would call a true cross-certificate.  But doing nothing would simply prolong the agony.

Bob

>
>Dave Kemp
>
>
>
>> From: Sharon Boeyen <[email-masked]>
>>
>> Cross-certification can certainly occur either uni-laterally or
>> bi-laterally.
>>
>>  If CA A issues a cross cert for CA B, that cross cert can be published
>> :
>> a)  by CA A as a forward cross-certificate in the cross-certificates
>> attribute of CA A's entry;
>> b)  by CA B as a reverse cross-certificate in the cross-certificates
>> attribute of CA B's entry;
>> c)  or both
>> If the cross-certification is bi-lateral the reverse would apply to the
>> cross-certificate issued by CA B for CA A.
>>
>> CA A should control what gets published/or not in its entry and CA B
>> control what gets published/or not in its entry. Nada is correct that in
>> no case should we expect that CA A have write permission to CA B's entry
>> or vice versa.
>>
>> I do expect that some of these directory specific issues will get
>> addressed in the PKIX LDAP schema specification that we agreed to pursue
>> at the December meeting. For instance, we would want to make sure that
>> cross-certificates are placed in the cross-certificates attribute and
>> not the CA-certificate attribute.
>>
>> Another reason to maintain the term cross-certification and not confuse
>> matters further.
>>
>> ------------------
>> Sharon Boeyen
>> Entrust Technologies

Date:         Tue, 27 Jan 1998 13:26:54 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      [IETF-PKIX] FW: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi,

Sorry, I meant for this to go to everyone, not just to Bob.

>----------
>From:  Carlisle Adams
>Sent:  Tuesday, January 27, 1998 12:01 PM
>To:    'Bob Jueneman'
>Subject:       RE: [IETF-PKIX] cross-certification
>
>Hi Bob,
>
>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 5:00 PM
>To:    Carlisle Adams; [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>Carlisle, for the record I continue to have a problem with what appears to be
>the basic premise regarding unilateral cross-certification, i.e., that it
>necessarily needs to be requested by the subject of the certificate at all.
>But perhaps I am not reading the text correctly.
>
>You are reading the text correctly.  But that basic premise is there for a
>very simple reason.  If the subject is not involved in this decision (i.e.,
>if the issuer decides entirely on its own to create a cross-certificate for
>that subject) AND if the issuer is the one responsible for publishing the
>cross-certificate once its created, then there is no need for a protocol.
>There is nothing whatsoever in that exercise that needs to be specified in
>CMP.
>
>What we're trying to cover is the case in which the subject *does* ask for
>the cross-certificate.  In this situation, there needs to be a protocol
>specified (so that the subject knows *how* to ask, and the issuer knows how
>to respond).
>
>If my IT organization decides to bestow corporate trust on some TLCA, and
>does so by means of a unilateral cross-certificate (outside of the TLCA's
>hierarchy), I don't expect the TLCA being so recognized to initiate or even
>participate in the creation of the certificate, either by participation in a
>protocol or through any legal or business arrangements, necesarily.
>
>And for that reason, I'm not sure why it would make sense to depart from the
>general pattern of haivng the CA who issues the certificate be responsible
>for publishing it.  Surely the issuing CA would still be responsbile for
>publishing any6 CRLs, so why be inconsistent?
>
>Again, you and Nada agree here and I'm not hearing opposing views from the
>list.  Therefore, I will relax the constraint that the subject (the
>requester) is the one who publishes.  As it turns out, the better solution is
>already accommodated in the protocol:  if the requester cares who publishes
>(and where), then it should use the PKIPublicationInfo parameter.  I will add
>a note to the effect that if this optional parameter is omitted in the
>request, then the issuer is the one who publishes the resulting certificate.
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
>
>

Date:         Tue, 27 Jan 1998 13:16:04 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

> From: Hal Lockhart <[email-masked]>
>
> I grant the wording is hard to follow, but the idea is simple.  Just ask
> the question" Is the issuer attribute a back pointer?  If yes, its
> hierarchical, if no, its a cross-cert.
>
> Hal

I thought it sounded simple too, until I drew the diagram and realized
that the issuer field in the subordinate CA's certificate didn't solve
anything - it's always a back pointer to something.

Start with top-level CAs 0 and 1 again, or call them "Canada" and
"Singapore":

                          CA0 "Canada"
                            \
      CA1 "Singapore" ----> CA2 "IBM"
      /                    /  \
     E1                   E2   E3

The problem is that CA2 has two certificates with the same public key
and possibly the same subject name (IBM), but with different issuer
names.  Each Relying Party can choose which of CA0 or CA1 to use as
a trust anchor when validating E3's cert; for each choice there is an
available cert with CA2 as the subject and a valid back-pointing
issuer field.

You have to invoke politics to determine which domain IBM belongs to,
and therefore which cert is the cross-cert.  There doesn't seem to be
any way around that.

One possible solution is for both Singapore and Candada to agree that
CA2's real name is "C=CA, O=IBM".  Any cert with CA2 as the subject
which didn't follow name subordination would be defined as a cross-cert.
But it doesn't seem useful to go through the process of labelling a
particular certificate as a cross-cert if there is no difference in
the path validation procedure as a result of assigning that label.

I'm starting to believe that if the term "cross-certification" is used
to mean anything more limited and specific than "CA-certification",
then the description of the difference belongs *only* in Part 4.

For purposes of Part 1 and Part 3, they are synonymous unless someone
can come up with a concrete example where the difference has an
observable effect on 1) certificate contents, 2) path validation rules,
or 3) management protocol operations.  This is, in fact, a Good Thing.
It means that X.509/PKIX is general enough to support the
political/operational act of "cross-certification" without requiring
any special-purpose syntax or protocol operations.

Date:         Tue, 27 Jan 1998 11:45:20 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

Hi Bob, Nada,

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 8:44 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] mandatory PasswordBasedMac
>
>Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather
>than triple-DES MAC for password protection.
>
>Although the use of triple-DES for password authentication may be approved
>for export from the US, proving beyond a reasonable doubt that that is all
>that it is used for may pose substantial difficulties. In addition, the use
>of triple-DES may also cause significant _import_ restrictions, e.g., into
>France, Russia, and some other countries.
>
>As a general principle, we should not be using an encryption algorithm,
>especially a symmetric algorithm, when a safer, less controversial algorithm
>is available and more than adequate for the purpose.

This seems to be two votes in favor of HMAC-SHA-1 and no disagreements
so far.  I don't mind specifying this as the mandatory parameter in
PasswordBasedMac, but let me repeat Nada's question:

>BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
>anybody have a pointer to some document specifying it?

I need this as soon as possible (i.e., within the next day or two).  If
an OID doesn't exist, should PKIX define one?

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 11:27:16 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Al,

>----------
>From:  Arsenault, Al W.[SMTP:[email-masked]]
>Sent:  Tuesday, January 27, 1998 10:29 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>        Scenario A:  the Top-Level CA of the Government of Canada issues a
>CA-certificate to a subordinate CA for Revenue Canada, or some other
>government department
>
>        Scenario B:  the Top-Level CA of the Government of Canada issues a
>cross-certificate to the Top-Level CA of the Government of Singapore,
>permitting validation of communications among some end-users supported
>by the two governments under certain conditions
>
>are two different things, that ought to be recognized as such.  While it
>may or may not be directly reflected in the certificate, the degree of
>control exerted by the issuing CA over the certificate's recipient is
>very different, and relying parties should be able to take this into
>account.

I agree that these seem intuitively to be two different things and that
it would be nice to recognize them as such.  However, as you rightly
point out, the difference may not be directly reflected in the
certificate.  In other words, there may be nothing whatsoever in the
bare syntax of the certificates that allows you to make the distinction
in an automated way.  It seems to me that it might be a somewhat
fruitless exercise to take things that can't be distinguished by the
bits-on-the-wire and try to give them different names.

As odd as it may seem to some, I think that these are both examples of
cross-certification because in each case there are two distinct CAs
involved (and I think that looking at things in terms of "subject
communities" and "relying party communities" makes this clear).

Agreed:  using the term "cross-certificate" for both cases fails to
distinguish between Scenario A and Scenario B.  However, the term
"CA-certificate" fails to distinguish between Scenario A above and a
self-signed certificate.  When reasoning about and implementing path
validation logic, distinguishing the latter seems (to me) to be more
important than distinguishing the former.  Thus, I'd be more inclined to
give the latter different names than to give the former different names.

>So, how do we define this?  Let's start with Denis' suggestion:
>
>>Cross-certificate: A CA-certificate issued by one CA for another CA that
>>is either in a different naming hierarchy and/or in a different
>>organizational structure.
>
>I think this is okay, but I'd rather see "organizational structure"
>replaced with "domain", which I think is a much more flexible term.

I kind of agree, but I fear that it's so much more flexible a term that
for most practical purposes, it's really undefined...  :-)

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 27 Jan 1998 11:14:52 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

At 10:29 AM 1/27/98 -0500, Arsenault, Al W. wrote:

>Bob Jueneman wrote:
>
>>1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
>>subject community or hierarchy) if the certificate containing the
>>distinguished name of the entity listed in the subject attribute was
>>issued by the same CA (distinguished name) whose distinguished name
>>appears in the issuer attribute in the same certificate.
>
>I'm not sure I fully understand this (I went so far as to try
>diagramming the sentence), but it seems to only allow two-level
>hierarchies; e.g., a Top-Level CA and then one subordinate CA.  It seems
>to fall apart if you try to build (Top-Level CA, CA, subordinate CA)
>structures.  Bob:  is there anything you can do to clarify this?

I grant the wording is hard to follow, but the idea is simple.  Just ask
the question" Is the issuer attribute a back pointer?  If yes, its
hierarchical, if no, its a cross-cert.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 27 Jan 1998 10:29:38 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Intellectually, I believe that there is a difference between a
"CA-certificate" issued to a CA in the same hierarchy, and a
"cross-certificate" issued to a CA (maybe a Root CA/TopLevelCA/whatever)
in another hierarchy.

For example:  at the RSA Conference two weeks ago, John Ryan of Entrust
announced that the Government of Canada (which uses Entrust) and the
Government of Singapore (which also uses Entrust) will soon
cross-certify.  It seems to me that that's a valid use of the term - it
strikes me that:

        Scenario A:  the Top-Level CA of the Government of Canada issues a
CA-certificate to a subordinate CA for Revenue Canada, or some other
government department

        Scenario B:  the Top-Level CA of the Government of Canada issues a
cross-certificate to the Top-Level CA of the Government of Singapore,
permitting validation of communications among some end-users supported
by the two governments under certain conditions

are two different things, that ought to be recognized as such.  While it
may or may not be directly reflected in the certificate, the degree of
control exerted by the issuing CA over the certificate's recipient is
very different, and relying parties should be able to take this into
account.

So, how do we define this?  Let's start with Denis' suggestion:

>Cross-certificate: A CA-certificate issued by one CA for another CA that
>is either in a different naming hierarchy and/or in a different
>organizational structure.

I think this is okay, but I'd rather see "organizational structure"
replaced with "domain", which I think is a much more flexible term.

Bob Jueneman wrote:

1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
subject community or hierarchy) if the certificate containing the
distinguished name of the entity listed in the subject attribute was
issued by the same CA (distinguished name) whose distinguished name
appears in the issuer attribute in the same certificate.

I'm not sure I fully understand this (I went so far as to try
diagramming the sentence), but it seems to only allow two-level
hierarchies; e.g., a Top-Level CA and then one subordinate CA.  It seems
to fall apart if you try to build (Top-Level CA, CA, subordinate CA)
structures.  Bob:  is there anything you can do to clarify this?

                        Al Arsenault

- speaking only for myself.  My views do not necessarily reflect those
of my employer.

>

Date:         Tue, 27 Jan 1998 10:22:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

At 05:11 PM 1/26/98 -0700, Bob Jueneman wrote:

>How's this:
>
>1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a
subject community or hierarchy) if the certificate containing the
distinguished name of the entity listed in the subject attribute was issued
by the same CA (distinguished name) whose distinguished name appears in the
issuer attribute in the same certificate.
>
>2.  A Top-Level Certification Authority certificate is by definition a
self-signed certificate, i.e., one in which the issuer and subject
distinguished names are identical.  A TLCA normally issues certificates to
subordinate CAs and/or end-entities which contain the TLCA's name as the
issuer.
>
>3. A cross-certificate is a certificate issued to a end-entity (CA or
end-user) which is neither a subordinate  certificate as defined by (1),
nor a TLCA certificate as defined by (2).  I.e., the name of the issuing CA
in the certificate in question is _not_ the same as that contained in the
issuer attribute of any certificates issued to the subject entity by the
TLCA in that hierarchy.

I like these (assuming the correction that cross-certs can only be issued
to CA's as suggested by Denis). They are unambigious and seem to get at the
"what is a domain?" issue in a concrete way that avoids all the politics
and religion.

However, this now brings us to the engineering problem that somebody tried
to discuss a week or two back. Namely: how do we find all the certs we
need?  If the cross cert is required to point to a cert in our chain, we
are all set, but what if the relationship is more indirect?  Stealing
David's pictures:

                                          CA0
                         (2)                \
                                  CA1 ----> CA2
                                 /         /   \
                                E1        E2   E3

Assuming E1 has the CA1 cert, this case is easy, but

                                          CA0
               (3)                          \
                       CA1 ----> CA1a ----> CA2
                       /                   /   \
                      E1                  E2   E3

This requires a combination of bottom-up and top-down processing.  This is
further complicated if we have to protect against loops.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 27 Jan 1998 08:58:03 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Fillingham, David W." <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme
To: [email-masked]
Status:

Mack:

I definitely agree with you that it is "good news" that the NACHA CA
Demonstrators are taking advantage of the PKIX Part IV Policy Framework
to generate comparable policies!  This is precisely what the document
was written for - and it's great to see it being used as you describe!

I believe Section 5 of the Part IV document addresses your concern.  It
says...

5. PRACTICES AND POLICY SPECIFICATION OUTLINE

This section contains a possible outline for a practices and policy
specification, intended to serve as a checklist or (with some further
development) a standard template for use by certificate policy or CPS
writers.  Such a common outline will facilitate:

(a)  Comparison of two certificate policies during cross-certification
(for the purpose of equivalency mapping).

(b) Comparison of a CPS with a certificate policy definition to ensure
that the CPS faithfully implements the policy.

(c) Comparison of two CPSs.

It then goes on to provide a suggested numbered outline.  I think the
intent is that policies and CPS documents follow the Section 5 outline -
but if we can get the bulk of the CA community writing their policies
with the policy elements in the right order, then I think we'll have
made significant progress!  Not sure where the PKIX would make a
recommendation to do so, other than in the PKIX Part IV document itself
- and the recommendation is already there.

Thanks for your interest in, and support of, the IETF PKIX Policy
Framework!

Dave Fillingham

>----------
>From:  Mack Hicks[SMTP:[email-masked]]
>Sent:  Thursday, January 22, 1998 2:17 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme
>
>For: IETF-PKIX Mailing list
>
>As part of the NACHA Demonstrator for CA interoperability,
>the participant banks are putting together their Certificate Practice
>Stmts.  During this process, some people noted that the
>IETF PKIX Part IV - CPCPSF is being often being used as an outline.
>For example, the American Bar Association ISC is using the "same
>numbering scheme" in their documents (or so I was so informed.)
>
>This is really good news.
>Relying parties could then look at a CP and CPS by examining known
>paragraphs for information regarding such things as key size and
>authentication mechanisms.
>
>My question:
>
>  Is the numbering being used from the PART IV itself or from the
>  suggested outline?
>  Your CPCPSF numbering seems to be "slightly" different.
>
>  Since Part IV is not a standard, but a reference doc (sorry - I have
>  forgotten the exact name) - should there be a recommendation within
>  PKIX that CP's and CPS's follow the numbering scheme?
>
>PS:  NACHA Demonstrator <URL:http://www.nacha.org/tic/workgrps.htm#CA>
>
>-   -    -    -    -    -    -    -    -    -    -    -    -
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>
>

Date:         Tue, 27 Jan 1998 13:27:33 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Bob Jueneman wrote:

> >If we could come up with a simple and consensus-agreed definition
> >which could be quickly inserted into CMP, that would be ideal.
> >Can you write such a definition?  (I can't.)
>
> How's this:

(...)

> 3. A cross-certificate is a certificate issued to a end-entity (CA or end-user)

Bob,

If you take a look at part 3,section 3.5, we have "cross-certification:
An requesting CA provides to a responding CA ..." this means that the
end-entity CANNOT be an end-user.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Tue, 27 Jan 1998 13:45:09 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Carlisle Adams wrote:

(text deleted)

> Relying Party:  a relying party of a CA is an entity that validates
> certificate chains using the public key of that CA as an end-point
> (i.e., a trust anchor).

If we were going to need and keep that definition, then I would prefer
the following wording:

Relying Party:  a relying party of a CA is an entity that validates
certificate chains using one or more self-signed certificates of
that CA as an end-point (i.e., a trust anchor).

(text deleted)

An intuitive difference between a CA-certificate and a cross-certificate
is that a CA-certificate is a certificate simply stating that this is a
certificate issued by one CA for another CA, whereas a cross-certificate
implies that at the time the certificate is generated, the two CAs have
loose relationships. This may mean that they are in different naming
hierarchies and/or different organizational structures. Let me make a
try and put a Euro (instead of a cent) into the balance  :-)

Cross-certificate: A CA-certificate issued by one CA for another CA that
is either in a different naming hierarchy and/or in a different
organizational structure.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Mon, 26 Jan 1998 18:44:04 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
Comments: To: [email-masked]
To: [email-masked]
Status:

Unless there is a really good reason, I would prefer to use HMAC-SHA-1 rather than triple-DES MAC for password protection.

Although the use of triple-DES for password authentication may be approved for export from the US, proving beyond a reasonable doubt that that is all that it is used for may pose substantial difficulties. In addition, the use of triple-DES may also cause significant _import_ restrictions, e.g., into France, Russia, and some other countries.

As a general principle, we should not be using an encryption algorithm, especially a symmetric algorithm, when a safer, less controversial algorithm is available and more than adequate for the purpose.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> Nada Kapidzic Cicovic <[email-masked]> 01/22 2:47 AM >>>
At 11:46 1/21/98 -0500, Carlisle Adams wrote:
>Hi Nada,
>
>>----------
>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>Sent:  Monday, January 12, 1998 8:03 AM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] mandatory PasswordBasedMac
>>
>>I have one more comment on the completeness of ipki3cmp document.
>>
>>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
>>mandatory algorithm for PKI message protection. As far as I understand, the
>>reason for specifying mandatory algorithms is for easier interoperability
>>between complying implementations. However, PasswordBasedMac (as specified
>>in section "3.1.3 PKI Message Protection") is parametrized with a
>>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
>>but for MAC different alternatives are given.
>>
>>Shouldn't the specification of mandatory algorithms make clear which
>>algorithms should be used in place of the mentioned two parameters in
>>PasswordBasedMac? What would be the preferable alternatives?
>
>Good point (thanks for noticing this)!  Yes, a particular OWF and MAC
>should be mandated for interoperability purposes.
>
>Unless there are any strong objections, I think the most sensible
>choices would be SHA-1 for the OWF (since it's already mandated as part
>of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES
>(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and
>PROT_SYM_ALG).

Well, HMAC-SHA-1 is also a valid and presumably much faster alternative to
Triple-DES-MAC. If SHA-1 is mandatory for OWF, then HMAC-SHA-1 can be a
natural choice for the MAC.

BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
anybody have a pointer to some document specifying it?

Regards,

Nada

>
>I will add this to Appendix B2.  Thanks again!
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Mon, 26 Jan 1998 17:11:32 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
Comments: To: [email-masked]
To: [email-masked]
Status:

Dave,

>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed. Certificate definitions should certainly not depend on the container used to hold them!

>
>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".
>
>If we could come up with a simple and consensus-agreed definition
>which could be quickly inserted into CMP, that would be ideal.
>Can you write such a definition?  (I can't.)

How's this:

1.  A [CA] certificate is a subordinate [CA] certificate (e.g., within a subject community or hierarchy) if the certificate containing the distinguished name of the entity listed in the subject attribute was issued by the same CA (distinguished name) whose distinguished name appears in the issuer attribute in the same certificate.

2.  A Top-Level Certification Authority certificate is by definition a self-signed certificate, i.e., one in which the issuer and subject distinguished names are identical.  A TLCA normally issues certificates to subordinate CAs and/or end-entities which contain the TLCA's name as the issuer.

3. A cross-certificate is a certificate issued to a end-entity (CA or end-user) which is neither a subordinate  certificate as defined by (1), nor a TLCA certificate as defined by (2).  I.e., the name of the issuing CA in the certificate in question is _not_ the same as that contained in the issuer attribute of any certificates issued to the subject entity by the TLCA in that hierarchy.

Bob

>
>In the meantime, I agree with you that there appears to be a meaningful
>difference between a CA-cert and a cross-cert, even if we can't define
>what it is.  For that reason, I agree that it would be undesirable
>to change "cross-certificate" to "CA-certificate" in PKIX documents.
>Option (a) was better than option (b), but doing nothing is better
>still.

Option (a) would be better than (b), since most of the discussion in the PKIX documents seems to revolve around the issuance of subordinate CA certificate rather than what I would call a true cross-certificate.  But doing nothing would simply prolong the agony.

Bob

>
>Dave Kemp
>
>
>
>> From: Sharon Boeyen <[email-masked]>
>>
>> Cross-certification can certainly occur either uni-laterally or
>> bi-laterally.
>>
>>  If CA A issues a cross cert for CA B, that cross cert can be published
>> :
>> a)  by CA A as a forward cross-certificate in the cross-certificates
>> attribute of CA A's entry;
>> b)  by CA B as a reverse cross-certificate in the cross-certificates
>> attribute of CA B's entry;
>> c)  or both
>> If the cross-certification is bi-lateral the reverse would apply to the
>> cross-certificate issued by CA B for CA A.
>>
>> CA A should control what gets published/or not in its entry and CA B
>> control what gets published/or not in its entry. Nada is correct that in
>> no case should we expect that CA A have write permission to CA B's entry
>> or vice versa.
>>
>> I do expect that some of these directory specific issues will get
>> addressed in the PKIX LDAP schema specification that we agreed to pursue
>> at the December meeting. For instance, we would want to make sure that
>> cross-certificates are placed in the cross-certificates attribute and
>> not the CA-certificate attribute.
>>
>> Another reason to maintain the term cross-certification and not confuse
>> matters further.
>>
>> ------------------
>> Sharon Boeyen
>> Entrust Technologies

Date:         Mon, 26 Jan 1998 16:08:49 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

>Given Jeff's comments below, perhaps it is an appropriate time to invite
>all individuals/corporations participating in the PKIX work to inform us of
>any other patent filings or patents granted that might impact any of the
>PKIX projects.  We can do without more surprises down the track.

>Warwick

Other organizations I am aware of address this problem by assigning _)corporate_ membership in the group, and by signing a document which clearly spells out what the intellectual property rights of the "contributing" organization are vs. the rights of other members of the group, or the public.

The IETF, on the other hand, defines "membership" very loosely, if at all, and the contributions are generally viewed as being those of the individual, not the corporation.  It therefore seems difficult to assign the responsibility for patent clearance, licensing, etc., to the individual contributors, who may be quite ill-suited to that role.

I do agree that it would be poor form for someone to knowingly, much less deliberately, submit a contribution which later (surprise!) is revealed to be encumbered by a patent.

On the other hand, I suspect that 99% of the contributors to this list are not patent experts, and in many if not most cases, may have little or no knowledge of the patents currently held by their employer. Certainly I was unaware of the Novell patent in this area (CRL processing) until I heard about it from Phillip Halem-Baker, despite the fact that two of the inventors sit not more than 100 feet from me -- the patent originated prior to my joining Novell.  And I haven't had the time (or inclination, to be candid) to research the patent vs. the proposed standard (to which I have contributed only occasional comments) to see whether the proposed standard infringes or not.

Another issue is the extent to which a "contribution" is more or less complete and intact, vs. the more normal kinds of evolving commentary and dialogue.  In the case of a more or less complete contribution, I would normally expect that a company has reviewed the general concept to determine whether they have any intellectual property issues, prior to publicly disclosing what might be an invention. But in the case of a continued technical dialogue, I think it would be quite rare to get a IP review prior to making a suggestion that might ultimately be included in a proposed standard.

Of course another whole issue entirely is whether the IETF, and more particularly the IESG, does the public good or ill by what I perceive to be a rather blatant anti-intellectual property bias.  In other words, does deliberately crafting or modifying standards to avoid infringing on the valid inventions of others in the field tend to reward innovation and invention, or discourage it?

The world-wide system of patent protection is based on the assumption that by providing the creator of an invention the right to make a reasonable return on his work for a limited amount of time, the public will ultimately benefit from their labors, and hence the public good will be enhanced.

It would be interesting to know whether the IETF and particularly the IESG share this assumption.

Bob

(Speaking strictly for myself, and not necessarily for any past, present, or future employers, and/or any other organizations with which I may be associated)

>
>At 06:38 PM 1/13/98 -0500, Jeffrey I. Schiller wrote:
>>Indeed it is poor form for an individual to make contributions to a
>>working group and after the group has adopted those recommendations,
>>announce that the proposal is encumbered by that individual or the
>>individuals company (and the individual was aware of the encumbrance at
>>the time of suggestion). In other words, when you make a contribution to
>>a WG, it is exactly that, a *contribution*.
>>
>>Some believe that because the patent application process is secret, that
>>information about pending patents does not have to be revealed. This
>>just isn't so. Although the patent process is secret, it is completely
>>reasonable for the IETF to say "If you want to contribute a technology
>>to a working group effort, then you must disclosure your interest." If
>>you don't wish to disclose your interest, you don't have to make the
>>suggestion!
>>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

Date:         Tue, 27 Jan 1998 08:31:06 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 27 January 1998 1:15
Subject: Re: [IETF-PKIX] Cross Certification - Terminology

:> From: Charles Moore <[email-masked]>
:>
:> If we must, I would suggest the following:
:>
:> Cross-Certificates
:> CAs may cross-certify each other, that is each issue the other a
certificate
:> and combine the two certificates in a single directory attribute called a
:> crossCertificatePair. This crossCertificatePair attribute, supports
chains
:> of trust that run in both directions and implement trust models that
begin
:> at the CA which issued the users certificate, rather than trust models
where
:> trust originates from a common "root". A crossCertificatePair, includes
two
:> certificates, forward and reverse.  The subject of  the forward
certificate
:> is the issuer of the reverse certificate and vice-versa.
:
:
:Inter-domain certification is not necessarily bilateral, i.e. it does
:not always result in a crossCertificatePair.

The relevant definition is
CertificatePair    ::= SEQUENCE {
 forward   [0] Certificate OPTIONAL,
 reverse   [1] Certificate OPTIONAL}

I believe that there are optionals  here, the specification does not force a
particular solution.

snip.

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

Attachment converted: Lutefisk:smime.p7s 36 (????/----) (0001E31D)

Date:         Tue, 27 Jan 1998 07:56:13 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

-----Original Message-----
snip--

. For instance, we would want to make sure that
:cross-certificates are placed in the cross-certificates attribute and
:not the CA-certificate attribute.

Agree
:
:Another reason to maintain the term cross-certification and not confuse
:matters further.
:
Agree.

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

Attachment converted: Lutefisk:smime.p7s 35 (????/----) (0001E31B)

Date:         Mon, 26 Jan 1998 16:05:32 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

Consider the following two certification graphs, each with three
End Entities:

                                          CA0
  (1)                    (2)                \
         CA1                      CA1 ----> CA2
        /   \                    /         /   \
       E1   CA2                 E1        E2   E3
           /   \
          E2   E3

Graph (1) purports to be a single-rooted heirarchy where E1, E2 and E3 all
  begin verifying at the self-signed cert of CA1.  CA2 has a CA-certificate
  issued by CA1.

Graph (2) purports to represent unilateral cross-certification, where E1
  trusts CA1's self-signed cert, and E2 and E3 trust CA0's self-signed cert.
  (CA0 is introduced solely to allow CA2 to be a non-root in both graphs.)
  CA2 has a CA-certificate, which in this case is also a cross-certificate,
  issued by CA1.

Note to Phill: in this example both graphs are acyclic.

As much as I'd like to believe that there is a difference between
CA-certification within an organization/heirarchy and
cross-certification across unrelated organizations, I am unable to
discern any difference between the two graphs.  Today, in graph 2,
E2 and E3 trust root CA0.  Tomorrow, E2 might trust CA0 while E3
chooses to trust CA1.  The next day, they might both trust only CA1.
Next week, each might trust both CA0 and CA1.

Any scheme which labels a cert issued by CA1 to CA2 depending on the
independent and dynamic trust decisions made by CA2's subjects seems to
stand on shaky ground.  And Carlisle's proposal also implies that all
CA-certification fits his definition of cross-certification.

So I guess we're coming around to Warwick's option (b).

Date:         Mon, 26 Jan 1998 13:26:25 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

Sharon:

Well I, for one, asked many people who mentioned cross-certification for
clarification and, as with our experience on this list, was not overly
surprised to find that they were quite often talking about different
things.  The waters are muddy now.  We have no choice but to either define
the term or drop it.

Do I take it you are voting for my (b) option?

Warwick

At 08:04 AM 1/26/98 -0500, Sharon Boeyen wrote:
>I believe that removing the term cross-certification will do nothing
>more than add confusion to the situation. At the RSA conference last
>week, for example,  I attended numerous sessions where the term
>cross-certification was used repeatedly and not once did I hear a
>question asking for clarification. We will only muddy the waters now if
>we try to change the term, or even worse, people reading our documents
>may interpret that PKIX doesn't address cross-certification.
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>
>>----------
>>From:  Warwick Ford[SMTP:[email-masked]]
>>Sent:  January 25, 1998 7:03 PM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] Cross Certification - Terminology
>>
>>The thread on cross-certification terminology did not achieve much except
>>to confirm that many people have different views on what
>>"cross-certification" means and what needs to be done to address the
>>subject area.  We shall clearly not resolve all the issues here quickly,
>>but there were some valuable contributions to start from.
>>
>>However, we need immediately to clarify or fix the usage of the term in
>>PKIX 1 and CMP, since that is causing lots of confusion in the outside
>>world.  I see two simple alternatives, and feel we should adopt one of them
>>before these documents are published as proposed standards:
>>
>>(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
>>X.509-defined term "CA-certificate"; or
>>
>>(b) Explicitly define the term "cross-certificate" to be the same as the
>>term "CA-certificate" (as defined in X.509).
>>
>>I know that not everyone agrees with (b).  For that reason, I propose we do
>>(a), but am willing to open this up to one last round of opinions.
>>
>>Warwick
>>
>>---------------------------------------------------------------------
>>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>>---------------------------------------------------------------------
>>
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 26 Jan 1998 13:21:00 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed

>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".

Where are these communities defined? The subject community
could potentially be defined in the certificate (e.g. *.cnn.com), its
the relying party community that is fuzzy.

Regardless, I really don't think that the problem lies there. The
problem is that 'cross certification' is a property of the trust
graph, not the individual links that compose it. If the graph
is acyclic then no cross certification is going on, if it is cyclic
then there is.

This does not mean that there is a difference between a
CA certificate and a cross certificate however. Both are
simply a type of certificate that makes a claim to delegate
trust in some sense 'I trust X and all Y's that X trusts'.

If we were to define a cross certificate as a CA-certificate that
is a part of a cycle then the type of a particular certificate
would change simply by the issuing of a certificate that
completed a cycle.

E.G if Alice CA-certifies Bob and Bob CA-certifies Carol and
these are the only certificates existing then they are simply
CA-certificates, they could even fit into the PEM model. But
should Carol or Bob decide to CA-certify Alice all the
certificates suddenly become 'Cross certificates'.

This is clearly nonsense but I believe the root of the problem
is the attempt to make a distinction where none exists. Either
a party is making the statement 'trust this person as a CA'
or they are not. Issuing a CA cert involves liability and that is
so regardless of whether the certificate is called a CA-cert,
a cross-certificate or for that matter a PGP key signing.

There is a whole litterature on preventing deadlock in
communications networks that is in effect addressing the
same issue. Deadlock is a global property of networks,
not a property of individual arcs or nodes. Much confusion
was caused until that realisation was made.

It is important to remember that what is left out of
a specification can be just as important as what is
left in.

        Phill

Date:         Mon, 26 Jan 1998 12:43:10 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Dave,

Let's try this...

>----------
>From:  David P. Kemp[SMTP:[email-masked]]
>Sent:  Monday, January 26, 1998 11:09 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>Sharon,
>
>If CA A issues a certificate for CA B, what criteria are used to
>decide if it is a cross-certificate or a CA-certificate?
>
>Defining the distinction to be "if it's published in a
>cross-certificate directory attribute, then it's a cross-certificate"
>seems tautological - if there is no other distinction then there is no
>need for the two different types of directory attributes.

Agreed; this is hardly a useful definition.

>It seems clear to me that the distinction must be based on Tim Moses'
>concepts of "subject community" and "relying party community" -
>if those communities are identical then the cert is a CA cert,
>if the resulting communities are not identical then it is a cross-cert.
>But that just shifts the problem from defining "cross-certificate"
>to defining "subject community".

Here is a proposal.

Subject:  a subject of a CA is an entity that is identified by the
subject field of a certificate issued by that CA.

Relying Party:  a relying party of a CA is an entity that validates
certificate chains using the public key of that CA as an end-point
(i.e., a trust anchor).

Given these definitions, I would argue that if the "subject community"
and the "relying party community" are identical, then the cert is not
simply a certificate in which the subject and issuer are CAs, but a
"self-signed CA cert" in which the subject and issuer are the *same* CA
(since only a single CA can have this property).  If the communities are
not identical (as is the case by definition when the subject and issuer
CAs are distinct), then the cert is a "cross-certificate".

This is really the definition of cross-certification  implied by PKIX-1
and CMP ("any case of issuance of a certificate by one CA for another",
as Warwick put it), primarily because this is the definition implied by
X.509 itself where terms like CA-Certificate, CertificationPath,
CertificatePair, and CrossCertificates are all used in the same context
(that of constructing chains of certificates from a relying party to a
subject through an arbitrary set of distinct CAs).  See for example
Warwick's book "Computer Communications Security", p.389.  See also
Menezes, et al, "Handbook of Applied Cryptography", p.572, where
CA-certificate and cross-certificate are defined synonymously.

The point here is that *any* two CAs have different subject and relying
communities, regardless of whether they are in the same organizational
structure or different organizational structures, regardless of whether
they exist in the same hierarchy or different hierarchies or no
hierarchies at all.  Therefore, if they engage in unilateral or mutual
certification, the result is a cross-certificate (or a pair of
cross-certificates).

>If we could come up with a simple and consensus-agreed definition
>which could be quickly inserted into CMP, that would be ideal.
>Can you write such a definition?  (I can't.)

Comments on the above?

>In the meantime, I agree with you that there appears to be a meaningful
>difference between a CA-cert and a cross-cert, even if we can't define
>what it is.  For that reason, I agree that it would be undesirable
>to change "cross-certificate" to "CA-certificate" in PKIX documents.
>Option (a) was better than option (b), but doing nothing is better
>still.

If by "CA-cert" in the previous paragraph you mean "what goes into the
CA-certificate attribute for CA X's directory entry", then I think it
only makes sense for this to be CA X's self-signed certificate.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Mon, 26 Jan 1998 12:50:53 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

>I believe that removing the term cross-certification will do nothing
>more than add confusion to the situation. At the RSA conference last
>week, for example,  I attended numerous sessions where the term
>cross-certification was used repeatedly and not once did I hear a
>question asking for clarification

That is not necessarily a good thing. I have been to conferences
at which the term 'Object Oriented' has been used by almost
every speaker, in most cases as a synonym for 'modern'.

The purpose of a specification is to make the most precise
statement possible about a protocol. Terms that have been
discovered by marketing tend to rapidly become meaningless.

            Phill

Date:         Mon, 26 Jan 1998 11:09:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Sharon,

If CA A issues a certificate for CA B, what criteria are used to
decide if it is a cross-certificate or a CA-certificate?

Defining the distinction to be "if it's published in a
cross-certificate directory attribute, then it's a cross-certificate"
seems tautological - if there is no other distinction then there is no
need for the two different types of directory attributes.

It seems clear to me that the distinction must be based on Tim Moses'
concepts of "subject community" and "relying party community" -
if those communities are identical then the cert is a CA cert,
if the resulting communities are not identical then it is a cross-cert.
But that just shifts the problem from defining "cross-certificate"
to defining "subject community".

If we could come up with a simple and consensus-agreed definition
which could be quickly inserted into CMP, that would be ideal.
Can you write such a definition?  (I can't.)

In the meantime, I agree with you that there appears to be a meaningful
difference between a CA-cert and a cross-cert, even if we can't define
what it is.  For that reason, I agree that it would be undesirable
to change "cross-certificate" to "CA-certificate" in PKIX documents.
Option (a) was better than option (b), but doing nothing is better
still.

Dave Kemp

> From: Sharon Boeyen <[email-masked]>
>
> Cross-certification can certainly occur either uni-laterally or
> bi-laterally.
>
>  If CA A issues a cross cert for CA B, that cross cert can be published
> :
> a)  by CA A as a forward cross-certificate in the cross-certificates
> attribute of CA A's entry;
> b)  by CA B as a reverse cross-certificate in the cross-certificates
> attribute of CA B's entry;
> c)  or both
> If the cross-certification is bi-lateral the reverse would apply to the
> cross-certificate issued by CA B for CA A.
>
> CA A should control what gets published/or not in its entry and CA B
> control what gets published/or not in its entry. Nada is correct that in
> no case should we expect that CA A have write permission to CA B's entry
> or vice versa.
>
> I do expect that some of these directory specific issues will get
> addressed in the PKIX LDAP schema specification that we agreed to pursue
> at the December meeting. For instance, we would want to make sure that
> cross-certificates are placed in the cross-certificates attribute and
> not the CA-certificate attribute.
>
> Another reason to maintain the term cross-certification and not confuse
> matters further.
>
> ------------------
> Sharon Boeyen
> Entrust Technologies

Date:         Mon, 26 Jan 1998 15:35:30 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] R: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "applica tion"
To: [email-masked]
Status:

So you confirm my 2nd interpretation. Thank you.
  Adriano

> -----Messaggio originale-----
> Da:   Santosh Chokhani [SMTP:[email-masked]]
> Inviato:      luned“ 26 gennaio 1998 15.18
> A:    [email-masked]
> Oggetto:      Re: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning
> of             "application"
>
> Example of Application in this case are: electronic mail, retail
> transactions, contracts, travel order, etc.  I hope these examples
> clarify the term applications.
>
> > -----Original Message-----
> > From: Santoni Adriano [SMTP:[email-masked]]
> > Sent: Monday, January 26, 1998 7:25 AM
> > To:   [email-masked]
> > Subject:      [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of
> > "application"
> >
> > Hi all. Sorry if this question has been asked before.
> >
> > Regarding the following excerpt from
> draft-ietf-pkix-ipki-part4-02...
> >
> >         4.1.3  Community and Applicability
> >
> >                  [cut]
> >
> >                  This subcomponent also contains:
> >
> >                     *  A  list of applications for which the issued
> > certificates
> >                     are suitable.
> >
> >                     * A list  of  applications  for  which  use  of
> > the
> > issued
> >                     certificates is restricted.  (This list
> implicitly
> > prohibits
> >                     all other uses for the certificates.)
> >
> > ...anybody wants to explain if the term "application" here means:
> >
> > *       some specific software product (e.g. Netscape Navigator,
> Lotus
> > Domino, etc.)
> > *       a generic software system category that accomplish some
> > category
> > of business needs (e.g. home banking, software publishing, digital
> > signature of disk files, etc.)
> >
> > TIA to all volunteers,
> >    Adriano
> >
> > Ing. Adriano Santoni
> > Direzione Rete - Servizio Progettazione Rete Logica
> > Societˆ Interbancaria per l'Automazione - SIA S.p.A.
> > Viale Certosa, 218 - I-20156 MIlano
> >
> > Vox: +39 2 3005 277
> > Fax: +39 2 38003333
> > Email: [email-masked]
> > Website: http://www.sia.it

Date:         Mon, 26 Jan 1998 09:39:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

> From: Charles Moore <[email-masked]>
>
> If we must, I would suggest the following:
>
> Cross-Certificates
> CAs may cross-certify each other, that is each issue the other a certificate
> and combine the two certificates in a single directory attribute called a
> crossCertificatePair. This crossCertificatePair attribute, supports chains
> of trust that run in both directions and implement trust models that begin
> at the CA which issued the users certificate, rather than trust models where
> trust originates from a common “root”. A crossCertificatePair, includes two
> certificates, forward and reverse.  The subject of  the forward certificate
> is the issuer of the reverse certificate and vice-versa.

Inter-domain certification is not necessarily bilateral, i.e. it does
not always result in a crossCertificatePair.

I favor Warwick's option (a):

    (a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
        X.509-defined term "CA-certificate"

Date:         Mon, 26 Jan 1998 15:22:55 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Antonio Esposito <[email-masked]>
Subject:      [IETF-PKIX] unsubscribe
To: [email-masked]
Status:

<html><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.71.1712.3"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 size=2>unsubscribe</FONT></DIV></BODY></HTML>

</html>

Date:         Mon, 26 Jan 1998 09:18:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santosh Chokhani <[email-masked]>
Subject:      Re: [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "application"
To: [email-masked]
Status:

Example of Application in this case are: electronic mail, retail
transactions, contracts, travel order, etc.  I hope these examples
clarify the term applications.

> -----Original Message-----
> From: Santoni Adriano [SMTP:[email-masked]]
> Sent: Monday, January 26, 1998 7:25 AM
> To:   [email-masked]
> Subject:      [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of
> "application"
>
> Hi all. Sorry if this question has been asked before.
>
> Regarding the following excerpt from draft-ietf-pkix-ipki-part4-02...
>
>         4.1.3  Community and Applicability
>
>                  [cut]
>
>                  This subcomponent also contains:
>
>                     *  A  list of applications for which the issued
> certificates
>                     are suitable.
>
>                     * A list  of  applications  for  which  use  of
> the
> issued
>                     certificates is restricted.  (This list implicitly
> prohibits
>                     all other uses for the certificates.)
>
> ...anybody wants to explain if the term "application" here means:
>
> *       some specific software product (e.g. Netscape Navigator, Lotus
> Domino, etc.)
> *       a generic software system category that accomplish some
> category
> of business needs (e.g. home banking, software publishing, digital
> signature of disk files, etc.)
>
> TIA to all volunteers,
>    Adriano
>
> Ing. Adriano Santoni
> Direzione Rete - Servizio Progettazione Rete Logica
> Societˆ Interbancaria per l'Automazione - SIA S.p.A.
> Viale Certosa, 218 - I-20156 MIlano
>
> Vox: +39 2 3005 277
> Fax: +39 2 38003333
> Email: [email-masked]
> Website: http://www.sia.it

Date:         Mon, 26 Jan 1998 08:29:32 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Cross-certification can certainly occur either uni-laterally or
bi-laterally.

 If CA A issues a cross cert for CA B, that cross cert can be published
:
a)  by CA A as a forward cross-certificate in the cross-certificates
attribute of CA A's entry;
b)  by CA B as a reverse cross-certificate in the cross-certificates
attribute of CA B's entry;
c)  or both
If the cross-certification is bi-lateral the reverse would apply to the
cross-certificate issued by CA B for CA A.

CA A should control what gets published/or not in its entry and CA B
control what gets published/or not in its entry. Nada is correct that in
no case should we expect that CA A have write permission to CA B's entry
or vice versa.

I do expect that some of these directory specific issues will get
addressed in the PKIX LDAP schema specification that we agreed to pursue
at the December meeting. For instance, we would want to make sure that
cross-certificates are placed in the cross-certificates attribute and
not the CA-certificate attribute.

Another reason to maintain the term cross-certification and not confuse
matters further.

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  January 26, 1998 4:08 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] cross-certification
>
>At 12:03 1/22/98 -0500, you wrote:
>>Hi Nada,
>>
>>>----------
>>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>>Sent:  Thursday, January 22, 1998 5:26 AM
>>>To:    [email-masked]
>>>Subject:       [IETF-PKIX] cross-certification
>>>
>>>Carlisle,
>>>
>....
>
>>>My additional question on second sentence in B7 is: why is publication of
>>>cross-certificate responsibility of requesting CA, and not of the issuing
>>>CA as in any other case?
>>
>>Certainly, the certificate could be published by either side.  However,
>>a basic premise in this document is that the issuing CA (i.e., the one
>>that actually creates and signs the certificate) has final authority
>>over the certificate contents.  Thus, an EE can put anything in the
>>cert. template, but the CA is free to make any modifications that it
>>likes.  The same is true for the cross certification exchange.  Note,
>>though, that for this particular case it may be of slightly more
>>importance that the requester fully approve of all the contents of the
>>certificate before it gets published.  It seemed to me that the simplest
>>way to ensure this was to specify in no uncertain terms that the
>>requester is the one responsible for publishing.
>>
>
>My concern is that requesting CA will not have enough privileges to publish
>the cross-certificate into issuing CA's directory. (This certificate should
>be published in issuing CA's directory, since it is intended to be used by
>end-entities in issuing CA's domain when verifying certificates from
>requester CA's domain.)
>
>Therefore, it seems more natural to have cross-certificate published by its
>issuer.
>
>Regards,
>
>Nada
>
>
>>
>>--------------------------------------------
>>Carlisle Adams
>>Entrust Technologies
>>[email-masked]
>>--------------------------------------------
>>
>______________________________________________________________
>
>Nada Kapidzic Cicovic
>COST - Computer Security Technologies CST AB
>(subsidiary of Entegrity Solutions Corporation)
>office:   + 46 (0)8 477 77 37
>mobile:   + 46 (0)70 495 09 03
>fax:      + 46 (0)8 477 77 31
>e-mail:   [email-masked] or [email-masked]
>address:  Finlandsgatan 60, 164 74 Kista, Sweden
>

Date:         Mon, 26 Jan 1998 08:04:54 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

I believe that removing the term cross-certification will do nothing
more than add confusion to the situation. At the RSA conference last
week, for example,  I attended numerous sessions where the term
cross-certification was used repeatedly and not once did I hear a
question asking for clarification. We will only muddy the waters now if
we try to change the term, or even worse, people reading our documents
may interpret that PKIX doesn't address cross-certification.
------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  January 25, 1998 7:03 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Cross Certification - Terminology
>
>The thread on cross-certification terminology did not achieve much except
>to confirm that many people have different views on what
>"cross-certification" means and what needs to be done to address the
>subject area.  We shall clearly not resolve all the issues here quickly,
>but there were some valuable contributions to start from.
>
>However, we need immediately to clarify or fix the usage of the term in
>PKIX 1 and CMP, since that is causing lots of confusion in the outside
>world.  I see two simple alternatives, and feel we should adopt one of them
>before these documents are published as proposed standards:
>
>(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
>X.509-defined term "CA-certificate"; or
>
>(b) Explicitly define the term "cross-certificate" to be the same as the
>term "CA-certificate" (as defined in X.509).
>
>I know that not everyone agrees with (b).  For that reason, I propose we do
>(a), but am willing to open this up to one last round of opinions.
>
>Warwick
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
>

Date:         Mon, 26 Jan 1998 13:24:45 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Santoni Adriano <[email-masked]>
Subject:      [IETF-PKIX] draft-ietf-pkix-ipki-part4-02: meaning of "application"
To: [email-masked]
Status:

Hi all. Sorry if this question has been asked before.

Regarding the following excerpt from draft-ietf-pkix-ipki-part4-02...

        4.1.3  Community and Applicability

                 [cut]

                 This subcomponent also contains:

                    *  A  list of applications for which the issued
certificates
                    are suitable.

                    * A list  of  applications  for  which  use  of  the
issued
                    certificates is restricted.  (This list implicitly
prohibits
                    all other uses for the certificates.)

...anybody wants to explain if the term "application" here means:

*       some specific software product (e.g. Netscape Navigator, Lotus
Domino, etc.)
*       a generic software system category that accomplish some category
of business needs (e.g. home banking, software publishing, digital
signature of disk files, etc.)

TIA to all volunteers,
   Adriano

Ing. Adriano Santoni
Direzione Rete - Servizio Progettazione Rete Logica
Societˆ Interbancaria per l'Automazione - SIA S.p.A.
Viale Certosa, 218 - I-20156 MIlano

Vox: +39 2 3005 277
Fax: +39 2 38003333
Email: [email-masked]
Website: http://www.sia.it

Date:         Mon, 26 Jan 1998 10:51:33 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Hamming, J.E." <[email-masked]>
Subject:      [IETF-PKIX] Question
To: [email-masked]
Status:

how do i remove myself from this list?

Date:         Mon, 26 Jan 1998 10:08:47 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

At 12:03 1/22/98 -0500, you wrote:
>Hi Nada,
>
>>----------
>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>Sent:  Thursday, January 22, 1998 5:26 AM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] cross-certification
>>
>>Carlisle,
>>
....

>>My additional question on second sentence in B7 is: why is publication of
>>cross-certificate responsibility of requesting CA, and not of the issuing
>>CA as in any other case?
>
>Certainly, the certificate could be published by either side.  However,
>a basic premise in this document is that the issuing CA (i.e., the one
>that actually creates and signs the certificate) has final authority
>over the certificate contents.  Thus, an EE can put anything in the
>cert. template, but the CA is free to make any modifications that it
>likes.  The same is true for the cross certification exchange.  Note,
>though, that for this particular case it may be of slightly more
>importance that the requester fully approve of all the contents of the
>certificate before it gets published.  It seemed to me that the simplest
>way to ensure this was to specify in no uncertain terms that the
>requester is the one responsible for publishing.
>

My concern is that requesting CA will not have enough privileges to publish
the cross-certificate into issuing CA's directory. (This certificate should
be published in issuing CA's directory, since it is intended to be used by
end-entities in issuing CA's domain when verifying certificates from
requester CA's domain.)

Therefore, it seems more natural to have cross-certificate published by its
issuer.

Regards,

Nada

>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Mon, 26 Jan 1998 09:12:48 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Denis Pinkas <[email-masked]>
Organization: Bull
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

Warwick Ford wrote:

 :The thread on cross-certification terminology did not achieve much
except
 :to confirm that many people have different views on what
 :"cross-certification" means and what needs to be done to address the
 :subject area.  We shall clearly not resolve all the issues here
quickly,
 :but there were some valuable contributions to start from.
 :
 :However, we need immediately to clarify or fix the usage of the term
in
 :PKIX 1 and CMP, since that is causing lots of confusion in the outside
 :world.
 :
 : I see two simple alternatives, and feel we should adopt one of them
 :before these documents are published as proposed standards:
 :
 :(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
 :X.509-defined term "CA-certificate"; or

This seems reasonable. However, seeing how would look the text (only for
the sections where the word is used) would be nice before a complete new
draft is re-issued.

 :(b) Explicitly define the term "cross-certificate" to be the same as
the
 :term "CA-certificate" (as defined in X.509).
 :
 :I know that not everyone agrees with (b).  For that reason, I propose
we do
 :(a), but am willing to open this up to one last round of opinions.

Charles Moore wrote:

> If we must, I would suggest the following:
>
> Cross-Certificates
> CAs may cross-certify each other,

I fear you are re-opening an issue that I thought to be closed.
Cross-certification is one way, not necessarilly bi-lateral.

> that is each issue the other a certificate
> and combine the two certificates in a single directory attribute called a
> crossCertificatePair. This crossCertificatePair attribute, supports chains
> of trust that run in both directions and implement trust models that begin
> at the CA which issued the users certificate, rather than trust models where
> trust originates from a common ãrootä. A crossCertificatePair, includes two
> certificates, forward and reverse.  The subject of  the forward certificate
> is the issuer of the reverse certificate and vice-versa.

I do not agree with the above. Warwick is pretty right when he says
"many people have different views on what "cross-certification" means.
:-)

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.         E-mail : [email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date:         Mon, 26 Jan 1998 11:59:55 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, 26 January 1998 7:25
Subject: [IETF-PKIX] Cross Certification - Terminology

:The thread on cross-certification terminology did not achieve much except
:to confirm that many people have different views on what
:"cross-certification" means and what needs to be done to address the
:subject area.  We shall clearly not resolve all the issues here quickly,
:but there were some valuable contributions to start from.
:
:However, we need immediately to clarify or fix the usage of the term in
:PKIX 1 and CMP, since that is causing lots of confusion in the outside
:world.
Is it?
: I see two simple alternatives, and feel we should adopt one of them
:before these documents are published as proposed standards:
:
:(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
:X.509-defined term "CA-certificate"; or
:
:(b) Explicitly define the term "cross-certificate" to be the same as the
:term "CA-certificate" (as defined in X.509).
:
:I know that not everyone agrees with (b).  For that reason, I propose we do
:(a), but am willing to open this up to one last round of opinions.

If we must, I would suggest the following:

Cross-Certificates
CAs may cross-certify each other, that is each issue the other a certificate
and combine the two certificates in a single directory attribute called a
crossCertificatePair. This crossCertificatePair attribute, supports chains
of trust that run in both directions and implement trust models that begin
at the CA which issued the users certificate, rather than trust models where
trust originates from a common ãrootä. A crossCertificatePair, includes two
certificates, forward and reverse.  The subject of  the forward certificate
is the issuer of the reverse certificate and vice-versa.

Cross certificates provide a simple technical mechanism that may support a
number of different policies, such policies are not subject to
standardisation within PKIX.

:
:Warwick
:
:---------------------------------------------------------------------
:Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
:   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
:---------------------------------------------------------------------
:

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

Attachment converted: Lutefisk:smime.p7s 33 (????/----) (0001E315)

Date:         Sun, 25 Jan 1998 16:51:37 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and ignored.
Comments:     RFC822 error: <E> Mail origin cannot be determined.
Comments:     RFC822 error: <E> Original tag data was -> Brian Franks <>
From: Undetermined origin c/o LISTSERV administrator <[email-masked]>
Subject:      [IETF-PKIX] Search Engines
To: [email-masked]
Status:

I saw your web site on the internet.  I work
for a company that submits web sites to search
engines.  We can submit your web site to over
250 of the worlds best  search engines for only
$39.95!  If you would like to put your web site in
the fast lane and get more  hits, call our 800#
or see our web page for more information.

Sincerely,

Brian Franks
NetWorld
(800) 484-2621 X5568

Date:         Sun, 25 Jan 1998 16:03:37 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] Cross Certification - Terminology
To: [email-masked]
Status:

The thread on cross-certification terminology did not achieve much except
to confirm that many people have different views on what
"cross-certification" means and what needs to be done to address the
subject area.  We shall clearly not resolve all the issues here quickly,
but there were some valuable contributions to start from.

However, we need immediately to clarify or fix the usage of the term in
PKIX 1 and CMP, since that is causing lots of confusion in the outside
world.  I see two simple alternatives, and feel we should adopt one of them
before these documents are published as proposed standards:

(a) Replace the term "cross-certificate" in PKIX 1 and CMP by the
X.509-defined term "CA-certificate"; or

(b) Explicitly define the term "cross-certificate" to be the same as the
term "CA-certificate" (as defined in X.509).

I know that not everyone agrees with (b).  For that reason, I propose we do
(a), but am willing to open this up to one last round of opinions.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Sat, 24 Jan 1998 22:14:34 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] another characteristic of online validation.
To: [email-masked]
Status:

Mack Hicks wrote:
> I have to voice my agreement with Mike that cross-certification
> is not manageable (technical banking term - "scary".))
>
> An example, the trusted relationships between UNIX nodes.  One can
> make the point that the Rhost kind of trust is similar to the
> cross-certification model.  Rhost type of trust has done nothing
> but get lots of people into lots and lots of trouble.
>
> 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."
>
> Some people think banks trust each other through their Am Bnks Ass
> number (like on the checks).  Anyone who has gotten a bounced check
> knows this is not the case.  Knowing the "naming" and "addressing"
> (name constraints!) does not increase the level of trust.
>
> Keeping naming constraints current - or even manageable - is the
> full time task for lots of people in the mainframe world.
> Keeping that trust (usually in one place - like RACF or ACF2)
> is a full time job that often goes horribly wrong.
>
>
> 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?
>
> -   -    -    -    -    -    -    -    -    -    -    -    -
> Mack Hicks (415) 278-7230  -- Interactive Banking Division
> 425 1st St m/s3671, SF CA 94105 <[email-masked]>

another characteristic we've been exploring with x9.59 and aads is the
question of systemic risk introduced by inserting a dependency on
some other agency when completing a transaction. imagine a financial
institution with triple redundant implementation at three harden sites
spread around the country ... and now having to go out over the
internet and finding some CA operating in somebody's closet
in order to complete a transaction. How many people would like
to have "whether or not their paycheck got deposted in their
bank account" dependent on if a http "hit" was succesful or not.

for some of the discussion see http://www.garlic.com/~lynn/

Date:         Sat, 24 Jan 1998 16:38:13 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: D26NM061/26/M/IBM <[email-masked]>
Subject:      [IETF-PKIX] David Hemsath/Austin/IBM is out of the office.
To: [email-masked]
Status:

I am out of the office from 01/24/98, returning 02/02/98.  You will receive
only this notification of my absence prior to my return, at which time I will
respond.

Date:         Sat, 24 Jan 1998 16:03:19 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Given Jeff's comments below, perhaps it is an appropriate time to invite
all individuals/corporations participating in the PKIX work to inform us of
any other patent filings or patents granted that might impact any of the
PKIX projects.  We can do without more surprises down the track.

Warwick

At 06:38 PM 1/13/98 -0500, Jeffrey I. Schiller wrote:
>Indeed it is poor form for an individual to make contributions to a
>working group and after the group has adopted those recommendations,
>announce that the proposal is encumbered by that individual or the
>individuals company (and the individual was aware of the encumbrance at
>the time of suggestion). In other words, when you make a contribution to
>a WG, it is exactly that, a *contribution*.
>
>Some believe that because the patent application process is secret, that
>information about pending patents does not have to be revealed. This
>just isn't so. Although the patent process is secret, it is completely
>reasonable for the IETF to say "If you want to contribute a technology
>to a working group effort, then you must disclosure your interest." If
>you don't wish to disclose your interest, you don't have to make the
>suggestion!
>

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Fri, 23 Jan 1998 15:37:42 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: RPK New Zealand Ltd <[email-masked]>
Subject:      [IETF-PKIX] Announcement: RPK InvisiMail released on 12 Jan, 1998
To: [email-masked]
Status:

You have received this message because at some time during the past two years you have requested to be put on the RPK New Zealand Ltd. company mailing list.  (We're the Fast Public Key Encryption company).  If you wish to be removed from the list, please forward this message to [email-masked]

--------------------------------

RPK New Zealand Ltd. in a joint venture with Virtually Online Ltd. has released RPK InvisiMail, a standards-based e-mail security application for use with Internet mail software (SMTP/POP3).  The product offers the strongest encryption available anywhere in the world.  Since it was built outside the United States, it is also available all over the world with strong encryption.  RPK InvisiMail is also the easiest product of its type to setup and use which makes it quite unique.

You can learn more about this product by reading the press release below or by visiting the web site at www.InvisiMail.com.  We are also offering FREE downloads of the RPK InvisiMail Intro product.  Please give it a try and pass it along to anyone you like.

--------------------------------

For Immediate Release

Contact:        Sal Cataldi, Cataldi PR +1 212.941.9464, [email-masked], www.InvisiMail.com

RPK InvisiMail(tm), secure Internet e-mail with globally available strong encryption for Microsoft, Netscape platforms

SAN FRANCISCO, Jan. 12, 1998 - InvisiMail Ltd (www.InvisiMail.com) announced today immediate worldwide availability of RPK(tm) InvisiMail(tm), a standards-based e-mail security add-in for Microsoft, Netscape and other POP3/SMTP Internet e-mail clients and gateway servers.  Tested and certified by the International Computer Security Association (www.ncsa.com), RPK InvisiMail automatically and transparently encrypts e-mail messages and attachments, authenticates the sender and verifies the contents of each message have not been changed in transit.

RPK InvisiMail is globally available with high strength encryption.  InvisiMail and the underlying RPK encryption algorithm were developed outside the United States.  Therefore, InvisiMail is not subject to restrictive U.S. export policies.  RPK InvisiMail is as easy to set up and use as anti-virus software, and just as important.

While Microsoft and Netscape battle each other with incompatible and difficult to use security offerings, InvisiMail seamlessly integrates with ALL popular POP3/SMTP e-mail products including Netscape, Microsoft, Eudora, Pegasus, Calypso -- more than any other solution available today -- making it the preferred e-mail security product for multi-platform use, worldwide.

All InvisiMail users can send the FREE InvisiMail Intro version to anyone worldwide, providing compatibility without requiring others to purchase anything, making InvisiMail unique among
e-mail security offerings.

"Most people don't realize that their e-mail can be forged, altered or read by anyone, any time, without any evidence," said Jack Oswald, President and CEO of RPK Ltd.  "Without products like RPK InvisiMail, communications on the Internet are untrustworthy."

InvisiMail uses the RPK Fast Public Key Encryptonite(tm) Engine, the strongest cryptography available worldwide today.  RPK is dramatically faster than the well-known RSA algorithm, yet just as secure.  RPK has been analyzed by world class cryptographers who have issued reports on the security and integrity of the technology.

"InvisiMail is the easiest, fastest, most transparent e-mail security product I have seen," said Kevin Shannon, President of net*Gain, a specialist in launching Internet companies. "This is the product we've all been waiting for."

As part of its official launch, InvisiMail Professional is available FREE to all New Zealand residents for ninety days.

RPK InvisiMail is available in two desktop versions: Intro (FREE) and Professional (introductory price $29.95).  RPK InvisiMail Enterprise Gateway Server will be available Q2 1998.  InvisiMail can be downloaded from: www.InvisiMail.com.

All trademarks and registered trademarks are those of their respective companies.

***

Date:         Fri, 23 Jan 1998 09:09:59 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Kesselman, Glenn A" <[email-masked]>
Subject:      [IETF-PKIX] Please add me to the mailing list
To: [email-masked]
Status:

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------ =_NextPart_001_01BD27DE.AEE2BD00
Content-Type: text/plain

Glenn A. Kesselman
Director of Western Regional Sales
Entegrity Solutions Corp.
2077 Gateway Place, Suite 200
San Jose, CA 95110
Voice: (408) 487-8600 ext. 117
Fax: (408) 487-8610
[email-masked]
http://www.entegrity.com

------ =_NextPart_001_01BD27DE.AEE2BD00
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.0.1457.3">

</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=3D2 FACE=3D"Arial">Glenn A. =
Kesselman&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Director of Western Regional Sales =
</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Entegrity Solutions Corp.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2077 Gateway Place, Suite 200</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">San Jose, CA =
95110&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Voice: (408) 487-8600 ext. =
117&nbsp;</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Fax: (408) 487-8610 </FONT>
<BR><FONT SIZE=3D2 =
FACE=3D"Arial">[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A =
HREF=3D"http://www.entegrity.com" =
TARGET=3D"_blank">http://www.entegrity.com</A></FONT></U>
<BR>
<BR>
</P>

</BODY>
</HTML>
------ =_NextPart_001_01BD27DE.AEE2BD00--

Date:         Fri, 23 Jan 1998 14:48:59 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jakob Bjerre Jensen <[email-masked]>
Subject:      [IETF-PKIX] PKIX information flow ...
To: [email-masked]
Status:

Dear PKIX-list.

I have some questions, which I hope someone can answer:

Consider the PKI-scenario consiting of

     1. CA
     2. RAs
     3. a repository/directory
     4. some End Entities

Having read PKIX: Infrastructure Certificate Management Protocols, PKI
Operational Protocols- LDAPv2
and RFC 1777 (LDAP) I am under the impression, that information flowing
between the instances in such a
PKI is done through the ASN.1 structure

 PKIMessage ::= SEQUENCE {
      header           PKIHeader,
      body             PKIBody,
      protection   [0] PKIProtection OPTIONAL,
      extraCerts   [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL
  }

and that information flowing between the repository/directory and end
entities alternatively
could be done through LDAPv2.

Is this correct?

Next: Does someone have experience with PKIX with information flow
building on the above PKIMessage
structure and/or LDAP (directory <--> end entities) ?

- Jakob

Alternate-recipient: Allowed
Disclose-recipients: Prohibited
Content-return: Allowed
Content-identifier: 06BC834C79B42220
Conversion: Allowed
Original-encoded-information-types: IA5-Text
Priority: normal
X400-Content-type: P2-1988 ( 22 )
X400-MTS-identifier: [/c=US/admd=attmail/; 06BC834C79B42220-attmail]
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date:         Thu, 22 Jan 1998 11:17:22 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Mack Hicks <[email-masked]>
Subject:      [IETF-PKIX] PKIX Part IV - CPCPSF - Number scheme
Comments: To: Return requested <[email-masked]>
To: [email-masked]
Status:

For: IETF-PKIX Mailing list

As part of the NACHA Demonstrator for CA interoperability,
the participant banks are putting together their Certificate Practice
Stmts.  During this process, some people noted that the
IETF PKIX Part IV - CPCPSF is being often being used as an outline.
For example, the American Bar Association ISC is using the "same
numbering scheme" in their documents (or so I was so informed.)

This is really good news.
Relying parties could then look at a CP and CPS by examining known
paragraphs for information regarding such things as key size and
authentication mechanisms.

My question:

  Is the numbering being used from the PART IV itself or from the
  suggested outline?
  Your CPCPSF numbering seems to be "slightly" different.

  Since Part IV is not a standard, but a reference doc (sorry - I have
  forgotten the exact name) - should there be a recommendation within
  PKIX that CP's and CPS's follow the numbering scheme?

PS:  NACHA Demonstrator <URL:http://www.nacha.org/tic/workgrps.htm#CA>

-   -    -    -    -    -    -    -    -    -    -    -    -
Mack Hicks (415) 278-7230  -- Interactive Banking Division
425 1st St m/s3671, SF CA 94105 <[email-masked]>

Date:         Thu, 22 Jan 1998 12:03:18 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Hi Nada,

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  Thursday, January 22, 1998 5:26 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] cross-certification
>
>Carlisle,
>
>Thanks for replying to my previous messages. I the meantime I found one
>more strangeness in ipki3cmp:
>
>In 4.6.1 One-way request-response scheme of cross-certification, it is
>stated that all messages in this scheme (request/response/confirm) will be
>protected with a MAC based on a shared authentication code.
>However, Appendix B7 states that protection bits on these messages are to
>be calculated using MSG_SIG_ALG.
>
>I suppose that the proper way of protection of cross-certification messages
>is the one described in B7, and that section 4.6.1 should be modified
>accordingly.

Actually, it's the other way around:  4.6.1 is correct and B7 should be
modified to MSG_MAC_ALG.  Thanks again for your careful reading.

>My additional question on second sentence in B7 is: why is publication of
>cross-certificate responsibility of requesting CA, and not of the issuing
>CA as in any other case?

Certainly, the certificate could be published by either side.  However,
a basic premise in this document is that the issuing CA (i.e., the one
that actually creates and signs the certificate) has final authority
over the certificate contents.  Thus, an EE can put anything in the
cert. template, but the CA is free to make any modifications that it
likes.  The same is true for the cross certification exchange.  Note,
though, that for this particular case it may be of slightly more
importance that the requester fully approve of all the contents of the
certificate before it gets published.  It seemed to me that the simplest
way to ensure this was to specify in no uncertain terms that the
requester is the one responsible for publishing.

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Thu, 22 Jan 1998 11:26:14 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      [IETF-PKIX] cross-certification
To: [email-masked]
Status:

Carlisle,

Thanks for replying to my previous messages. I the meantime I found one
more strangeness in ipki3cmp:

In 4.6.1 One-way request-response scheme of cross-certification, it is
stated that all messages in this scheme (request/response/confirm) will be
protected with a MAC based on a shared authentication code.
However, Appendix B7 states that protection bits on these messages are to
be calculated using MSG_SIG_ALG.

I suppose that the proper way of protection of cross-certification messages
is the one described in B7, and that section 4.6.1 should be modified
accordingly.

My additional question on second sentence in B7 is: why is publication of
cross-certificate responsibility of requesting CA, and not of the issuing
CA as in any other case?

Regards,

Nada

Date:         Thu, 22 Jan 1998 10:47:06 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

At 11:46 1/21/98 -0500, Carlisle Adams wrote:
>Hi Nada,
>
>>----------
>>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>>Sent:  Monday, January 12, 1998 8:03 AM
>>To:    [email-masked]
>>Subject:       [IETF-PKIX] mandatory PasswordBasedMac
>>
>>I have one more comment on the completeness of ipki3cmp document.
>>
>>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
>>mandatory algorithm for PKI message protection. As far as I understand, the
>>reason for specifying mandatory algorithms is for easier interoperability
>>between complying implementations. However, PasswordBasedMac (as specified
>>in section "3.1.3 PKI Message Protection") is parametrized with a
>>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
>>but for MAC different alternatives are given.
>>
>>Shouldn't the specification of mandatory algorithms make clear which
>>algorithms should be used in place of the mentioned two parameters in
>>PasswordBasedMac? What would be the preferable alternatives?
>
>Good point (thanks for noticing this)!  Yes, a particular OWF and MAC
>should be mandated for interoperability purposes.
>
>Unless there are any strong objections, I think the most sensible
>choices would be SHA-1 for the OWF (since it's already mandated as part
>of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES
>(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and
>PROT_SYM_ALG).

Well, HMAC-SHA-1 is also a valid and presumably much faster alternative to
Triple-DES-MAC. If SHA-1 is mandatory for OWF, then HMAC-SHA-1 can be a
natural choice for the MAC.

BTW, what is the object identifier for HMAC-SHA-1 (and other HMACs)? Does
anybody have a pointer to some document specifying it?

Regards,

Nada

>
>I will add this to Appendix B2.  Thanks again!
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------
>
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Wed, 21 Jan 1998 15:06:28 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      [IETF-PKIX] late meeting minutes
Comments: To: Dixie Walker <[email-masked]>
To: [email-masked]
Status:

<x-rich><fontfamily><param>Times</param><bigger><bigger>PKIX WG Meeting Minutes
(12/8+10/97)

Approximately 360 attendees participated in the two PKIX WG session at

the 40th IETF.  Several of the PKIX I-Ds have been through working

group last call and have moved on to the IESG for review, but a few

issues remain and must be resolved prior to IESG approval and IETF

last call.

Part 1 (Certificate/CRL Profile)

This draft completed WG last call, but a few issues remain to be

resolved.  Issues relating to use of algorithm OIDs and some ASN.1

errors have been resolved, and the authors have avoided inclusion of

some legal language that was previously proposed.

Unresolved issues:

        - There is disagreement about wildcarding in names (e.g., DNS

and RFC 822).  A small group met to resolve this issue after the (2nd)

meeting.  That group suggested disallowing use of asterisks in these

name forms as a means of conveying the notion that the name was a

place-holder for a set of names.  Instead, a new document will be

created to describe name form conventions, on a per-application

context basis, with explicitly declared semantics, in support of the

requirements that motivated use of wildcard name forms.

        - We are using '88 ASN.1, but BMP string is a new ASN.1

construct, so this is a technical matter (but does not affect bit on

the wire format).

        - There is a related issue is use of UTF8, a new ('98 ASN.1)

character set encoding, an alternative to BMP.  This appears to be an

issue at the IESG last call level of approval, but is not an issue

among PKIX members.

        - For key usage, we propose to stay with what X.509 says,

despite disagreements over whether it is the "right" interpretation.

        - Should CRLDistributionPoint be critical, non-critical, or at

the discretion of the CA?  Currently, it cannot be marked critical,

but this can cause problems.  The concern is that if marked critical,

then a client without support for this would reject the certificate,

even if the user was willing to ignore this extension, as required by

X.509. Not resolved.

Part 2 (split into LDAP, FTP, HTTP, OCSP)

No problems with FTP or HTTP. LDAP v2 profile completed both

last calls and is to be forwarded to IESG for approval.  We agree to
add

a new work item to deal with v3, since current LDAP use in PKIX is
based

on v2.  There was a suggestion to add a work item to develop a minimal

schema for PKIX use of LDAP.  This is a possible overlap with the LDAP

WG, so coordination is required.  Later during the week the LDAP WG
chair

was contacted and it was determined that creation of a schema for use
with

PKIX was within the purview of the PKIX WG. See slides for additional
details.

Part 3 (Certificate Management Protocol)

No issues here other than the character set concerns raised under Part
1.

Certificate Request Syntax (PKCS7/10 focus)

A proposal was made to move work on this to S/MIME WG, and Schiller

and Housley (S/MIME WG chair) have no objections.  However, this work

is not S/MIME-specific and several PKIX and S/MIME WG members believe

that this work item should remain in PKIX, as it is more general.  The

fundamental question is whether CRS is a completely separate protocol,

focused on S/MIME, or if it is a profile for Part 3.  This was
subsequently

resolved [see below]. A straw poll of attendees showed a plurality of
attendees

in favor of keeping the work item in this WG, and only a single vote in
favor of

moving it to S/MIME.  The S/MIME WG, meeting two days later, concurred

with this and did not recommend adoption of CRS within that WG,
assuming that

PKIX would reconcile CRS/CMP differences and include a specification
for

securely transporting commonly-agreed certificate management messages
over

CMS (i.e., son of PKCS 7).

At the second PKIX WG meeting, a compromise approach was announced,

aimed at reconciling differences between CRS and CMP.  In essence, a

common certificate request message syntax was agreed upon, and CMP
will

adopt this syntax as the certificate request payload type within that
protocol

(replacing the current certificate request payload format).  CRS also
will be

revised to reference that syntax.  This new, harmonized certificate
request

format will appear as a separate RFC.  It is not anticipated that

this will delay the progression of CMP to proposed standard, since it
is

simply a protocol syntax change for alignment purposes, plus a
splitting of

one document into two in the interest of facilitating future
developments.

CRS will continue to progress, specifying the mapping of certificate

management messages onto CMS and providing the vehicle for producing

and RFC (or RFCs) that document agreed common formats for other
certificate management messages (i.e., messages other than certificate
request).

Time-Stamping and Notary Protocols

These are new, potential work items, discussed on a preliminary basis

in Munich.  Two presentations: Rob Zuccherato (Entrust) on time

stamping and notary functions, and Stuart Haber (Surety) on time

stamping. See slides for additional details.

Entrust- Time stamping service described here deals exclusively with

establishing existence of data (really a hash of data) at a point in

time.  Basic notary service for data demonstrates that a requester

posses data (not just a hash of the data) at a given time.  A

certificate notary service requires validation of a certificate chain

for the requester, including CRLs and ARLs.  There is also a fancy

data notarization service, encompassing data validity, and a combined

service of data possession and validity.  Some folks note that

validation of data (and certificates) is outside the scope of what

real world notaries do in the U.S. (but Latin Notaires do have broader

functions).

Surety- Stuart provided an overview of time stamping problem and

solution space, with a focus on the hash tree technology developed

(patented) and offered by Surety as a service.  The current Surety

service offers a 1 second granularity,

At least one WG member argued that the notary and time stamping

functions are not completely PKI-specific, and we should try to avoid

duplication of efforts like the PKIX/SPKI situation.  Another member

noted that there is a new I-D for time stamping via NTP, that raises

possible overlap concerns as well.  One possible outcome is a split of

time stamping vs. notary functions.  Certificate path validation, a

part of the described notary service, does make sense for PKIX,

consistent with X.509 validation procedures.

A straw poll during the second PKIX meeting showed a strong sentiment

that this WG amend its charter to include development of a standard for

time stamping, but there was not strong support for adding a work item

to develop notary functions (other than certificate path validation).
Thus an

extension of the WG charter will be proposed to the IESG in order to

address time stamping.

OCSP

Mike Myers provided a status review for this I-D, and responded to

comments that have appeared on the WG list over the last few weeks.  A

number of modifications will be made as a result of these comments

Mike described a schedule for revisions and (new) comments to bring

OCSP to WG last call in time for the next (LA) IETF meeting.  Included

in the revisions will be a better characterization of the contexts in

which OCSP are expected to operate, since that range of environments

has grown since OCSP was initially designed. To better accommodate this

diversity, a document structure was proposed that establishes a base
OCSP

document and syntax and one or more supplementary texts that build upon

the base syntax, as noted above.

</bigger></bigger></fontfamily>
</x-rich>

Date:         Wed, 21 Jan 1998 11:30:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] request for change of CertRepContent
To: [email-masked]
Status:

Hi Nada,

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  Thursday, January 08, 1998 5:22 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] request for change of CertRepContent
>
>I wonder if this is the right time to request a change in ipki3cmp format
>of the certification response message (being in the final call stage), but
>it seems to be lacking one very useful information: CRLs needed to verify
>certificates contained in the message.
>
>The inclusion of CRLs would enable certificate verification software to
>verify certificates without extra access to CRL repositories. The field can
>be made optional, so that CAs are not required to keep CRLs after
>publishing them, but in case they do keep CRLs this field may be used to
>make certificate validation process faster.
>
>The suggested format of CertRepContent is the following:
>
>  CertRepContent ::= SEQUENCE {
>      caPubs          [0] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
>  ->  crls            [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL,
>      -- CRLs corresponding to caPubs and certificates in response
>      response            SEQUENCE OF CertResponse
>  }
>
>Any comments?

Given that extra certificates can also be carried in the extraCerts
field of the PKIMessage structure, I'm not sure that CertRepContent is
the ideal place to carry the CRL (if it is carried).  My strong
preference would be to carry it in the generalInfo field of the
PKIHeader (recall that this is an optional sequence of InfoTypeAndValue
and that one of the InfoTypeAndValue contents defined in Section 3.3.18
is CurrentCRL).

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Wed, 21 Jan 1998 11:46:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

Hi Nada,

>----------
>From:  Nada Kapidzic Cicovic[SMTP:[email-masked]]
>Sent:  Monday, January 12, 1998 8:03 AM
>To:    [email-masked]
>Subject:       [IETF-PKIX] mandatory PasswordBasedMac
>
>I have one more comment on the completeness of ipki3cmp document.
>
>In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
>mandatory algorithm for PKI message protection. As far as I understand, the
>reason for specifying mandatory algorithms is for easier interoperability
>between complying implementations. However, PasswordBasedMac (as specified
>in section "3.1.3 PKI Message Protection") is parametrized with a
>one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
>but for MAC different alternatives are given.
>
>Shouldn't the specification of mandatory algorithms make clear which
>algorithms should be used in place of the mentioned two parameters in
>PasswordBasedMac? What would be the preferable alternatives?

Good point (thanks for noticing this)!  Yes, a particular OWF and MAC
should be mandated for interoperability purposes.

Unless there are any strong objections, I think the most sensible
choices would be SHA-1 for the OWF (since it's already mandated as part
of MSG_SIG_ALG) and Triple-DES-MAC [PKCS11] for the MAC (since 3-DES
(3-key, EDE, CBC) is already mandated for SYM_PENC_ALG and
PROT_SYM_ALG).

I will add this to Appendix B2.  Thanks again!

--------------------------------------------
Carlisle Adams
Entrust Technologies
[email-masked]
--------------------------------------------

Date:         Tue, 20 Jan 1998 15:33:09 +0000
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Neil Hopcroft <[email-masked]>
Subject:      [IETF-PKIX] PolicyConstraints Extension
To: [email-masked]
Status:

Looking at section 4.2.1.12 of PKIX Part 1 the ASN1 given appears not to
be complete, and, on further investigation there appears also to be a
problem with the coding in appendix A ("PolicyConstraints Syntax" not
"PolicyConstraintsSyntax"), also, should there be some kind of reference
to CertPolicySet?

I have attempted to find some archives for this list but the reference
to the FTP site on the IETF page is broken.

Thanks for you help

    Neil

Date:         Mon, 19 Jan 1998 10:46:00 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]
Status:

At 06:28 PM 1/15/98 -0500, Sharon Boeyen wrote:
>U.S. patent 5699431 is on the topic of crl distribution points and as
>such is related to PKIX.
>
>CRL distribution points are an optional item in the PKIX certificate and
>crl profiles and I don't believe there is, or should be, anything on
>distribution points which is mandated by any part of the PKIX
>specifications.

I think it is important for some competent, disinterested party to look
into this as soon as possible.  I have not seen the patent, but I know that
initial patents in a new field are usually worded quite broadly.  The
discussion in December on OCSP convinced me that, at least in the abstract,
OCSP and traditional CRLs may be viewed as endpoints on a spectrum of
configuration options for CRL distribution points.

I hope no one will interpret this comment to mean that I suspect bad faith
on the part of Entrust, quite the opposite.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Sun, 18 Jan 1998 10:03:00 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Jean Pawluk <[email-masked]>
Subject:      [IETF-PKIX] IETF-PKIX membership check
Comments: cc: [email-masked]
To: [email-masked]
Status:

 In the never-ending battle to get the IETF-PKIX list up to date,
 I am sending this message to check the current membership data.

 Is anyone forwarding to a remailer using an old membership list?

 I remove people from this list and verify that they are gone, yet
 we still are receiving mail messages here saying that mail cannot
 be delivered to the people who have been removed. Well that is no
 surprise, except they have not been on this list for at least 6
 weeks, so we are wondering if anyone was using remailers.

 Thanks

 Jeanne

Date:         Fri, 16 Jan 1998 22:29:20 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Comments:     Authenticated Sender is <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] DEREGULATION OF THE U.S ELECTRIC UTILITY
Comments: To: [email-masked]
To: [email-masked]
Status:

 DEREGULATION OF THE U.S ELECTRIC UTILITY
 INDUSTRY IS CREATING A $215 BILLION FINANCIAL
 OPPORTUNITY FOR YOU!

 Imagine Utility Savings of 20% - 40%!  now imagine
 being a marketer of those savings and earning a recurring
 monthly  commission on the Utility usage of consumers
 throughout the country...

 <<<<< Call 1-800-358-2754  for 24 hr, 1 min message >>>>>

 __________________________________________________

 Effective Jan '98, Electric Utility Monopolies will be
 dissolved on a State-by-State basis opening a $215
 "Billion Dollar" industry to free-market competition.

 We need independent "Electric Power Marketers" in
 all 50 States especially California and the Northeast.
 Build a leveraged, recurring income in as little as
 10-15 hours/week.  full training and support; minimal
 start-up; lucrative.

 New Ground- Floor Opportunity with established
 international networking giant.  Capitalize now on
 projected $10 Billion in annual revenue.

 People made millions with deregulation of the
 Telecommunications Industry.  The Electric Utility
 Industry will be three times the opportunity.

 <<< Call 1-800-358-2754  for 24 hr, 1 min message >>>

 (Please do not reply via e-mail.  Call our Voicemail and
 leave your name, telephone number and the best time
 to call and we will contact you as soon as possible)

 To be removed, call the above number and SPELL your
 email address stating you would like to be removed from
 future mailings.

Date:         Thu, 15 Jan 1998 17:55:15 -0800
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]
Status:

RFC 2026 (aka BCP 9) has all the detail on this. Section 10.3.1, step 6, says:

The contributor represents that he has disclosed the existence of
any proprietary or intellectual property rights in the
contribution that are reasonably and personally known to the
contributor.

Section 10.3.2 specifies what kind of patent information must be made
available before something can move onto standards track. If a company is
known to have an applicable patent but has not come up with a patent
statement, that company can hold up the process of getting the document on
standards track (nudge, nudge).

--Paul Hoffman, Director
--Internet Mail Consortium

Date:         Thu, 15 Jan 1998 18:28:39 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] Re patent 5699431 & PKIX
To: [email-masked]
Status:

U.S. patent 5699431 is on the topic of crl distribution points and as
such is related to PKIX.

CRL distribution points are an optional item in the PKIX certificate and
crl profiles and I don't believe there is, or should be, anything on
distribution points which is mandated by any part of the PKIX
specifications.

The patent was just issued in December and an intellectual property
statement for submission to standards bodies, as required, is nearly
complete. We do plan to make the technology covered by the patent
available  fairly and equitably. Apologies for the delay, however we
believed that the disclosure was required at issuance, not application
and that is why it is only being done now. Is there an IETF procedure or
requirements specification related to this process so we can ensure that
we follow it correctly?

------------------
Sharon Boeyen
Entrust Technologies

mailto:[email-masked]       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

Date:         Thu, 15 Jan 1998 11:26:47 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Whittaker <[email-masked]>
Subject:      Re: [IETF-PKIX] Looking for advise
To: [email-masked]
Status:

Good questions.  One quick note:  you don't need LDAP at all to build a
PKI.  That LDAP is used in many PKIs has to do with its desirable
characteristics as an access protocol into the directories that are used
to support those PKIs.  In those cases, LDAP is used only to obtain
verification materials, such as certificates and revocation lists;  it
is not a necessary part of verification itself.

>        I was looking to get some advice from the group to be sure I
>have everything I need. My company produces an edge router. From the
>reading I've done, it looks to me that I need to implement LDAP into our
>router and use it to verify the X.509 certificates received from remote
>peers.  Is this too simplistic a view, or is this really all I need? If
>so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm)

Do you need to use LDAP?  No, not necessarily, that depends on how your
system works....
>
>        A couple of other questions I have:
>        1. How does my router get a certificate for local peers?

This depends on the protocols used to establish connectios with local
peers.  If you are using GSSAPI, then the initial handshake transfers
the certificate; this is the case with SPKM-1 and SPKM-2.  Other
protocols (such as IPSEC?) have different methods.

> Can it be done dynamically via the add operation of a ModifyRequest?

I wouldn't think so.  I'm assuming that you are thinking of using LDAP
to talk to a directory, and not to talk to another router.  If so, then
you would use a base object search and request that the appropriate
attribute(s) (probably userCertificate) be returned.

If you were thinking of using the LDAP modify request to write the
certificate to the peer router, well, I wouldn't, because then the
router has to implement an LDAP server side as well as client, and
that's more work than you need.

If your context establishment protocol does not include certificate
exchange, you'll need to define a mechanism, one more efficient than
LDAP.

>        2. I am assuming the IP address and public key of a CA can be
>configured by the user. Is this correct?

Again, the answer is "that depends".  That depends on your PKI model and
trust architecture.  You may not have a CA at all (PGP trust model).  Or
your software may have been configured with the IP address of the CA,
and the CA gave your software a copy of its public key as part of
initialization of your PKI identity (Entrust model, one possible IPKI
model).  In the latter case, if the peer router was certified by your
CA, and your context establishment protocol provided for certificate
exchange, then you'd only need a directory access protocol to obtain the
revocation lists published by your CA, and then only if you used
revocation lists.

>        3. Are there public CAs available for testing purposes?

Various groups, too numerous to mention, have established
auto-responders and other infrastructure elements in support of testing
their specifications.  If you want to obtain certificates, there are
many sources, some of which were recently mentioned in cert-talk:

        http://www.entrust.com/webca/index.htm
        http://www.darmstadt.gmd.de/ice-tel
        http://www.secude.com/trustfactory/
        http://www.verisign.com/

To subscribe to cert-talk, see the attached message with subject
"Announcing cert-talk".

Since you are doing router work, I assume your interest is IPSEC.  You
might try contacting some IPSEC people.  Their mailing list is at

>        4. Will there be many changes between LDAPv2 and LDAPv3?

Many changes.  LDAPv3 does not mandate LDAPv2 support, and there isn't
backwards compatibility.

Your need for LDAPv3 vs LDAPv2 depends on what you are trying to do.
Note that the PKIX group has created a profile for using LDAPv2 for
repository (directory) access in an IPKI environment.  An LDAPv3 profile
will be forthcoming.

In either case, you would need to become conversant with both protocols,
but first you need to know why and whether you need LDAP at all.

>        5. Is there a workshop for X.509 compliant equipment to test for
>interoperability? (For example, There is an interoperability workshop for
>the PPP related protocols)

See the answer to question 3.

At the risk of being accused of advertising, check out the Entrust web
site for information on the Entrust/IPSEC Negotiator Toolkit.  It may
have some of the capabilities you desire.

pww

>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
>System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3401
>
>

From: "Thane E. Plambeck" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Announcing the cert-talk X.509 mailing list
Date: Wed, 10 Dec 1997 12:49:07 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

                          Announcing

                          cert-talk

            X.509 Digital Certificate Discussion List

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CHARTER:

      The cert-talk mailing list is a public, unmoderated forum
devoted to practical technical issues surrounding the use of X.509
certificates in public-key cryptography applications.

SUBJECT MATTER:

Topics of interest on cert-talk include, but are not limited to:

      * Practical problems and tools related to certificate
        manipulation:

        Import and export of certificates into applications
        Data extraction from certificates
        Certificate extension handling
        Compatibility of certificates across applications
        Revocation schemes
        Certificate storage schemes and APIs
        Distinguished name manipulation
        Certificate profiles and trust attributes
        Chain formation
        Signing and verification

      * Use of (and problems with) X.509 certificates with other
        public key technologies and networking standards such as:

        Secure Sockets Layer (SSL) and IETF TLS
        S/MIME secure electronic mail
        PKCS consortium standards
        SET (Secure Electronic Transactions)
        SKIP
        LDAP

HOW DO I SUBSCRIBE TO CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, send mail to the email address

 [email-masked]

    with the body of the message containing the single word SUBSCRIBE
    You need not put any text in the subject of your message.

    Please do not send requests to the cert-talk list itself.

ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK?

    Any mail addressed to <[email-masked]> will be sent
    to all members of the cert-talk mailing list.

HOW DO I UNSUBSCRIBE FROM CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, to remove your name from the cert-talk list send
    mail to the address

        [email-masked]

    with the message body being the single word UNSUBSCRIBE. You need
    not put any text in the body of your message.

    Please do not send requests to the cert-talk list itself.

FOR MORE INFORMATION:

              http://mail.structuredarts.com/cert-talk/

MAINTAINER:

              Structured Arts Computing Corporation
              20111 Stevens Creek Blvd, Suite 145
              Cupertino, California 95014-2345

              http://www.structuredarts.com/

              [email-masked]

Date:         Thu, 15 Jan 1998 11:29:26 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Peter Whittaker <[email-masked]>
Subject:      Re: [IETF-PKIX] Looking for advise
To: [email-masked]
Status:

>
>Sorry, I forgot the IPSEC ML address.

>Good questions.  One quick note:  you don't need LDAP at all to build a PKI.
>That LDAP is used in many PKIs has to do with its desirable characteristics
>as an access protocol into the directories that are used to support those
>PKIs.  In those cases, LDAP is used only to obtain verification materials,
>such as certificates and revocation lists;  it is not a necessary part of
>verification itself.
>
>        I was looking to get some advice from the group to be sure I
>have everything I need. My company produces an edge router. From the
>reading I've done, it looks to me that I need to implement LDAP into our
>router and use it to verify the X.509 certificates received from remote
>peers.  Is this too simplistic a view, or is this really all I need? If
>so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm)
>
>Do you need to use LDAP?  No, not necessarily, that depends on how your
>system works....
>
>        A couple of other questions I have:
>        1. How does my router get a certificate for local peers?
>
>This depends on the protocols used to establish connectios with local peers.
>If you are using GSSAPI, then the initial handshake transfers the
>certificate; this is the case with SPKM-1 and SPKM-2.  Other protocols (such
>as IPSEC?) have different methods.
>
> Can it be done dynamically via the add operation of a ModifyRequest?
>
>I wouldn't think so.  I'm assuming that you are thinking of using LDAP to
>talk to a directory, and not to talk to another router.  If so, then you
>would use a base object search and request that the appropriate attribute(s)
>(probably userCertificate) be returned.
>
>If you were thinking of using the LDAP modify request to write the
>certificate to the peer router, well, I wouldn't, because then the router has
>to implement an LDAP server side as well as client, and that's more work than
>you need.
>
>If your context establishment protocol does not include certificate exchange,
>you'll need to define a mechanism, one more efficient than LDAP.
>
>        2. I am assuming the IP address and public key of a CA can be
>configured by the user. Is this correct?
>
>Again, the answer is "that depends".  That depends on your PKI model and
>trust architecture.  You may not have a CA at all (PGP trust model).  Or your
>software may have been configured with the IP address of the CA, and the CA
>gave your software a copy of its public key as part of initialization of your
>PKI identity (Entrust model, one possible IPKI model).  In the latter case,
>if the peer router was certified by your CA, and your context establishment
>protocol provided for certificate exchange, then you'd only need a directory
>access protocol to obtain the revocation lists published by your CA, and then
>only if you used revocation lists.
>
>        3. Are there public CAs available for testing purposes?
>
>Various groups, too numerous to mention, have established auto-responders and
>other infrastructure elements in support of testing their specifications.  If
>you want to obtain certificates, there are many sources, some of which were
>recently mentioned in cert-talk:
>
>       http://www.entrust.com/webca/index.htm
>       http://www.darmstadt.gmd.de/ice-tel
>       http://www.secude.com/trustfactory/
>       http://www.verisign.com/
>
>To subscribe to cert-talk, see the attached message with subject "Announcing
>cert-talk".
>
>Since you are doing router work, I assume your interest is IPSEC.  You might
>try contacting some IPSEC people.  Their mailing list is at
>mailto:[email-masked]
>
>        4. Will there be many changes between LDAPv2 and LDAPv3?
>
>Many changes.  LDAPv3 does not mandate LDAPv2 support, and there isn't
>backwards compatibility.
>
>Your need for LDAPv3 vs LDAPv2 depends on what you are trying to do.  Note
>that the PKIX group has created a profile for using LDAPv2 for repository
>(directory) access in an IPKI environment.  An LDAPv3 profile will be
>forthcoming.
>
>In either case, you would need to become conversant with both protocols, but
>first you need to know why and whether you need LDAP at all.
>
>        5. Is there a workshop for X.509 compliant equipment to test for
>interoperability? (For example, There is an interoperability workshop for
>the PPP related protocols)
>
>See the answer to question 3.
>
>At the risk of being accused of advertising, check out the Entrust web site
>for information on the Entrust/IPSEC Negotiator Toolkit.  It may have some of
>the capabilities you desire.
>
>pww
>
>
>
>Peter Whittaker         Entrust Key Validation Sequence:  7ORS-NGND-P6ZX
>System Architect, SI    mailto:[email-masked]    Phone: +1 613 247 3485
>Entrust Technologies    http://www.entrust.com      Fax: +1 613 247 3401
>
>
>

From: "Thane E. Plambeck" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Announcing the cert-talk X.509 mailing list
Date: Wed, 10 Dec 1997 12:49:07 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

                          Announcing

                          cert-talk

            X.509 Digital Certificate Discussion List

 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

CHARTER:

      The cert-talk mailing list is a public, unmoderated forum
devoted to practical technical issues surrounding the use of X.509
certificates in public-key cryptography applications.

SUBJECT MATTER:

Topics of interest on cert-talk include, but are not limited to:

      * Practical problems and tools related to certificate
        manipulation:

        Import and export of certificates into applications
        Data extraction from certificates
        Certificate extension handling
        Compatibility of certificates across applications
        Revocation schemes
        Certificate storage schemes and APIs
        Distinguished name manipulation
        Certificate profiles and trust attributes
        Chain formation
        Signing and verification

      * Use of (and problems with) X.509 certificates with other
        public key technologies and networking standards such as:

        Secure Sockets Layer (SSL) and IETF TLS
        S/MIME secure electronic mail
        PKCS consortium standards
        SET (Secure Electronic Transactions)
        SKIP
        LDAP

HOW DO I SUBSCRIBE TO CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, send mail to the email address

 [email-masked]

    with the body of the message containing the single word SUBSCRIBE
    You need not put any text in the subject of your message.

    Please do not send requests to the cert-talk list itself.

ONCE I AM SUBSCRIBED, HOW TO I SEND MAIL TO CERT-TALK?

    Any mail addressed to <[email-masked]> will be sent
    to all members of the cert-talk mailing list.

HOW DO I UNSUBSCRIBE FROM CERT-TALK?

    The easiest method is to visit the URL

 http://mail.structuredarts.com/cert-talk/

    Alternatively, to remove your name from the cert-talk list send
    mail to the address

        [email-masked]

    with the message body being the single word UNSUBSCRIBE. You need
    not put any text in the body of your message.

    Please do not send requests to the cert-talk list itself.

FOR MORE INFORMATION:

              http://mail.structuredarts.com/cert-talk/

MAINTAINER:

              Structured Arts Computing Corporation
              20111 Stevens Creek Blvd, Suite 145
              Cupertino, California 95014-2345

              http://www.structuredarts.com/

              [email-masked]

Date:         Thu, 15 Jan 1998 10:41:41 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] Looking for advise
To: [email-masked]
Status:

        Folks,

        Thank you to everyone who has given me pointers on reading
material to get started. It has proven very helpful.

        I was looking to get some advice from the group to be sure I
have everything I need. My company produces an edge router. From the
reading I've done, it looks to me that I need to implement LDAP into our
router and use it to verify the X.509 certificates received from remote
peers.  Is this too simplistic a view, or is this really all I need? If
so, do I use RFC1778 or 1777? (I think it's 1778 but want to confirm)

        A couple of other questions I have:
        1. How does my router get a certificate for local peers? Can it
be done dynamically via the add operation of a ModifyRequest?
        2. I am assuming the IP address and public key of a CA can be
configured by the user. Is this correct?
        3. Are there public CAs available for testing purposes?
        4. Will there be many changes between LDAPv2 and LDAPv3?
        5. Is there a workshop for X.509 compliant equipment to test for
interoperability? (For example, There is an interoperability workshop for
the PPP related protocols)

        Thanks in advance for the help!

        - Gina
--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Date:         Wed, 14 Jan 1998 00:09:20 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

Steve, thanks for the clarification.

Unfortunately, I was unaware of the Novell patent that might or might not be
involved in this particular instance, and so I can't even answer from a
technical perspective whether or not the cited Novell patent might apply to
the proposed standard, and if so how or to what degree.

Until we can answer that question, of course, it is rather premature to
discuss R&D or educational use, much less licensing terms.  On the other
hand, discriminatory and/or onerous terms are probably not the ideal way to
win friends in this industry, so it is a pretty good bet that we wouldn't do
that.  Of course, I'm not an attorney, much less an intellectual property
attorney, nor am I authorized to commit the company, etc., etc.

So the answer, unfortunately, is that I will have to get back to you if you
and/or the IESG feels that this is a substantive issue.

Bob

>>> Stephen Kent <[email-masked]> 01/13/98 09:29AM >>>
Bob,

        It is the IESG's position hat standards shouldm whenever possible,
avoid the use of encumbered technology.  So, for example, there was a big
deal getting RSA to agree to allow R&D and educational use of the algorithm
in PEM, long ago.  More recently, the IESG insistend that the TLS WG make
Diffie-Hellman and DSA the default algorithms for SSL, specifically to
avoid RSA patent problems.  So, the answers to your first question is that
the IESG does want WGs to avoid use of patented technology if at all
possible.  If patented technology is incorporated into an IETF standard,
then there must be a formal statement from the patent holders about
non-discrimnatory licensing and non-onerous fees, or the IESG will reject
the standard.  Thus it is important that these issues be resolved prior to
IESG submission.

        With regard to your second question, no, it is not incumbent on
companies to review all IETF I-Ds and advise the IESG of possible patent
overlaps.  However, it is expected that WG members participating in the
development of a standards, and who are aware of patents held by their
company (or themeslves), will make the WG aware of such intellectual
property issues in the course of standards development.

        At this point I am seriously considering asking the authors to
delete portions of the relevent documents for which there may be patent
problems, so that the documents can proceed to IESG approval.

Steve

Date:         Tue, 13 Jan 1998 18:38:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Jeffrey I. Schiller" <[email-masked]>
Organization: Massachusetts Institute of Technology
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Phillip M Hallam-Baker wrote:
> >Does the IESG expect some company (Novell, Nortel, etc.) to take on the
> >burden of examining some protocol and issuing a statement that said
> protocol
> >does not infringe on their patent?
>
> The IESG cannot make such a requirement, but it does very much frown
> upon companies who are aware of pending patent claims failing to
> report them while being actively involved in the development of a
> specification.

Indeed it is poor form for an individual to make contributions to a
working group and after the group has adopted those recommendations,
announce that the proposal is encumbered by that individual or the
individuals company (and the individual was aware of the encumbrance at
the time of suggestion). In other words, when you make a contribution to
a WG, it is exactly that, a *contribution*.

Some believe that because the patent application process is secret, that
information about pending patents does not have to be revealed. This
just isn't so. Although the patent process is secret, it is completely
reasonable for the IETF to say "If you want to contribute a technology
to a working group effort, then you must disclosure your interest." If
you don't wish to disclose your interest, you don't have to make the
suggestion!

As for unilateral statements. I do not make decisions in a vacuum. I
poled people individually at the Munich meeting to get the sense of the
community about encumbered vs. unencumbered technologies (where a viable
alternative was available). We then asked the plenary. The consensus was
clear, the IETF favors unencumbered technologies. This is not an
arbitrary decision of the IESG!

                         -Jeff

>
> Of course there are many reasons for filing a patent besides wanting to
> exercise it. Many patents are filed in the US simply to stop the PTO
> issuing a patent to some smart Alex ten years later.
>
> >I am reasonably certain that the IESG doesn't get involved in negotiating
> >license agreements, so I would assume that they wouldn't ask for a company
> >to waive its patent rights.
>
> Bad assumption.
>
> They tend to simply insist that any patent encumbered technology
> be deleted from the draft prior to approving it. In IETF terms this is
> equivalent to 'Go straight to editing session, do not pass Go, do not
> collect $200'.
>
> It is not unusual for the alternatives to be offered in the form 'delete
> this from the spec or undertake to not enforce the patent on
> any party excepting a party which attempts to prevent you from
> using the patented property'.
>
> This is 'negotiation' of a form but a rather one sided one in that it
> consists of a unilateral ultimatum. Jeff Schiller, the security area
> director recently issued a series of similar ultimatums to the PGP
> and S/MIME groups where there were unsolved questions of
> intellectual property in the trademark area.
>
> This is why I raised the issue on the list. Until it is resolved we
> cannot get any of the drafts affected issued as RFCs.
>
>             Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 29 (????/----) (0001E0CB)

Date:         Tue, 13 Jan 1998 17:13:52 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ronald Ogle <[email-masked]>
Organization: Operational Research Consultants Inc.
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

David P. Kemp wrote:

> > From: Bob Jueneman <[email-masked]>
> >
> > If you recall, you [Warwick] were the one who convinced me of the elegance of the
> > policy OID constraint approach to certificate chaining, pointing out that it
> > allowed the user himself, (or his IT organization) to create a certificate
> > which effectively serves as his own local (unpublished) TLCA and
> > cross-certifies other CAs, without requiring access to some kind of a local
> > database of trusted CAs to validate each certificate.  A suitable trusted
> > smart card, a la Fortessa, containing a trusted public key or self-signed
> > certifcate, could feasibly implement the relying party's trust policy
> > without requiring a trusted operating system host.
> .......

> We have been grappling with the problem of reconciling three PKI models
> into a coherent concept of operations for a PKI to serve Federal Government
> users:
>  * single-rooted heirarchy (DMS / MISSI v1),
>  * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI v2)
>  * single-level certification with each user configuring a list of
>     "trusted" CAs (the current web browser model)
>

Wouldn't there also be a case for inter-domain certification  (point 2) at other
subordinate "chained" CA levels and not just at the root level?  For example, if you
have a "Federal Root CA" that signs all other Government CAs, in this case the DoD CA,
wouldn't you want the DoD CA to be able to inter-domain certify with other CA Roots
instead of requiring the inter-domain certification to take place at the Federal Root
CA.

Just my opinion.
Ron Ogle

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ronald Ogle
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 4 (TEXT/R*ch) (0001E0CA)

Date:         Tue, 13 Jan 1998 14:07:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip M Hallam-Baker <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: Robert Jueneman <[email-masked]>
To: [email-masked]
Status:

>I'm not entirely sure what you are asking, perhaps because I am rather
>ignorant of what the IESG's position is vis a vis patents and standards.
>
>Does the IESG insist on standards avoiding any existing patents?  In that
>case, what do they do about RSA, etc?

In general the IESG is very reluctant to approave any standard that does not
meet their deffinition of 'open'. In particular they will in general insist
that a
specification be implementable using patent free technology wherever
possible,
PEM was a rare case in which they considered the RSA/Diffie Helleman
patent essential.

In any case whenever a protocol is encumbered in some way by a protocol
they insist on an intellectual property statement and an undertaking to
license the patent according to non discriminatory terms.

>Does the IESG expect some company (Novell, Nortel, etc.) to take on the
>burden of examining some protocol and issuing a statement that said
protocol
>does not infringe on their patent?

The IESG cannot make such a requirement, but it does very much frown
upon companies who are aware of pending patent claims failing to
report them while being actively involved in the development of a
specification.

Of course there are many reasons for filing a patent besides wanting to
exercise it. Many patents are filed in the US simply to stop the PTO
issuing a patent to some smart Alex ten years later.

>I am reasonably certain that the IESG doesn't get involved in negotiating
>license agreements, so I would assume that they wouldn't ask for a company
>to waive its patent rights.

Bad assumption.

They tend to simply insist that any patent encumbered technology
be deleted from the draft prior to approving it. In IETF terms this is
equivalent to 'Go straight to editing session, do not pass Go, do not
collect $200'.

It is not unusual for the alternatives to be offered in the form 'delete
this from the spec or undertake to not enforce the patent on
any party excepting a party which attempts to prevent you from
using the patented property'.

This is 'negotiation' of a form but a rather one sided one in that it
consists of a unilateral ultimatum. Jeff Schiller, the security area
director recently issued a series of similar ultimatums to the PGP
and S/MIME groups where there were unsolved questions of
intellectual property in the trademark area.

This is why I raised the issue on the list. Until it is resolved we
cannot get any of the drafts affected issued as RFCs.

            Phill

Date:         Tue, 13 Jan 1998 12:34:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Hal Lockhart <[email-masked]>
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
To: [email-masked]
Status:

At 06:33 PM 1/12/98 -0400, Ronald Ogle wrote:
>Well, I don't know about that.  You may be familiar with Caller ID on the
>telephone.  With Caller ID, you can send the caller to a message stating that
>you will not answer the phone unless he/she publishes his/her phone number to
>your Caller ID service.  Abstract this idea out to e-mail.  If the e-mail
sender
>does not sign the e-mail, then an e-mail is sent back stating that the
recipient
>will not except unsigned e-mail.  Also, you could have a filter based on the
>signature that would reject or at least but the e-mail in a location that was
>unobtrusive.  So just like an unwanted phone call, an unwanted e-mail can
now go
>into the perverbial bit bucket without human intervention.

I am afraid I must agree with Perry. I don't think this approach will work
for long or work for most people.  Basically, you will have to either list
who you will receive from (inclusion), or who you will NOT receive from
(exclusion).  In either case, you will soon be administering large
unmanagable lists.

Further, inclusion will exclude mail you really want.  For example, I have
frequently been contacted by old friends and acquaintences who saw my
posting somewhere, or got my address from a mutual friend.  Or consider the
common case of starting a side discussion with another subscriber to a
mailing list.

Exclusion just puts you in the same old game of continous catch up with the
spammers.  As Perry points out, there is no reason to believe that they
will not be able to obtain digital identities (certs) for their many and
varied pseudonyms with the same level of assurance as your friends will get
for their real identities.

I am increasingly becoming convinced that any successful strategy against
spam will have to be economic in nature.  Other steps may temporarily slow
them down, but are at best stopgap.

>Perry E. Metzger wrote:
>
>> Andrew Csinger writes:
>> > Although somewhat off-topic, I think it's important to note in passing
>> > that
>> >
>> > PKI is ultimately the <bold><italic>solution</italic></bold> to the
>> > problem of SPAM,
>>
>> Not likely. Just because you can then verify that one of
>> Spamford Wallace's 7000 aliases sent the mail message doesn't mean it
>> does you any good to know where it came from.

Hal

=================================================================
Harold W. Lockhart Jr.            Platinum Solutions Inc.
Chief Technical Architect         8 New England Executive Park
Email: [email-masked]            Burlington, MA 01803 USA
Voice: (781)273-6406              Fax: (781)229-2969
=================================================================

Date:         Tue, 13 Jan 1998 11:29:03 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Bob,

        It is the IESG's position hat standards shouldm whenever possible,
avoid the use of encumbered technology.  So, for example, there was a big
deal getting RSA to agree to allow R&D and educational use of the algorithm
in PEM, long ago.  More recently, the IESG insistend that the TLS WG make
Diffie-Hellman and DSA the default algorithms for SSL, specifically to
avoid RSA patent problems.  So, the answers to your first question is that
the IESG does want WGs to avoid use of patented technology if at all
possible.  If patented technology is incorporated into an IETF standard,
then there must be a formal statement from the patent holders about
non-discrimnatory licensing and non-onerous fees, or the IESG will reject
the standard.  Thus it is important that these issues be resolved prior to
IESG submission.

        With regard to your second question, no, it is not incumbent on
companies to review all IETF I-Ds and advise the IESG of possible patent
overlaps.  However, it is expected that WG members participating in the
development of a standards, and who are aware of patents held by their
company (or themeslves), will make the WG aware of such intellectual
property issues in the course of standards development.

        At this point I am seriously considering asking the authors to
delete portions of the relevent documents for which there may be patent
problems, so that the documents can proceed to IESG approval.

Steve

Date:         Mon, 12 Jan 1998 18:33:57 -0400
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Ronald Ogle <[email-masked]>
Organization: Operational Research Consultants Inc.
Subject:      Re: [IETF-PKIX] Certificate Directories and Spam
Comments: To: [email-masked]
To: [email-masked]
Status:

Well, I don't know about that.  You may be familiar with Caller ID on the
telephone.  With Caller ID, you can send the caller to a message stating that
you will not answer the phone unless he/she publishes his/her phone number to
your Caller ID service.  Abstract this idea out to e-mail.  If the e-mail sender
does not sign the e-mail, then an e-mail is sent back stating that the recipient
will not except unsigned e-mail.  Also, you could have a filter based on the
signature that would reject or at least but the e-mail in a location that was
unobtrusive.  So just like an unwanted phone call, an unwanted e-mail can now go
into the perverbial bit bucket without human intervention.

Perry E. Metzger wrote:

> Andrew Csinger writes:
> > Although somewhat off-topic, I think it's important to note in passing
> > that
> >
> > PKI is ultimately the <bold><italic>solution</italic></bold> to the
> > problem of SPAM,
>
> Not likely. Just because you can then verify that one of
> Spamford Wallace's 7000 aliases sent the mail message doesn't mean it
> does you any good to know where it came from.
>
> Perry

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ronald Ogle
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 3 (TEXT/R*ch) (0001DEBE)

Date:         Mon, 12 Jan 1998 11:52:32 -0500
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      [IETF-PKIX] I-D ACTION:draft-ietf-pkix-ipki2opp-06.txt
Comments: To: [email-masked]
To: [email-masked]
Status:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.  This draft is a work item of the Public-Key
Infrastructure (X.509) Working Group of the IETF.

        Title           : Internet X.509 Public Key Infrastructure Operational
                          Protocols - LDAPv2
        Author(s)       : T. Howes, S. Boeyen, P. Richard
        Filename        : draft-ietf-pkix-ipki2opp-06.txt
        Pages           : 12
        Date            : 09-Jan-98

     The protocol described in this document is designed to satisfy some
     of  the  operational  requirements within the Internet X.509 Public
     Key Infrastructure (IPKI).  Specifically, this  document  addresses
     requirements  to  provide access to Public Key Infrastructure (PKI)
     repositories for the purposes of  retrieving  PKI  information  and
     managing  that  same  information.  The mechanism described in this
     document is based on  the  Lightweight  Directory  Access  Protocol
     (LDAP) v2, defined in RFC 1777, defining a profile of that protocol
     for use within the IPKI and updates encodings for certificates  and
     revocation  lists  from  RFC 1778. Additional mechanisms addressing
     PKIX operational requirements are specified in separate documents.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-pkix-ipki2opp-06.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-pkix-ipki2opp-06.txt

Internet-Drafts directories are located at:

        Africa: ftp.is.co.za

        Europe: ftp.nordu.net
                ftp.nis.garr.it

        Pacific Rim: munnari.oz.au

        US East Coast: ds.internic.net

        US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:      [email-masked].  In the body type:
        "FILE /internet-drafts/draft-ietf-pkix-ipki2opp-06.txt".

NOTE:   The mail server at ds.internic.net can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Content-Type: text/plain
Content-ID:     <[email-masked]>

[This attachment must be fetched by mail.
Open the stationery below and send the resulting
message to get the attachment.]
Attachment converted: Lutefisk:Get [IETF-PKIX] I-D ACTION-dr 1 (EuSn/CSOm) (0001DEA9)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-ipki2opp-06.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

[This attachment must be fetched by ftp.
ÊOpen the document below to ask your ftp client to fetch it.]
Attachment converted: Lutefisk:Get draft-ietf-pkix-ipki2opp-06 (AURL/Arch) (0001DEAA)
Content-Type: text/plain
Content-ID:     <[email-masked]>

Date:         Mon, 12 Jan 1998 14:03:06 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      [IETF-PKIX] mandatory PasswordBasedMac
To: [email-masked]
Status:

I have one more comment on the completeness of ipki3cmp document.

In section "B2. Algorithm Use Profile", PasswordBasedMac is specified as
mandatory algorithm for PKI message protection. As far as I understand, the
reason for specifying mandatory algorithms is for easier interoperability
between complying implementations. However, PasswordBasedMac (as specified
in section "3.1.3 PKI Message Protection") is parametrized with a
one-way-hash function and a MAC. For one-way-hash, SHA-1 is recommended,
but for MAC different alternatives are given.

Shouldn't the specification of mandatory algorithms make clear which
algorithms should be used in place of the mentioned two parameters in
PasswordBasedMac? What would be the preferable alternatives?

Regards,

Nada
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Mon, 12 Jan 1998 00:13:33 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

I'm not entirely sure what you are asking, perhaps because I am rather
ignorant of what the IESG's position is vis a vis patents and standards.

Does the IESG insist on standards avoiding any existing patents?  In that
case, what do they do about RSA, etc?

Does the IESG expect some company (Novell, Nortel, etc.) to take on the
burden of examining some protocol and issuing a statement that said protocol
does not infringe on their patent?

I am reasonably certain that the IESG doesn't get involved in negotiating
license agreements, so I would assume that they wouldn't ask for a company
to waive its patent rights.

Maybe we ought to hear from the Area Director on this issue.

Bob

>Bob Jueneman wrote:
>
>[details of Silvios patents deleted]
>
>Since you are Novell Bob, perhaps you could find out about the intention
>and interpretation of the Novell patent?
>
>http://patent.womplex.ibm.com/details?patent_number=5687235
>5687235 : Certificate revocation performance optimization
>
>INVENTORS:
>              Perlman; Radia J., Acton, MA
>              Reed; Edwards E., Lindon, UT
>              Carter; Tammy G., Pleasant Grove, UT
>ASSIGNEES:
>              Novell, Inc., Orem, UT
>ISSUED:
>              Nov. 11, 1997
>
>                                  FILED:
>                                       Oct. 26, 1995
>
>ABSTRACT:   The present invention is an improved certificate revocation
>process that improves the efficiency of an authentication exchange in a
>public key distributed network system. Specifically, the present
>invention includes a novel revocation service (RS) that, in response to
>a unique request from a server node, selects certain revoked
>certificates from a current CRL to include in its reply so as to consume
>minimal system bandwidth
>
>
>It would also be handy if someone from Entrust or Nortel could give some
>information about their intentions concerning their CRL distribution
>points patent.
>
>
>Needless to say this is all going to have to be sorted out before the
>IESG accepts the PKIX standards.

Date:         Sun, 11 Jan 1998 23:56:12 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Robert Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

>> From: Bob Jueneman <[email-masked]>
>>
>> If you recall, you [Warwick] were the one who convinced me of the
elegance of the
>> policy OID constraint approach to certificate chaining, pointing out that
it
>> allowed the user himself, (or his IT organization) to create a
certificate
>> which effectively serves as his own local (unpublished) TLCA and
>> cross-certifies other CAs, without requiring access to some kind of a
local
>> database of trusted CAs to validate each certificate.  A suitable trusted
>> smart card, a la Fortessa, containing a trusted public key or self-signed
>> certificate, could feasiblely implement the relying party's trust policy
>> without requiring a trusted operating system host.
>>
>> This way the RP has only his own public key to trust, and the IT
>> organization doesn't have to run around the country or the world
populating
>> new trusted TLCA keys into client software every time a new CA pops up or
a
>> key is replaced. They merely post new certificates on an untrusted
directory
>> or repository, to be downloaded as needed.
>
>
>I quite agree, and am surprised that this approach to PKI organization
>has not been more widely publicized, or documented (as an informational
>appendix or RFC, not as normative text) in PKIX.  Bob, this is the
>clearest statement I've seen yet of the advantages of the "domain
>administrator" (or "local TLCA") model - may I quote you?

In general, I assume that anything posted to a _public _ list such as this
is said on the record, and as such may be quoted without explicit
permission.  But thanks for the courtesy of asking.
>
>We have been grappling with the problem of reconciling three PKI models
>into a coherent concept of operations for a PKI to serve Federal Government
>users:
> * single-rooted hierarchy (DMS / MISSI v1),
> * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI
v2)
> * single-level certification with each user configuring a list of
>    "trusted" CAs (the current web browser model)
>
>The local-TLCA model, if supported by commercial product vendors, would
>satisfy the needs of individual users to choose who they trust (and
>also make trust decisions more explicit by requiring the user to issue
>a cert to each CA in the list, and allow finer granularity of control,
>if desired, by including name and policy constraints in the
>user-generated certs).
>
>It would also satisfy the needs of organizations to inject some
>assurance into the PKI management process, and allow control of some
>functions to be delegated to lower levels while retaining control over
>other functions (such as organizational messaging, high-value
>contracts, etc) at the organizational level.
>
>Dave Kemp

I think that I have described a further extension to this general paradigm,
certainly in person at a Federal PKI meeting and on some legal lists, but I
don't recall whether I discussed it on the PKIX list.  So let me elaborate
somewhat.

I am increasingly convinced that despite whatever benefits might accrue from
the official licensing of CAs a la the Utah Digital Signature Act, it is not
likely to extend or scale very well.  Although I currently live in Utah, I
would not claim that it was the hub of the universe with respect to
electronic commerce.  I therefore doubt that there will be a huge rush for
every CA in the world to sign up as a Utah-licensed CA.  The same is
probably true of Florida, Washington, Illinois, and the other states which
Utah-like legislation, much less the "minimalist" states such as California,
Massachusetts, etc.

What might happen, however, is that some of those states, some governmental
agencies, and perhaps some industry associations, might either formally or
informally publish a set of reasonable set of criteria for what constitutes
a reasonable set of operational practices for a CA.  (The ABA Information
Security committee -- the group that wrote the Digital Signature Guidelines
-- is presently addressing a set of Guidelines for CA accreditation that may
eventually form the basis for such an effort.)

Assuming that some reasonably small set of criteria are developed, _and_
assuming that those same organizations develop some form of auditing and/or
other on-going oversight is put into place, it is my hope that these
accrediting agencies can from the basis for an international PKI trust
infrastructure.  Although I am not an attorney, I believe that the
differences in the various legal systems throughout the world, together with
national sovereignty issues, are too great as to ever allow a prescriptive
set of standards to be put into place.

So instead of an international set of "thou-shalt"  laws or regulations
being passed, the basis for mutual trust will be much closer to the way that
a bond rating organization such as Standard and Poors operates.  In other
words, the accrediting agency will issue a non-liability bearing memorandum
of opinion about a CA's practices, and based on that opinion and the
recognition that the CA is at least a bona fide organization, individual
relying parties (or relying organizations) will decide for themselves
whether that CA's certificate form an adequate basis of trust for certain
classes of transactions, or not.

Now, how would this system operate in an individual-TLCA paradigm (to use
your terminology -- as good as any I've seen)?

Well, suppose I had three different types of transactions I might want to
decide whether to accept as a relying party.  Maybe one is a routine e-mail
attribution, not unlike what is presumably intended by those who use PGP to
sign their contributions.  They don't intend that their utterances be
interpreted as a legally binding contract, and I as a relying party don't
view that way either, except to make sure that someone isn't playing games
and impersonating someone else.

My second type of transaction might be intra- and intercorporate business
correspondence -- not formal purchase orders, bids, or other "EDI"
transactions -- just normal business correspondence that is routinely signed
to convey good faith in negotiations. Although not common, such
"transactions" have the potential to end up in court is there is ever a
serious disagreement about the intent of the parties.  another example of
the level of transaction might be to digitally sign a tax return, to file an
insurance claim, etc.

Finally, there is the really serious applications, e.g., for selling your
house, signing your will, or other big ticket items.  For businesses,
perhaps this level of transaction is the over-$100,000 (or maybe over $1
million) type of transaction.

Now, having analyzed my security/reliance requirements and reduced them down
to perhaps overly-simplistic essence, I might create three different
unpublished,, self-signed, TLCA certificates, each containing a unique
policy OID (unique to and known only by me).  I'll refer to those policies
as my Red, White, and Blue policies.

Now then, once I have reviewed the legal and technical aspects of say
VeriSign's Certificate Practice Statement in detail, I might conclude that
both their Class 1 and their Class 2 certificates satisfy my Red policy,
that their Class 3 certificate satisfies my White
policy, but that they don't yet have a class that would satisfy my Blue
category.

I could then cross certify VeriSign's certificates (unilaterally, without
necessarily contracting with VeriSign for this purpose), using policy
mapping plus a critical policy OID constraint to control which of VeriSign's
certificates I would accept.

Likewise, I might decide that Utah's licensed CAs would satisfy my Blue
criteria.

But going beyond the current status quo, sometime next year, Utah might
decide that the Washington State, Florida, MISSI, and German Government CA's
satisfy the criteria for a Utah licensed CA, and Utah might cross-certify
those other CAs, either unilaterally or bilaterally, again using policy
mapping.  Maybe they make up a series of policies, say Pearl, Ruby, and
Diamond.

And some other CA rating agency make up some other criteria, say
Classic/Green/Brass, Gold, and Platinum, etc., etc.

Assuming the various rating agencies invest the necessary legal and
technical effort into comparing the various policies and coming up with some
simplifying ratings, I would hope that I could eventually chain from my own
personal "Red" policy criteria to Utah's "Ruby" to MISSI's Gold policy, etc.

I may be asking a lot for the creation of these policy rating efforts, but I
think it is a lot more reasonable and feasible than having various CA's
actually undertake some level of liability for some other CAs actions, much
less some state agency or industry association.

In any case, assuming that these approximate correspondences can ultimately
be established, the use of an individual TLCA plus policy mapping and policy
constraints certainly appears to offer the necessary controls necessary to
implement a more or less automatic, lights-out approach to certificate
validation.  By switching contexts as to which self-signed TLCA certificate
is acceptable for a given type of transaction (perhaps based on the
transaction amount), all of the rest of the certificate validation process
should be capable of being completely automated and deterministic.

At least that is the challenge.  Now, I believe that what we ought to do is
hold up the detailed text to a critical examination along these lines, and
ask the nitty-gritty operational questions. For example, I haven't discussed
the role of policy parameters, and whether some form of mapping is needed
there.  How, for example, do we compare two reliance limit policy parameters
if one is in US dollars and the other is in French francs?

I'm sure there is more work to be done, but I think this is a good starting
point.

And by the way, I tend to believe that these kinds of examples _do_ belong
in the PKIX document. Too often, I believe, we tend to take out these kinds
of how-we-got-there steps, and only present the bare bones conclusions.  All
too often, that tends to make those who look at these issues later reinvent
the wheel, sometimes in a surprisingly different shape.

Bob

Date:         Fri, 9 Jan 1998 15:35:32 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

Bob Jueneman wrote:

[details of Silvios patents deleted]

Since you are Novell Bob, perhaps you could find out about the intention
and interpretation of the Novell patent?

http://patent.womplex.ibm.com/details?patent_number=5687235
5687235 : Certificate revocation performance optimization

INVENTORS:
              Perlman; Radia J., Acton, MA
              Reed; Edwards E., Lindon, UT
              Carter; Tammy G., Pleasant Grove, UT
ASSIGNEES:
              Novell, Inc., Orem, UT
ISSUED:
              Nov. 11, 1997

                                  FILED:
                                       Oct. 26, 1995

ABSTRACT:   The present invention is an improved certificate revocation
process that improves the efficiency of an authentication exchange in a
public key distributed network system. Specifically, the present
invention includes a novel revocation service (RS) that, in response to
a unique request from a server node, selects certain revoked
certificates from a current CRL to include in its reply so as to consume
minimal system bandwidth

It would also be handy if someone from Entrust or Nortel could give some
information about their intentions concerning their CRL distribution
points patent.

Needless to say this is all going to have to be sorted out before the
IESG accepts the PKIX standards.
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 28 (????/----) (0001DE9E)

Date:         Fri, 9 Jan 1998 15:26:06 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Management protocols and base64 encoding
To: [email-masked]
Status:

Tomas Gustavsson wrote:
>
> In draft-ieft-pkix-ipki3cmp-06.txt there is specified how messages should be
> transported over email and http. For http is says:
>
> Content-Type: application/pkixcmp
> <<the ASN.1 DER-encoded PKIX-CMP message>>
>
> while it is base64 encoded for email. I would like to allow base64 encoding
> also for http based transports. One reason for this is that with some windows
> based web servers we have had problems returning binary data undamaged from
> cgi programs. It is not very hard to make automatic detection if the received
> data is base64 encoded or not.

I really don't think that the spec should attempt to vary the HTTP
specification.
HTTP permits base64 encoding but does not require clients to be able to
interpret it. We designed HTTP to be 8-bit clean and have been extreemly
definite about keeping it that way.

If your server cannot provide an 8-bit clean communication with a plug
in
application that is a bug that is your responsibility. The purpose of
IETF
standards is to standardize communications over the network where it is
very
difficult to change infrastructure.

Mangling a spec to provide backwards compatibility with internal
infrastructure that can be upgraded by the person with the problem has
never been accepted as important.

It appears that your problem is using CGI which was developed as a
solution for UNIX based systems on a Windows platform. The only
reason CGI was invented was because UNIX support for shared
libraries was incomplete at the time.

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 27 (????/----) (0001DE9D)

Date:         Fri, 9 Jan 1998 10:33:11 -0800
Reply-To: [email-masked]
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Walter Enos <[email-masked]>
Subject:      [IETF-PKIX] (pure) Java implementations of PKIX?
To: [email-masked]
Status:

Are any Java implementations available today,
or are implementations planned to be available
once the standard is finalized?

I haven't seen any vendor announcements yet-
can anyone shed some light on this for me?
Thanks!
Walter
__________________
Walter Enos
904 Los Robles Avenue
Palo Alto, CA 94306
email:  [email-masked]

Date:         Fri, 9 Jan 1998 10:35:28 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

> From: Bob Jueneman <[email-masked]>
>
> If you recall, you [Warwick] were the one who convinced me of the elegance of the
> policy OID constraint approach to certificate chaining, pointing out that it
> allowed the user himself, (or his IT organization) to create a certificate
> which effectively serves as his own local (unpublished) TLCA and
> cross-certifies other CAs, without requiring access to some kind of a local
> database of trusted CAs to validate each certificate.  A suitable trusted
> smart card, a la Fortessa, containing a trusted public key or self-signed
> certifcate, could feasibly implement the relying party's trust policy
> without requiring a trusted operating system host.
>
> This way the RP has only his own public key to trust, and the IT
> organization doesn't have to run around the country or the world populating
> new trusted TLCA keys into client software every time a new CA pops up or a
> key is replaced. They merely post new certificates on an untrusted directory
> or repository, to be downloaded as needed.

I quite agree, and am surprised that this approach to PKI organization
has not been more widely publicized, or documented (as an informational
appendix or RFC, not as normative text) in PKIX.  Bob, this is the
clearest statement I've seen yet of the advantages of the "domain
administrator" (or "local TLCA") model - may I quote you?

We have been grappling with the problem of reconciling three PKI models
into a coherent concept of operations for a PKI to serve Federal Government
users:
 * single-rooted heirarchy (DMS / MISSI v1),
 * heirarchies interdomain-certified at the root level (IPsec/ANX, MISSI v2)
 * single-level certification with each user configuring a list of
    "trusted" CAs (the current web browser model)

The local-TLCA model, if supported by commercial product vendors, would
satisfy the needs of individual users to choose who they trust (and
also make trust decisions more explicit by requiring the user to issue
a cert to each CA in the list, and allow finer granularity of control,
if desired, by including name and policy constraints in the
user-generated certs).

It would also satisfy the needs of organizations to inject some
assurance into the PKI management process, and allow control of some
functions to be delegated to lower levels while retaining control over
other functions (such as organizational messaging, high-value
contracts, etc) at the organizational level.

Dave Kemp

Date:         Thu, 8 Jan 1998 14:51:37 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tomas Gustavsson <[email-masked]>
Subject:      [IETF-PKIX] Management protocols and base64 encoding
To: [email-masked]
Status:

In draft-ieft-pkix-ipki3cmp-06.txt there is specified how messages should be
transported over email and http. For http is says:

Content-Type: application/pkixcmp
<<the ASN.1 DER-encoded PKIX-CMP message>>

while it is base64 encoded for email. I would like to allow base64 encoding
also for http based transports. One reason for this is that with some windows
based web servers we have had problems returning binary data undamaged from
cgi programs. It is not very hard to make automatic detection if the received
data is base64 encoded or not.

Anyone else has any feelings about this?

Regards,
Tomas Gustavsson
Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corp.)
Email: [email-masked]
Tel: +46 8 477 7740
Fax: +46 8 477 7731

Date:         Thu, 8 Jan 1998 11:22:19 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Nada Kapidzic Cicovic <[email-masked]>
Subject:      [IETF-PKIX] request for change of CertRepContent
To: [email-masked]
Status:

I wonder if this is the right time to request a change in ipki3cmp format
of the certification response message (being in the final call stage), but
it seems to be lacking one very useful information: CRLs needed to verify
certificates contained in the message.

The inclusion of CRLs would enable certificate verification software to
verify certificates without extra access to CRL repositories. The field can
be made optional, so that CAs are not required to keep CRLs after
publishing them, but in case they do keep CRLs this field may be used to
make certificate validation process faster.

The suggested format of CertRepContent is the following:

  CertRepContent ::= SEQUENCE {
      caPubs          [0] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
  ->  crls            [1] SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL,
      -- CRLs corresponding to caPubs and certificates in response
      response            SEQUENCE OF CertResponse
  }

Any comments?

Regards,

Nada
______________________________________________________________

Nada Kapidzic Cicovic
COST - Computer Security Technologies CST AB
(subsidiary of Entegrity Solutions Corporation)
office:   + 46 (0)8 477 77 37
mobile:   + 46 (0)70 495 09 03
fax:      + 46 (0)8 477 77 31
e-mail:   [email-masked] or [email-masked]
address:  Finlandsgatan 60, 164 74 Kista, Sweden

Date:         Wed, 7 Jan 1998 10:28:18 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
Comments: To: [email-masked]
To: [email-masked]
Status:

>>> Tomaz> Klobucar <[email-masked]> 01/07 7:01 AM >>>
>Although there was a long discussion about certificate policies on this
list
>I am still a bit bemused, especially about recognizing and supporting
>certificate policies extensions (critical or non-critical). I would
>appreciate if someone could explain the following case. Let us suppose
>that a CA has published two policies for signing bills in certain company.
>One is used for bills where amount is less than 1000$ and does not specify
>how private keys must be protected. The other policy specifies
>rules for keys which can be used to sign bills over 1000$. These keys must
be
>stored on smartcards. The CA then issues certificates where one of this
>certificate policies is flagged critical. Should signing applications and
>applications for validating signatures which claim to support these
policies
>check the amount in each bill during signing procedure or signature
>validation? Must applications be able to verify if the signing key is
properly
>stored?
>
>Regards, Tomaz

Tomaz, let me take a crack at this. Others may jump in if they disagree.

First of all , when you say that the CA has published policies for signing
bills, I assume that what you really mean is that the Controller or other
management official within the company has decided what the policy must be,
and that the CA and others are directed to implement that policy, whether
the CA is internal to the company or outsourced.

The CA therefore will issue certificates with either of two flavors of
policy OIDs -- either "gold" for high value transactions, or "brown" for low
value transactions.  More likely, there will be a "gold" OID and no OID.

The rule for the relying party's software is simple.  The application which
processes bills has to look at the amount involved, and then decide whether
the appropriate evidence exists to approve the transaction.  So far, this
has NOTHING to do with the certificate infrastructure -- this is a
requirement laid on the application software and the software
developers/purchasers by the Controller, not by the certificate policy.

Assuming that the transaction amount is over $1000, the application has to
instruct the crypto API as to what kind of digital signatures to accept,
i.e., what kind of certificates are acceptable. The crypto API could
reference a local database of acceptable certificates, of course, but I
believe that your question assumed the use of the PKIX/X.509 infrastructure
without any trusted databases.

The way I would solve that problem if I were implementing the code would be
to provide two different contexts or API calls, one of which would specify
one self-signed certificate, and one of which would specify another.

The first self-signed certificate, effectively issued by the MIS department
responsible for overseeing the implementation of the controller's policy,
would contain a "gold" policy OID constraint which is marked Critical, and
would cross-certify the normal corporate CA's root key, or perhaps some
external CA's certificate. By virtue of the policy OID constraint, only
certificates containing a matching policy OID would be deemed acceptable,
whether issued by the top level corporate CA or some subordinate CA.
Importantly, however, the certificate of the end-user who is signing the
bill would (must) contain the matching policy OID.  Because the original
policy OID constraint was marked Critical, the relying party's software
would be forced to check that all of the certificates in the chain contained
the appropriate policy OID attribute.

The other self-signed certificate would either contain a "brown" policy OID
constraint, which might or might not be marked Critical, or more likely it
would not contain a policy OID constraint at all.

By dynamically switching between these two contexts on a transaction by
transaction basis, the relying party's software can ensure that for a given
transaction, the right kind of digital signature/certificate chain was used,
and ergo the right kind of protection was being given for the private key.

But the other portion of your question addressed the enforcement of the
policy at the time of signing, and that is a different question entirely.

When the CA binds the end-user's public key in a certificate, then in the
case of a "gold" policy OID, the CA is duty bound to ensure that only those
key storage devices which conform to the policy can be used to generate,
store, or access the corresponding private keys.  How the CA determines
and/or ensures that fact is its own business, but is presumably specified as
part of the overall policy which is referenced by the policy OID.

In most cases this will probably involve a representation by the end-user to
the CA that the key in question is properly stored, never accessed in the
clear, etc., and that may suffice -- especially if misrepresenting the facts
to the CA is grounds for firing the employee! Ultimately, as the
infrastructure evolves, devices such as smart cards, and even software
implementations, may protect the keys in such a way as to prevent their
disclosure outside of the minimum acceptable environment.

So now the user -- the one who is signing the bills originally -- either has
two keys, a good one and a not so good one, or they only have one or the
other, perhaps depending on their status in the company.

If they only have one key, of course there isn't much of a problem.  If
someone tries to sign a transaction over $1000 and doesn't have the right
kind of key, the transaction won't validate at the other end, and after
couple of such instances he won't do that again, or else.

If he has two keys, and the signing application is supposed to be
sufficiently intelligent to switch between the two keys based on the amount
of the transaction, that is more complicated. The two context solution could
still be used, in this case switching between the two signing keys. But this
is still sort of a scout's honor type of solution -- the enforcement is done
by the verifying application based on the policy OID in the certificate, and
not by the signing application where it probably ought to be done.

That is why, in one of my previous messages, I urged that the constraints in
the certificate be interpreted by the SIGNING application as well, prior to
using the corresponding private key to sign something. That would prevent
the signing application from using an encryption key instead of a signing
key, for example. And if the policy OID constraint is marked critical, the
signing application ought to be in an appropriate context before using that
key.

So, for example, if the application sees an amount that is over $1000, it
would switch contexts, examine the certificate that goes with the key that
is about to be used for signing, and either accept or reject that particular
signing operation accordingly.

I hope this answers your question.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

Date:         Wed, 7 Jan 1998 14:12:20 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Is PKIX Patent-free?
Comments: To: [email-masked]
To: [email-masked]
Status:

At least with respect to the second patent that Al mentioned, before someone
automatically concludes that Dr. Micali's patent is valid, they ought to go
back through the PEM archives for the dialogue between Sead Muftic and
myself, probably in the 1995 time period, where we were discussing something
very similar to what that patent appears to cover.

Likewise, I'm a little surprised by the registration agent patent. I thought
that was a pretty well developed concept in the DMS architecture, as well as
being pretty obvious. but I haven't examined the claims in detail, so maybe
there is more there than meets the eye.

It isn't clear to me how careful a job was done of looking at unpatented
prior art prior to issuing several of these patents. Before I shelled out a
lot of money for licenses in this area, I might talk to a good attorney
about the possibility of attacking the validity of these patent(s). At the
same time, I don't mean to suggest that any kind of inappropriate behavior
occurred on Dr. Micali's part -- lots of cases in the past have involved two
or more inventors coming up with essentially the same invention
independently, at more or less the same time, in response to a common
perceived need.

Bob

>(Thanks to Bill Burr and his folks at NIST who "discovered" this in
>their Federal PKI working group efforts.)
>
>Folks,
>
>        I'm not a lawyer, and I don't play one on TV, either, so I'm hoping
>that there is no problem with this, but...
>
>        There are (at least) two US patents that may be of interest to
PKIX.
>Both are owned by Silvio Micali.
>
>        One, patent #5,420,927, issued May 30, 1995, and entitled "Method
for
>certifying public keys in a digital signature", claims to cover a method
>of using registration agents to identify users, validate their public
>keys, send their keys on to a certification authority for inclusion in a
>certificate, confirm that the user possesses the private key that goes
>with the public key, etc.
>
>        The other, patent # 5,666,416, issued September 9, 1997, and
entitled
>"Certificate revocation system", claims to cover a method of having a CA
>determine whether a certificate is valid; pass a message stating such to
>another party, and having that party respond to queries from others with
>information about the validity of the certificate.  The "invention"
>covered by this patent "...obviates use of certification revocation
>lists communicated between the certifying authority and the directory. "
>
>        Is there someone on the list who can say with certainty that PKIX
parts
>1 and 3 do not infringe on the first of these patents, and that OCSP
>does not infringe on the other one?
>
>        Thanks for any information,
>
>
>                        Al Arsenault
>        - speaking only for myself.  My opinions do not necessarily reflect
>those of my employer.
>
>P.S.  URLs for these patents are
>
>        http://patent.womplex.ibm.com/details?patent_number=5420927
>
>and
>
>        http://patent.womplex.ibm.com/details?patent_number=5666416

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

Date:         Tue, 6 Jan 1998 17:43:10 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

Warwick,

Thanks for taking the time to continue this highly interesting discussion.

>>
>>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
>>do I necessarily need that CA's permission to do so?  I think not,
although
>>it might be polite to inform them of what I am doing.  (In most cases, of
>>course, this would only happen after a contractual agreement, so this is
>>probably just a rhetorical point.)
[snip]
>
>Well, I don't think you want to go around issuing certificates for other
>CAs' public keys without their permission.  Firstly, it is unwise since you
>would have no basis of assurances re future validity, revocation
>notification, etc.  Secondly you could arguably be treading into
>intellectual property violation waters.  Therefore, I think that we should
>be espousing that CA-certificates ALWAYS be issued only within a
>contractual agreement.

Hmm.

I'm not entirely sure that I agree.

What is the moral or legal, as opposed to technical, difference between my
creating a certificate which incorporates the public key of a TLCA, e.g.,
VeriSign, or any other CA, vs. directly loading the very same public key or
self-signed certificate into my trusted cache?

If you recall, you were the one who convinced me of the elegance of the
policy OID constraint approach to certificate chaining, pointing out that it
allowed the user himself, (or his IT organization) to create a certificate
which effectively serves as his own local (unpublished) TLCA and
cross-certifies other CAs, without requiring access to some kind of a local
database of trusted CAs to validate each certificate.  A suitable trusted
smart card, a la Fortessa, containing a trusted public key or self-signed
certifcate, could feasibly implement the relying party's trust policy
without requiring a trusted operating system host.

This way the RP has only his own public key to trust, and the IT
organization doesn't have to run around the country or the world populating
new trusted TLCA keys into client software every time a new CA pops up or a
key is replaced. They merely post new certificates on an untrusted directory
or repository, to be downloaded as needed.

A closed user group might be a different matter. But even in the case of
SET, what is to prevent me as a relying party from creating my own
certificate which cross-certifies the SET hierarchy?

If all I am doing is selling dollar dish rags, I might be willing to accept
a SET certificate, a Verisign certificate, a MISSI certificate, (or even a
PGP certificate or whatever), and take the byusiness risk that one of those
CAs or hierarchies has a less- han sterling reputation. It is arguably
better than using nothing at all, e.g., a telephone crecit card number.

In particularly, I DON'T think that I have to go out and negotiate a
contract with each one of those CAs before I create such a
cross-certificate, or equivalently load a self-signed certificate into my
trusted cache. That is essentially the fundamental assumption basis for an
open PKI architecture.

PUBLISHING such a certificate outside of my close circle of friends might be
quite a different matter, of course. But there my concern would be whether
by publishing such a certificate I might be making myself liable for that
other CA's operational screw-ups, etc. I would look at the CA's Cetification
Practice Statement and other indicia before decding whether or not to trust
the ongoing CRL and other policy matters, just as I would before loading
their root key into my cache. In any case I can make that decision for
myself -- I don't need and don't want a standard to preclude my options
(although I doubt that was what you had in mind).

I am not persuaded by the intellectual property argument, either, but I
would like to hear an attorney like Michael Baum put forth a cogent legal
theory along those lines.  To my way of thinking, I am not publishing any
copywrited or trademarked work at all, except to the extent that I
incorporate the public key contained in the CA's certificate. Since the
public nature of the public key is its raison d'etre, and since the CA's
certificate cannot be used except by incorporating the public key in the
relying party's cache of trusted keys one way or the other, I don't see how
I have infringed or diminished their copyright, the CA's trademark, or their
good name in any way.

I understand that VeriSign includes a copyright notice within their
certificates, but I have tended to regard this as a chicken soup, "it cant'
hurt" type of preventative medicine cop out.  If there is a real legal issue
lurking there somewhere, I'd like to know about it, as I believe it might
apply by extension to the use of that certificate by any relying party. I
don't think that was VeriSign's intent.

Regards,

Bob

Date:         Wed, 7 Jan 1998 17:46:05 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] cross certification
To: [email-masked]
Status:

Dwight & Warwick,

        I'd like to add another view to the cross certification discussion.
Certificates don't necessarily imply trust.  They are primarily mechanisms
to support identification (although explicit authorization is also an
option), and this identification is often used as an input to an access
control decision.  So, when I certify a CA in another administrative
domain, the simple connotation is that I am relying on (trusting?) that CA
to identify subjects within that domain.  Having relied upon that CA for
that function, I can then proceed to make access control decisions based on
the subject identities from this other administrative domain.  If one
embeds authorization info into the certs and uses that for access control,
then life is more complex and certification policy extensions may also be
used to help control the authorization range afforded to the
cross-certified CA.  As Tina Turner so aptly said, "what's trust got to do
with it?"

Steve

Date:         Wed, 7 Jan 1998 14:56:31 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Arsenault, Al W." <[email-masked]>
Subject:      [IETF-PKIX] Is PKIX Patent-free?
To: [email-masked]
Status:

(Thanks to Bill Burr and his folks at NIST who "discovered" this in
their Federal PKI working group efforts.)

Folks,

        I'm not a lawyer, and I don't play one on TV, either, so I'm hoping
that there is no problem with this, but...

        There are (at least) two US patents that may be of interest to PKIX.
Both are owned by Silvio Micali.

        One, patent #5,420,927, issued May 30, 1995, and entitled "Method for
certifying public keys in a digital signature", claims to cover a method
of using registration agents to identify users, validate their public
keys, send their keys on to a certification authority for inclusion in a
certificate, confirm that the user possesses the private key that goes
with the public key, etc.

        The other, patent # 5,666,416, issued September 9, 1997, and entitled
"Certificate revocation system", claims to cover a method of having a CA
determine whether a certificate is valid; pass a message stating such to
another party, and having that party respond to queries from others with
information about the validity of the certificate.  The "invention"
covered by this patent "...obviates use of certification revocation
lists communicated between the certifying authority and the directory. "

        Is there someone on the list who can say with certainty that PKIX parts
1 and 3 do not infringe on the first of these patents, and that OCSP
does not infringe on the other one?

        Thanks for any information,

                        Al Arsenault
        - speaking only for myself.  My opinions do not necessarily reflect
those of my employer.

P.S.  URLs for these patents are

        http://patent.womplex.ibm.com/details?patent_number=5420927

and

        http://patent.womplex.ibm.com/details?patent_number=5666416

Date:         Wed, 7 Jan 1998 15:01:21 +0100
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Tomaz Klobucar <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
To: [email-masked]
Status:

Although there was a long discussion about certificate policies on this list
I am still a bit bemused, especially about recognizing and supporting
certificate policies extensions (critical or non-critical). I would
appreciate if someone could explain the following case. Let us suppose
that a CA has published two policies for signing bills in certain company.
One is used for bills where amount is less than 1000$ and does not specify
how private keys must be protected. The other policy specifies
rules for keys which can be used to sign bills over 1000$. These keys must be
stored on smartcards. The CA then issues certificates where one of this
certificate policies is flagged critical. Should signing applications and
applications for validating signatures which claim to support these policies
check the amount in each bill during signing procedure or signature
validation? Must applications be able to verify if the signing key is properly
stored?

Regards, Tomaz

Date:         Wed, 7 Jan 1998 09:59:16 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

-----Original Message-----
From: Gary Gaskell <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, 7 January 1998 9:43
Subject: Re: [IETF-PKIX] Cross-certification issues and terminology

:Gents,
:
:[Firstly, apologies if this does not contribute in a constructive way to
:your discussion, as I haven't read _all_ of the preceding discussions.
:Hopefully it will contribute ;-) ]
:
:1. I don't think we can say, "X.509 says it all", as that is why you are
:all working PKIX in the first place.  PKIX must take some lead if this is
:ever to be deployed;
:
Snip

:I hope this in some way contributes to your debate.

It adds to the usage examples of Xcerts, but I still do not see problem with
the defintion of a Xcert in X.509.

I believe the discussion should be about what we are trying to standardise
in PKIX, I dont belive we should be trying to standardise on a particular
use of Xcerts ( as the the deployment experience of large scale PKI's is
just too imature at this time).

:
:Cheers,
:
:Gary
:
:On Tue, 6 Jan 1998, Warwick Ford wrote:
:

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

Attachment converted: Lutefisk:smime.p7s 26 (????/----) (0001DE3F)

Date:         Wed, 7 Jan 1998 09:26:18 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Wednesday, January 07, 1998 8:34 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] NO SUBJECT
>
> Charles:
>
> At 06:08 AM 1/7/98 +1000, Charles Moore wrote:
> >:Could you please clarify exactly what "technical definition" you are
> >:referring to?  What document is it in?
> >
> >The X.509 standard, has more than sufficient definition to meet our
> >technical objective, in both syntax, normative and non-normative
> text.
>
> Unfortunately X.509 does not define "cross-certification" in an
> unambiguous
> or particularly helpful way.  We would not be pursuing this thread if
> it did.
        [Charles Moore]  Ok, whats the problem.

        Are you sure we are separating definition ( specification) from
issues relating to the use of the specification.

        Please explain the ambiguity from a specification perspective
(not the use of the specification).

        All of the discussion I have followed to date has been on how
one might use this specification to meet  one-or-more policies, all good
discussion, but not related to ambiguity of specification.

        Do you want to standardise on a specific use of
cross-certificates ( ie a standard policy statement, one or more) and if
so why?

> Warwick
>
> ---------------------------------------------------------------------
> Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>    [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
> ---------------------------------------------------------------------

Date:         Wed, 7 Jan 1998 09:08:24 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gary Gaskell <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

Gents,

[Firstly, apologies if this does not contribute in a constructive way to
your discussion, as I haven't read _all_ of the preceding discussions.
Hopefully it will contribute ;-) ]

1. I don't think we can say, "X.509 says it all", as that is why you are
all working PKIX in the first place.  PKIX must take some lead if this is
ever to be deployed;

2. Cross certification is very important and I anticipate that the use of
cross certification will be a primary issue in the successful deployment
of PKIX.
Why:
  a. because governments will never get organised soon enough, for a
     hierarchy to work;
  b. Because an imposed heirarchy would be too rigid;
  c. An organisation wants to be in control of who their
     employees trust and deal with

>From point c above, I think we can draw the main reason for the design and
deployment of cross CA certs.  If we mandate contracts are written and
signed, we could be putting an onerous burden on an organisation in the
set up of their IT infrastructure.

IMO points a and b are what detract significantly from Australia PKAF
work.

The scenario that I'm thinking of goes like:

Organisation Acme has an IT system where its employees can only interact
with people in other organisations if Acme has cross signed the CA public
keys of other organisations.  This gives Acme more control and a way of
enforcing their business policy.  As they may change their preferred
supplier daily, a contractual basis for cross signing may be too much.

And I presume we could leave it to the organisation (e.g. Acme) to check a
central (government or private) directory service for cert revocations,
and then add them to their own CRL.

IE. The norm for a cert path check may be:
a. retrieve cert
b. check its CA's signature
c. check that my organisation has a cross cert for this other organisation
d. check my organisation's CRL.

If not if appears that my organisation has not approved business
interactions with the other organisation.  I think this could also be
expanded to cross signing the public keys of a node in a hierarchy.  If
there was to be one true hierarchy, then the organisation can control
which parts of it are trustworthy by the organisations people.

I hope this in some way contributes to your debate.

Cheers,

Gary

On Tue, 6 Jan 1998, Warwick Ford wrote:

>Bob:
>
>At 10:40 AM 1/6/98 -0700, Bob Jueneman wrote:
>>But first let me ask your opinion regarding the creation of a cross-domain
>>certificate.  I haven't read the CMP proposal in any detail, but I'm not
>>sure that I understand why any protocol is particularly needed in this case.
>>
>>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
>>do I necessarily need that CA's permission to do so?  I think not, although
>>it might be polite to inform them of what I am doing.  (In most cases, of
>>course, this would only happen after a contractual agreement, so this is
>>probably just a rhetorical point.)  So why do I need a protocol? Can't I
>>just pick up the self-signed certificate via a trusted out-of-band, i.e.,
>>manual, process (which I would need to do in any case), extract the public
>>key, and include that key in my newly minted certificate? (Regardless of
>>whether a public key is created by an end-user, or by a CA, or even by the
>>issuing CA, some sort of trusted, out-of-band process is always required
>>prior to the binding, to ensure that the subject is who they claim to be,
>>and to provide proof of possession of the corresponding private key.)
>
>Well, I don't think you want to go around issuing certificates for other
>CAs' public keys without their permission.  Firstly, it is unwise since you
>would have no basis of assurances re future validity, revocation
>notification, etc.  Secondly you could arguably be treading into
>intellectual property violation waters.  Therefore, I think that we should
>be espousing that CA-certificates ALWAYS be issued only within a
>contractual agreement.
>
>As to the need for a protocol...  Technically, all you need is an agreed
>format for representing a certificate-signing request ... the most obvious
>approach is to use exactly the same format (and surrounding protocol, if
>required) as when an end-entity enrolls with a CA.  The Microsoft
>Certificate Server, for example, uses PKCS#10 for representing the
>information sent from a subject CA to issuing CA to have a CA-certificate
>issued.  CMP is essentially the same -- the "CrossCert" transaction is just
>a minor variant of the end-entity certificate-signing request.
>
>>Is the supposition behind CMP that a TLCA in one domain would request that
>>they be issued a certificate by a CA in another domain?  That doesn't seem
>>very likely or reasonable. So I think that I must misperceive the intent of
>>CMP -- perhaps it is only intended to address how subordinate CAs request a
>>certificate from a higher level (within the hierarchy) CA?
>
>I believe CMP provides nothing more than a protocol for one CA issuing a
>certificate to another CA, regardless, of domain or structure.  This is why
>Denis and I prefer the term "CA-certification" for what CMP does.  CMP does
>nothing to help solve the "hard problems" of cross-certification.
>
>>On another point, you comment that inter-domain certification might end up
>>with a [linked] hierarchical structure, or might not.
>>
>>I assume that you mean that a CA in one domain might unilaterally issue a
>>certificate to a CA in another domain, not necessarily the TLCA in that
>>domain. I can see that that might happen, and might actually be quite useful
>
>Yes, and your subsequent example is quite valid.  Raises some good points ....
>
>Warwick
>
>
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
>

Cheers,

Gary

-----------------------------------------------------------
Gary Gaskell
Manager Secure Network Laboratory      Phone (07) 3864 1190
Information Security Research Centre   Fax   (07) 3221 2384
Queensland University of Technology
-----------------------------------------------------------

Date:         Tue, 6 Jan 1998 17:34:25 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

Charles:

At 06:08 AM 1/7/98 +1000, Charles Moore wrote:
>:Could you please clarify exactly what "technical definition" you are
>:referring to?  What document is it in?
>
>The X.509 standard, has more than sufficient definition to meet our
>technical objective, in both syntax, normative and non-normative text.

Unfortunately X.509 does not define "cross-certification" in an unambiguous
or particularly helpful way.  We would not be pursuing this thread if it did.

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Tue, 6 Jan 1998 17:15:09 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification issues and terminology
To: [email-masked]
Status:

Bob:

At 10:40 AM 1/6/98 -0700, Bob Jueneman wrote:
>But first let me ask your opinion regarding the creation of a cross-domain
>certificate.  I haven't read the CMP proposal in any detail, but I'm not
>sure that I understand why any protocol is particularly needed in this case.
>
>If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
>do I necessarily need that CA's permission to do so?  I think not, although
>it might be polite to inform them of what I am doing.  (In most cases, of
>course, this would only happen after a contractual agreement, so this is
>probably just a rhetorical point.)  So why do I need a protocol? Can't I
>just pick up the self-signed certificate via a trusted out-of-band, i.e.,
>manual, process (which I would need to do in any case), extract the public
>key, and include that key in my newly minted certificate? (Regardless of
>whether a public key is created by an end-user, or by a CA, or even by the
>issuing CA, some sort of trusted, out-of-band process is always required
>prior to the binding, to ensure that the subject is who they claim to be,
>and to provide proof of possession of the corresponding private key.)

Well, I don't think you want to go around issuing certificates for other
CAs' public keys without their permission.  Firstly, it is unwise since you
would have no basis of assurances re future validity, revocation
notification, etc.  Secondly you could arguably be treading into
intellectual property violation waters.  Therefore, I think that we should
be espousing that CA-certificates ALWAYS be issued only within a
contractual agreement.

As to the need for a protocol...  Technically, all you need is an agreed
format for representing a certificate-signing request ... the most obvious
approach is to use exactly the same format (and surrounding protocol, if
required) as when an end-entity enrolls with a CA.  The Microsoft
Certificate Server, for example, uses PKCS#10 for representing the
information sent from a subject CA to issuing CA to have a CA-certificate
issued.  CMP is essentially the same -- the "CrossCert" transaction is just
a minor variant of the end-entity certificate-signing request.

>Is the supposition behind CMP that a TLCA in one domain would request that
>they be issued a certificate by a CA in another domain?  That doesn't seem
>very likely or reasonable. So I think that I must misperceive the intent of
>CMP -- perhaps it is only intended to address how subordinate CAs request a
>certificate from a higher level (within the hierarchy) CA?

I believe CMP provides nothing more than a protocol for one CA issuing a
certificate to another CA, regardless, of domain or structure.  This is why
Denis and I prefer the term "CA-certification" for what CMP does.  CMP does
nothing to help solve the "hard problems" of cross-certification.

>On another point, you comment that inter-domain certification might end up
>with a [linked] hierarchical structure, or might not.
>
>I assume that you mean that a CA in one domain might unilaterally issue a
>certificate to a CA in another domain, not necessarily the TLCA in that
>domain. I can see that that might happen, and might actually be quite useful

Yes, and your subsequent example is quite valid.  Raises some good points ....

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Wed, 7 Jan 1998 06:08:59 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, 7 January 1998 0:12
Subject: Re: [IETF-PKIX] NO SUBJECT

:Charles:
:
:At 12:02 PM 1/6/98 +1000, Charles Moore wrote:
:>So
:>1. Leave the technical definition as is
:
:Could you please clarify exactly what "technical definition" you are
:referring to?  What document is it in?
:
:Do you mean bullet (g) in the PKIX Profile which says "cross-certification:
:Two CAs exchange the information necessary to establish cross-certificates
:between those CAs" ... kinda circular, maybe?

The X.509 standard, has more than sufficient definition to meet our
technical objective, in both syntax, normative and non-normative text.

How this mechanism can be used, does not need to be, and should not be in
PKIX, standardised as it is dependent on certificate policy.

:
:Warwick
:
:---------------------------------------------------------------------
:Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
:   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
:---------------------------------------------------------------------

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

Attachment converted: Lutefisk:smime.p7s 23 (????/----) (0001DE33)

Date:         Tue, 6 Jan 1998 14:47:02 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Patent on use of CRLs etc
To: [email-masked]
Status:

Bob Jueneman wrote:
>
> I couldn't read your attachment.  Could you provide a short summary of the
> patent?  Who was it issued to?

The Nortel and Novell Patents are both on the IBM patent server:

http://patent.womplex.ibm.com/details?patent_number=5699431
http://patent.womplex.ibm.com/details?patent_number=5687235

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 22 (????/----) (0001DE23)

Date:         Tue, 6 Jan 1998 14:39:48 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] Patent on use of CRLs etc
To: [email-masked]
Status:

Also note patent 5687235.

        Phill

PS The patent I applied for covering motherhood, apple pie and the
American way was rejected as 'having no conceivable application'

Phillip Hallam-Baker wrote:
>
> Do we need to include a reference to US Patent 5699431 in the
> PKIX drafts?
>
> It appears it might cover much of the PKIX CRL infrastructure
> including partitioned CRLs.
>
> Is this likely to cause difficulty with the IESG?
>
>                 Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 21 (????/----) (0001DE22)

Date:         Tue, 6 Jan 1998 13:04:49 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      [IETF-PKIX] Patent on use of CRLs etc
To: [email-masked]
Status:

Do we need to include a reference to US Patent 5699431 in the
PKIX drafts?

It appears it might cover much of the PKIX CRL infrastructure
including partitioned CRLs.

Is this likely to cause difficulty with the IESG?

                Phill
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

Attachment converted: Lutefisk:smime.p7s 20 (????/----) (0001DE20)

Date:         Tue, 6 Jan 1998 11:44:15 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] Patent on use of CRLs etc
Comments: To: [email-masked]
To: [email-masked]
Status:

I couldn't read your attachment.  Could you provide a short summary of the
patent?  Who was it issued to?

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

>>> Phillip Hallam-Baker <[email-masked]> 01/06 11:04 AM >>>
Do we need to include a reference to US Patent 5699431 in the
PKIX drafts?

It appears it might cover much of the PKIX CRL infrastructure
including partitioned CRLs.

Is this likely to cause difficulty with the IESG?

                Phill

Date:         Tue, 6 Jan 1998 10:40:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] Cross-certification issues and terminology
Comments: To: [email-masked]
To: [email-masked]
Status:

Warwick,

Separating the (cross-)certificate issuance issues from the certificate
retrieval issues is probably useful, although both problems will have to be
solved sooner or later. I also agree that there may be a requirement for a
cross-certificate within a simple hierarchy (i.e., with a single domain),
for performance or other reasons. And I haven't even begun to think through
the CRL and other issues involved in cross-domain certification -- I hope
that you have, and that it works.

But first let me ask your opinion regarding the creation of a cross-domain
certificate.  I haven't read the CMP proposal in any detail, but I'm not
sure that I understand why any protocol is particularly needed in this case.

If I as a CA want to issue a certificate to a TLCA (or in fact to any CA),
do I necessarily need that CA's permission to do so?  I think not, although
it might be polite to inform them of what I am doing.  (In most cases, of
course, this would only happen after a contractual agreement, so this is
probably just a rhetorical point.)  So why do I need a protocol? Can't I
just pick up the self-signed certificate via a trusted out-of-band, i.e.,
manual, process (which I would need to do in any case), extract the public
key, and include that key in my newly minted certificate? (Regardless of
whether a public key is created by an end-user, or by a CA, or even by the
issuing CA, some sort of trusted, out-of-band process is always required
prior to the binding, to ensure that the subject is who they claim to be,
and to provide proof of possession of the corresponding private key.)

Is the supposition behind CMP that a TLCA in one domain would request that
they be issued a certificate by a CA in another domain?  That doesn't seem
very likely or reasonable. So I think that I must misperceive the intent of
CMP -- perhaps it is only intended to address how subordinate CAs request a
certificate from a higher level (within the hierarchy) CA?

On another point, you comment that inter-domain certification might end up
with a [linked] hierarchical structure, or might not.

I assume that you mean that a CA in one domain might unilaterally issue a
certificate to a CA in another domain, not necessarily the TLCA in that
domain. I can see that that might happen, and might actually be quite useful
-- MISSI might certify a subordinate CA within its domain, let's say the
Utah National Guard, and the State of Utah might also certify that CA under
the provisions of the Utah Digital Signature Act. Rather than provoke a
constitutional crisis over the primacy of federal vs. state powers, a first
come, first served rule might be applied, and Utah would cross-certify the
Utah National Guard CA directly, bypassing higher-level CAs in the MISSI
hierarchy.  (It might well be that Utah would either require a higher
standard of performance for their licensed CAs than MISSI would necessarily
provide, or that the State simply wouldn't have the resources to audit and
otherwise ensure compliance with the Utah Act for other MISSI CAs. So
although they might certify the Utah National Guard CA, they would not
certify MISSI itself, nor the other CAs under the MISSI hierarchy.)

Let me see if I understand how the certificate validation process works in
this case. And I will conveniently ignore the issue of how the certificates
are actually located, whether they are all in one ubiquitous directory, or
have to be retrieved from various sites is a small detail, at least for now.

So consider the case where a relying party has loaded the root key of the
Utah TLCA, and wants to only deal with CAs that are licensed under the Utah
Act. A purchase order is received, signed by the Supply Officer of Bravo
Company, First Chemical Weapons Battalion, Utah National Guard, whose
certificate is issued by the UNG CA directly (for the sake of argument).

If the relying party's software just climbs the certificate tree blindly, it
would tend to look for the next level certificate, which let's say is issued
by the US Army CA to the Utah National Guard. But climbing that particular
tree isn't going to be useful, because Utah hasn't certified the MISSI TLCA.

So somehow the relying party's software has to know that it should preload
and verify the Utah certificate which certifies the Utah National Guard CA's
certificate.  Then, when the RP's software encounters the UNG's certificate,
it can exclaim "Eureka! I already have verified this public key, and so
everything is hunky-dory."

That's OK in concept, but God is in the niggling details:

1.  How does the RP software know that that particular cross-certificate is
going to be needed?  Does it have to preload and verify every certificate
issued by Utah? That might not be too bad in the case of Utah, but what if
it were New York or Illinois? The software might have to maintain thousands
of keys in its stack.

2.  It isn't sufficient to just (pre-)validate the public key of the Utah
National Guard -- presumably the RP software has to keep track of all of the
policy OID and other constraints that might be applied, from the Utah TLCA
on down, and then check that the end-user certificate issued by the UNG
satisfies those criteria.

I am increasingly beginning to believe that it will be necessary to store
prevalidated certificates in a locally-trusted working directory. Whether
the most efficient implementation of the search argument for finding a
certificate in the directory should be the DN of the subject, or perhaps a
hash of the public key, remains to be determined.

How this should impact OCSP, and/or how nonrepudiation should best be
provided in this environment also requires further study, I believe.

Bob

>Bob:
>
>This is another interesting (and unquestionably useful) view on the meaning
>of "cross-certification".  It is different to what I had been referring to
>as "inter-domain certification" because, to my mind, inter-domain
>certification might end up with a hierarchical structure or might not.
>
>It is now clear that there are at least 3 quite different problems being
>addressed, all of them being declared as the "cross-certification" problem,
>but that there is no "cross-certification" panacea.  I therefore suggest we
>retire the term "cross-certification" for the moment and focus on the
>various problems and the characteristics of their solutions.
>
>I believe the "problems" identified thus far are:
>
>(a) The mechanical problem of having one CA issue a cert for another CA
>(regardless of domain, PKI structure, etc.).  This is the problem solved by
>the CMP CrossCert transaction or similar enrollment protocols.  As pointed
>out by Denis Pinkas, this is probably best called "CA-certification" for
>consistency with the X.509 term "CA-certificate".
>
>(b) The problem of establishing a link between two domains (typically two
>organizations) whereby a CA in one domain issues a certificate for the
>cert-signing key of a CA in another domain.  This raises the issues of
>assessment of trustworthiness, establishment of binding agreements,
>liability apportionment, X.509 protection mechanisms such as name
>constraints and policy-mapping, transitivity (on to further domains), etc.
>(I have been using the term "inter-domain certification" for this.)
>
>(c) The problem of finding a cert chain given that, in the general case,
>the overall structure of CAs comprises hierarchies, with inter-hierarchy
>links.  This raises the issues of availability of information from
>directories, and the capabilities of certificate-using products to perform
>the necessary searching and traversal.
>
>I do not believe the (b) and (c) problem domains generally lead to a common
>solution, nor that there is a particularly strong need to seek such a
>common solution.  For example, when a CA in domain A issues a certificate
>for a CA in domain B, the result could still be a hierarchy (if A is
>certifying the TLCA of B, and A is the only domain that does so), in which
>case the advantages of hierarchical cert-finding are still apparent.
>Conversely, within one domain, one might have a basic hierarchical
>structure but allow (for chain-shortening, performance purposes)
>certification links across the hierarchy (both the Fed Govt and Canadian
>Govt architectures have recognized the potential need for this).
>
>Warwick

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two leaps."

Date:         Tue, 6 Jan 1998 08:28:53 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

Charles:

At 12:02 PM 1/6/98 +1000, Charles Moore wrote:
>So
>1. Leave the technical definition as is

Could you please clarify exactly what "technical definition" you are
referring to?  What document is it in?

Do you mean bullet (g) in the PKIX Profile which says "cross-certification:
Two CAs exchange the information necessary to establish cross-certificates
between those CAs" ... kinda circular, maybe?

Warwick

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Tue, 6 Jan 1998 12:02:22 +1000
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Charles Moore <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

I am not sure why things have to be made more complicated than needed.

A) First Separate out the technical issues from the policy issues.
B) Address the technical issues here, leave the policy issues for the
policy/business decisions.

With the above, cross certification at least with the current standard
is straight forward.
All of the discussed uses of cross-certificates are ok, it all depends
on the policy under which the cross-certificate is certified.

So
1. Leave the technical definition as is
2. Let the certificate policy make statements about the rules and
meanings of any cross-certificate.
Let the policy have flexibility to support what people what to put
labels on such as inter-domain certification or other terms.

> -----Original Message-----
> From: Warwick Ford [SMTP:[email-masked]]
> Sent: Tuesday, January 06, 1998 10:44 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] NO SUBJECT
>
> Bob:
>
> This is another interesting (and unquestionably useful) view on the
> meaning
> of "cross-certification".  It is different to what I had been
> referring to
> as "inter-domain certification" because, to my mind, inter-domain
> certification might end up with a hierarchical structure or might not.
>
> It is now clear that there are at least 3 quite different problems
> being
> addressed, all of them being declared as the "cross-certification"
> problem,
> but that there is no "cross-certification" panacea.  I therefore
> suggest we
> retire the term "cross-certification" for the moment and focus on the
> various problems and the characteristics of their solutions.
        [Charles Moore]  One problem, but many policies, and there are
more than these.

> I believe the "problems" identified thus far are:
>
> (a) The mechanical problem of having one CA issue a cert for another
> CA
> (regardless of domain, PKI structure, etc.).  This is the problem
> solved by
> the CMP CrossCert transaction or similar enrollment protocols.  As
> pointed
> out by Denis Pinkas, this is probably best called "CA-certification"
> for
> consistency with the X.509 term "CA-certificate".
        [Charles Moore]  It is just cross-certification, nothing more.
Whether CMP crossCerts messages are useful for this or any other Xcert
is a different issue.

> (b) The problem of establishing a link between two domains (typically
> two
> organizations) whereby a CA in one domain issues a certificate for the
> cert-signing key of a CA in another domain.  This raises the issues of
> assessment of trustworthiness, establishment of binding agreements,
> liability apportionment, X.509 protection mechanisms such as name
> constraints and policy-mapping, transitivity (on to further domains),
> etc.
> (I have been using the term "inter-domain certification" for this.)
        [Charles Moore]  Its the same as above just that the policies on
cross certification are different

> (c) The problem of finding a cert chain given that, in the general
> case,
> the overall structure of CAs comprises hierarchies, with
> inter-hierarchy
> links.  This raises the issues of availability of information from
> directories, and the capabilities of certificate-using products to
> perform
> the necessary searching and traversal.
        [Charles Moore]  I believe this is a orthogonal problem that
applies to all cases.

> I do not believe the (b) and (c) problem domains generally lead to a
> common
> solution,
        [Charles Moore]  I am not sure I understand, they both can
produce a solution, but in all cases there is a need to know the
policies/rules

> nor that there is a particularly strong need to seek such a
> common solution.
        [Charles Moore]  If this means common code/rules I agree in the
specific and also the general case.

> For example, when a CA in domain A issues a certificate
> for a CA in domain B, the result could still be a hierarchy (if A is
> certifying the TLCA of B, and A is the only domain that does so), in
> which
> case the advantages of hierarchical cert-finding are still apparent.
> Conversely, within one domain, one might have a basic hierarchical
> structure but allow (for chain-shortening, performance purposes)
> certification links across the hierarchy (both the Fed Govt and
> Canadian
> Govt architectures have recognized the potential need for this).
        [Charles Moore]  I am not sure I understand the specific
relevance, the PKI will have many different structures, the technical
services such as
        cross-certification must support ( and I believe it does) any
structure.
        Some of the structures will have advantages over others in given
situations.

Date:         Mon, 5 Jan 1998 19:43:42 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

Bob:

This is another interesting (and unquestionably useful) view on the meaning
of "cross-certification".  It is different to what I had been referring to
as "inter-domain certification" because, to my mind, inter-domain
certification might end up with a hierarchical structure or might not.

It is now clear that there are at least 3 quite different problems being
addressed, all of them being declared as the "cross-certification" problem,
but that there is no "cross-certification" panacea.  I therefore suggest we
retire the term "cross-certification" for the moment and focus on the
various problems and the characteristics of their solutions.

I believe the "problems" identified thus far are:

(a) The mechanical problem of having one CA issue a cert for another CA
(regardless of domain, PKI structure, etc.).  This is the problem solved by
the CMP CrossCert transaction or similar enrollment protocols.  As pointed
out by Denis Pinkas, this is probably best called "CA-certification" for
consistency with the X.509 term "CA-certificate".

(b) The problem of establishing a link between two domains (typically two
organizations) whereby a CA in one domain issues a certificate for the
cert-signing key of a CA in another domain.  This raises the issues of
assessment of trustworthiness, establishment of binding agreements,
liability apportionment, X.509 protection mechanisms such as name
constraints and policy-mapping, transitivity (on to further domains), etc.
(I have been using the term "inter-domain certification" for this.)

(c) The problem of finding a cert chain given that, in the general case,
the overall structure of CAs comprises hierarchies, with inter-hierarchy
links.  This raises the issues of availability of information from
directories, and the capabilities of certificate-using products to perform
the necessary searching and traversal.

I do not believe the (b) and (c) problem domains generally lead to a common
solution, nor that there is a particularly strong need to seek such a
common solution.  For example, when a CA in domain A issues a certificate
for a CA in domain B, the result could still be a hierarchy (if A is
certifying the TLCA of B, and A is the only domain that does so), in which
case the advantages of hierarchical cert-finding are still apparent.
Conversely, within one domain, one might have a basic hierarchical
structure but allow (for chain-shortening, performance purposes)
certification links across the hierarchy (both the Fed Govt and Canadian
Govt architectures have recognized the potential need for this).

Warwick

At 01:52 PM 1/5/98 -0700, Bob Jueneman wrote:
>Warwick,
>
>I certainly agree with the need to clarify the terminology.
>
>
>To my way of thinking, one of the most important distinctions between an
>interdomain cross-certificate and an "ordinary" certificate lies in the
>potential one-to-many relationship of the subject to the issuer that
>significantly complicates the certificate retrieval mechanism, by requiring
>both bottom-up and top-down processing.
>
>Since I may not have a correct understanding of the model, let me at least
>describe what I am envisioning:
>
>A stand-alone, hierarchical domain exists that consists of a top-level CA,
>one or more subordinate CAs whose certificates are either signed by the
>top-level CA or by a higher-level subordinate CA, and a multiplicity of
>end-user's whose certificates are signed by a subordinate CA.
>
>Although not absolutely necessary, I am envisioning that the public key of
>the top-level CA will be incorporated in a self-signed certificate for
>compatibility of distribution as well as to allow the inclusion of various
>attributes (e.g., expiration dates, DNs, etc.) in a standard form.
>
>Given an end-user's certificate, it is possible to at least identify the
>name of the issuing CA by looking at the issuerName field of the end-user's
>certificate. Hopefully the location of that certificate can also be derived,
>at least indirectly if not directly.  By applying this mechanism
>recursively, it is possible to climb the chain of certificates up to the
>top-level CA, whose self-signed certificate serves as a 'stopper" to stop
>the search.  If the top-level CA's public key is included in the cache of
>trusted keys for that application, then the chain is validated, if not,
>punt.
>
>Within the hierarchy, certificates have a one to many relationship between
>the issuer and multiple subjects. But cross-domain certificates introduce
>the possibility that a given subject's public key may be signed by multiple
>issuers, i.e., though the creation of a multiplicity of certificates which
>include the public key of that top-level CA within that domain.
>
>Since an X.509 certificate cannot contain multiple issuers, and even if it
>could there would be no effective way to coordinate the issuance of such a
>multiple issuer certificate, the tree-climbing algorithm for certificate
>retrieval effectively breaks at this point.
>
>Instead, the introduction of a cross-domain certificate provides an
>alternative means of distributing trusted root keys to relying parties
>within a particular community of interest -- one that is more flexible and
>extensible than merely including the root keys in code, for example.
>
>In effect, this provides a mechanism for implementing Dwight Arthur's view
>of the world -- a community of relying parties, perhaps influenced or
>dictated by an organization's IT department, distributes a single trusted
>root key for that particular community through an out-of-band mechanism.
>That particular domain makes up a hierarchy, although in the case of a
>single user who operates his own CA, the hierarchy has a depth of one level.
>
>Those end users whose chain of certificates can be verified by checking the
>chain up to the top-level trusted CA (modulo whatever policy OID and other
>path validation mechanisms may be imposed) can assumed to be trusted by
>anyone whose has chosen or implemented that top-level CA as their trusted
>root.
>
>End users who may be issued certificates under the aegis of another
>top-level CA, but one that is trusted by the relying party (or more likely,
>by the relying party's IT department as a function of organization policy,
>including contractual or other agreements) can be automatically accepted if
>some CA in the relying party's hierarchy (usually, but not necessarily, the
>top level CA in the domain) cross-certifies the other domain though the
>issuance of a certificate which includes the public key of the foreign
>domain's top-level CA.
>
>>From a certificate processing standpoint, the ultimate end-user's
>certificate is still processed from the bottom up, all the way to the
>self-signed certificate that represents the top-level CA in the foreign
>domain.  But as a result of the cross-domain certification, and perhaps as a
>result of preprocessing all of the cross-domain certificates issued by the
>relying party's own top-level CA, the foreign CA's public key can now be
>considered trusted, just as though it had been conveyed directly via a
>secure out-of-band mechanism.
>
>In addition, all of the existing policy OID and other constraint mechanisms
>can be imposed to control the extent to which transitive trust extends to
>subordinate CAs and their end-users.
>
>That's at least what I mean by cross-certification.  I'm not quite sure
>whether that is what other people have implied by the term. In particular,
>my use of the term cross-certification does NOT mean the simple
>certification of subordinate CA by a higher-level CA in a simple hierarchy.
>
>Bob

---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 5 Jan 1998 13:52:05 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
Comments: To: [email-masked]
To: [email-masked]
Status:

Warwick,

I certainly agree with the need to clarify the terminology.

To my way of thinking, one of the most important distinctions between an
interdomain cross-certificate and an "ordinary" certificate lies in the
potential one-to-many relationship of the subject to the issuer that
significantly complicates the certificate retrieval mechanism, by requiring
both bottom-up and top-down processing.

Since I may not have a correct understanding of the model, let me at least
describe what I am envisioning:

A stand-alone, hierarchical domain exists that consists of a top-level CA,
one or more subordinate CAs whose certificates are either signed by the
top-level CA or by a higher-level subordinate CA, and a multiplicity of
end-user's whose certificates are signed by a subordinate CA.

Although not absolutely necessary, I am envisioning that the public key of
the top-level CA will be incorporated in a self-signed certificate for
compatibility of distribution as well as to allow the inclusion of various
attributes (e.g., expiration dates, DNs, etc.) in a standard form.

Given an end-user's certificate, it is possible to at least identify the
name of the issuing CA by looking at the issuerName field of the end-user's
certificate. Hopefully the location of that certificate can also be derived,
at least indirectly if not directly.  By applying this mechanism
recursively, it is possible to climb the chain of certificates up to the
top-level CA, whose self-signed certificate serves as a 'stopper" to stop
the search.  If the top-level CA's public key is included in the cache of
trusted keys for that application, then the chain is validated, if not,
punt.

Within the hierarchy, certificates have a one to many relationship between
the issuer and multiple subjects. But cross-domain certificates introduce
the possibility that a given subject's public key may be signed by multiple
issuers, i.e., though the creation of a multiplicity of certificates which
include the public key of that top-level CA within that domain.

Since an X.509 certificate cannot contain multiple issuers, and even if it
could there would be no effective way to coordinate the issuance of such a
multiple issuer certificate, the tree-climbing algorithm for certificate
retrieval effectively breaks at this point.

Instead, the introduction of a cross-domain certificate provides an
alternative means of distributing trusted root keys to relying parties
within a particular community of interest -- one that is more flexible and
extensible than merely including the root keys in code, for example.

In effect, this provides a mechanism for implementing Dwight Arthur's view
of the world -- a community of relying parties, perhaps influenced or
dictated by an organization's IT department, distributes a single trusted
root key for that particular community through an out-of-band mechanism.
That particular domain makes up a hierarchy, although in the case of a
single user who operates his own CA, the hierarchy has a depth of one level.

Those end users whose chain of certificates can be verified by checking the
chain up to the top-level trusted CA (modulo whatever policy OID and other
path validation mechanisms may be imposed) can assumed to be trusted by
anyone whose has chosen or implemented that top-level CA as their trusted
root.

End users who may be issued certificates under the aegis of another
top-level CA, but one that is trusted by the relying party (or more likely,
by the relying party's IT department as a function of organization policy,
including contractual or other agreements) can be automatically accepted if
some CA in the relying party's hierarchy (usually, but not necessarily, the
top level CA in the domain) cross-certifies the other domain though the
issuance of a certificate which includes the public key of the foreign
domain's top-level CA.

>From a certificate processing standpoint, the ultimate end-user's
certificate is still processed from the bottom up, all the way to the
self-signed certificate that represents the top-level CA in the foreign
domain.  But as a result of the cross-domain certification, and perhaps as a
result of preprocessing all of the cross-domain certificates issued by the
relying party's own top-level CA, the foreign CA's public key can now be
considered trusted, just as though it had been conveyed directly via a
secure out-of-band mechanism.

In addition, all of the existing policy OID and other constraint mechanisms
can be imposed to control the extent to which transitive trust extends to
subordinate CAs and their end-users.

That's at least what I mean by cross-certification.  I'm not quite sure
whether that is what other people have implied by the term. In particular,
my use of the term cross-certification does NOT mean the simple
certification of subordinate CA by a higher-level CA in a simple hierarchy.

Bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
[email-masked]

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross the chasm in two leaps."

>>> Warwick Ford <[email-masked]> 01/05 6:09 AM >>>
Dwight:

In my score-keeping on the terminology issue, I have thus far seen support
for at least two totally different interpretations of the term
"cross-certification", then several different shades of meaning beyond that.

I would contend that "cross-certification" is NOT a well-defined term and
suggest we move to (and clearly define) more precise terms such as
"CA-certification" and "inter-domain certification".  I was giving the list
another few days after the break to make sure that all inputs are in,
before making a concrete proposal.

Regards,
Warwick

At 04:47 PM 1/4/98 -0500, Dwight Arthur wrote:
>On trust and cross certification:
>
>I believe that there is a persistent misperception among technologists
>in this field that an RP will trust someone because of the
>certificate(s) that person can produce. On the contrary I would suggest
>that in many cases the RP represents an enterprise that causes a
>certificate to be granted because of a pre-existing relationship of
>trust. In other words, trust leads to certificates, certificates do not
>lead to trust.
>
>If my enterprise operates a system which we have agreed to make
>accessible to you, it is because we already have some reason to trust
>you, such as a contractual relationship with your employer, or
>collateral that you have deposited with us, or maybe a line of credit
>that you have identified and we have verified.
>
>The certificate plays an important role: it allows my system to validate
>your identity at the time that you access it, and allows you to create
>"digital signatures" as lasting verifiable indications that you commit
>yourself and/or your enterprise to various transactions. In order to
>achieve these benefits without the overhead and expense of personally
>issuing certificates to everyone I trust, I will rely in some cases on
>CAs operated by others to issue the certificates. To be able to validate
>these certificates, I may require some relationship with the external CA
>that may require cross-certification (although there may be other
>simpler ways such as bilateral exchange of keys).
>
>BUT IN NO CASE does the fact that I cross certify an external CA make me
>willing to trust any and all certs issued by that CA. All it does is
>that when I receive a signature from someone I am inclined to trust, it
>provides me with a path for validation of the signture, a method to
>determine that the private key is apparently free of compromise to this
>point, and perhaps a pointer into a directory from which other relevant
>data might be retrieved.
>
>What will, however, be quite useful in the future will be a certificate
>granted by my trade association, or by the CPA firm that audits the
>organization that operates the CA, or maybe some other body stating that
>the CA's CPS meets my trade association's requirements for accreditation
>at some level and that the CPA's scheduled and unscheduled audits
>demonstrate an acceptable degree of operational compliance with the
>policies specified in the CPS. If I find this certificate revoked I will
>definitely consider withholding trust from holders of certificates
>issued by the disaccredited (discredited ?) CA. Despite the fact that I
>have good reason (other than the cert) to trust the subject party, the
>discreditation (?) may signal that the cert is no longer a reliable
>indicator that the person holding it is in fact the person I trust.
>
>Question: it the CPA-to-CA certificate a cross-certificate under the
>recently circulated definitions of terms? I do not recall any mention of
>accreditation.
>
>-Dwight Arthur
>
>
>
>On 12/19/97, Russ Housley wrote:
>> Mack:
>>
>> I understand your issues, and in the banking community, there may be very
>> limited corss certification.
>>
>> I was simply trying to point out that the issuance of a cross certificate
>> from CA_a to CA_b need not cause every certificate issued by CA_b become
>> valid to the community that consider CA_a to be a trusted root.  If there
>> is an easily identified subset of CA_b's community and CA_a trusts CA_b
>> correctly validate the membership in that subset, then cross
certification
>> is an appropriate mechanism.  Trust is the center of this issue.  You
>> correctly point out that bankers like to minimize the number of people
(and
>> orgianizations) that they need to trust.  It greatly simplifies the risk
>> analysis and risk management.
>>
>> Russ
>>
>> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote:
>> >For: IETF-PKIX Mailing list
>> >
>> >From: "Russ Housley"<[email-masked]>
>> >
>> >> 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".))
>> >
>> >An example, the trusted relationships between UNIX nodes.  One can
>> >make the point that the Rhost kind of trust is similar to the
>> >cross-certification model.  Rhost type of trust has done nothing
>> >but get lots of people into lots and lots of trouble.
>> >
>> >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."
>> >
>> >Some people think banks trust each other through their Am Bnks Ass
>> >number (like on the checks).  Anyone who has gotten a bounced check
>> >knows this is not the case.  Knowing the "naming" and "addressing"
>> >(name constraints!) does not increase the level of trust.
>> >
>> >Keeping naming constraints current - or even manageable - is the
>> >full time task for lots of people in the mainframe world.
>> >Keeping that trust (usually in one place - like RACF or ACF2)
>> >is a full time job that often goes horribly wrong.
>> >
>> >
>> >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?
>> >
>> >-   -    -    -    -    -    -    -    -    -    -    -    -
>> >Mack Hicks (415) 278-7230  -- Interactive Banking Division
>> >425 1st St m/s3671, SF CA 94105 <[email-masked]>
>> >
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Mon, 5 Jan 1998 09:55:13 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Bob Jueneman <[email-masked]>
Subject:      Re: [IETF-PKIX] PKIX Part 1: more clarity needed on AltNames
Comments: To: [email-masked]
To: [email-masked]
Status:

Paul, I think that the only reasonable vieww would be to assume that the CA
is binding the public key to the gestalt, i.e., the totality,  of all of the
attributes contained in the certificate, including the DN and any alt names.
 If we start trying to pick apart different meanings for this, that and the
other attrbute when used in combination with other attributes, the
combinatoric explosion of semantic possibilities will quickly become
impossible to deal with.

So I believe that the CA is certifying each name individually, AND as a
group. Remember, it is perfectly possible, meaningful, and correct, for the
CA to issue multiple certificates to the same DN, and/or the same alt name,
for various purposes.

What the legal implications of a digital signature issued by
"[email-masked]" might be would be a different issue.

Bob

>
>>My guess would be that
>>the CA is vouching for the binding between each name in a certificate
>>and the remaining contents of the certificate.
>
>Each name individually, or as a group? "The rest of this cert applies to
>either the DN xxx,yyy or the email address [email-masked]" or "The rest of
>this cert applies to DN xxx,yyy, but only when also thought of as
>[email-masked]"?
>
>>It's probably a
>>distinction without a difference to ask whether the CA is vouching for
>>a binding between name A and name B - if both are bound to the same
>>public key, (in the same cert or in separate otherwise identical certs)
>>then they are implicitly equally valid, and it doesn't make much sense
>>to ask which name is "definitive".
>
>To me, this means "each name individually". I'm fine with this answer (and
>with the other), but neither is clearly stated in the doc.
>
>I can see a reason why "as a group" could be a logical choice. You might
>issue one cert for the combination of a DN of "o=FooCo, cn=Chris Smith" and
>a subjectAltName of "[email-masked]", and a different cert for  DN of
>"o=FooCo, cn=Kim Tong" and a subjectAltName of "[email-masked]". Or,
>the DNs might be the same (with an ou and no cn) but with different
>subjectAltNames.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Date:         Mon, 5 Jan 1998 09:58:13 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] X509 newcomer
To: [email-masked]
Status:

        Hi!

        I work for a router company and I am researching using X509
certificates in our box.  I am just starting to learn about X.509
certificates. I have read the draft draft-ietf-pkix-ipki-part1-06.txt.
I have the ITU-T recommendation for X509 and Amendment 4.

        I have a couple of questions I was hoping someone on this list
could answer.

        1. The draft states it is part of a multipart standard.
What/where are the other parts? Are there any other specifications for
using certificates?

        2. Are there any white papers/drafts/specs/books out there that I can
read which would give me an understanding of the operational procedures
for using X509 certificates?

        3. Any other information a beginner should know?

        Thank you very much for any information you can provide.

        - Gina

--
Gina M. DePlanche               |       OpenROUTE Networks, Inc.
[email-masked]               |       A subsidiary of Proteon, Inc.
(508) 898-2800 x2541            |       9 Technology Drive, Westborough, MA
Fax: (508) 836-5347             |       01581-1799  MailStop #23

Date:         Mon, 5 Jan 1998 08:09:08 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
To: [email-masked]
Status:

Dwight:

In my score-keeping on the terminology issue, I have thus far seen support
for at least two totally different interpretations of the term
"cross-certification", then several different shades of meaning beyond that.

I would contend that "cross-certification" is NOT a well-defined term and
suggest we move to (and clearly define) more precise terms such as
"CA-certification" and "inter-domain certification".  I was giving the list
another few days after the break to make sure that all inputs are in,
before making a concrete proposal.

Regards,
Warwick

At 04:47 PM 1/4/98 -0500, Dwight Arthur wrote:
>On trust and cross certification:
>
>I believe that there is a persistent misperception among technologists
>in this field that an RP will trust someone because of the
>certificate(s) that person can produce. On the contrary I would suggest
>that in many cases the RP represents an enterprise that causes a
>certificate to be granted because of a pre-existing relationship of
>trust. In other words, trust leads to certificates, certificates do not
>lead to trust.
>
>If my enterprise operates a system which we have agreed to make
>accessible to you, it is because we already have some reason to trust
>you, such as a contractual relationship with your employer, or
>collateral that you have deposited with us, or maybe a line of credit
>that you have identified and we have verified.
>
>The certificate plays an important role: it allows my system to validate
>your identity at the time that you access it, and allows you to create
>"digital signatures" as lasting verifiable indications that you commit
>yourself and/or your enterprise to various transactions. In order to
>achieve these benefits without the overhead and expense of personally
>issuing certificates to everyone I trust, I will rely in some cases on
>CAs operated by others to issue the certificates. To be able to validate
>these certificates, I may require some relationship with the external CA
>that may require cross-certification (although there may be other
>simpler ways such as bilateral exchange of keys).
>
>BUT IN NO CASE does the fact that I cross certify an external CA make me
>willing to trust any and all certs issued by that CA. All it does is
>that when I receive a signature from someone I am inclined to trust, it
>provides me with a path for validation of the signture, a method to
>determine that the private key is apparently free of compromise to this
>point, and perhaps a pointer into a directory from which other relevant
>data might be retrieved.
>
>What will, however, be quite useful in the future will be a certificate
>granted by my trade association, or by the CPA firm that audits the
>organization that operates the CA, or maybe some other body stating that
>the CA's CPS meets my trade association's requirements for accreditation
>at some level and that the CPA's scheduled and unscheduled audits
>demonstrate an acceptable degree of operational compliance with the
>policies specified in the CPS. If I find this certificate revoked I will
>definitely consider withholding trust from holders of certificates
>issued by the disaccredited (discredited ?) CA. Despite the fact that I
>have good reason (other than the cert) to trust the subject party, the
>discreditation (?) may signal that the cert is no longer a reliable
>indicator that the person holding it is in fact the person I trust.
>
>Question: it the CPA-to-CA certificate a cross-certificate under the
>recently circulated definitions of terms? I do not recall any mention of
>accreditation.
>
>-Dwight Arthur
>
>
>
>On 12/19/97, Russ Housley wrote:
>> Mack:
>>
>> I understand your issues, and in the banking community, there may be very
>> limited corss certification.
>>
>> I was simply trying to point out that the issuance of a cross certificate
>> from CA_a to CA_b need not cause every certificate issued by CA_b become
>> valid to the community that consider CA_a to be a trusted root.  If there
>> is an easily identified subset of CA_b's community and CA_a trusts CA_b
>> correctly validate the membership in that subset, then cross certification
>> is an appropriate mechanism.  Trust is the center of this issue.  You
>> correctly point out that bankers like to minimize the number of people (and
>> orgianizations) that they need to trust.  It greatly simplifies the risk
>> analysis and risk management.
>>
>> Russ
>>
>> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote:
>> >For: IETF-PKIX Mailing list
>> >
>> >From: "Russ Housley"<[email-masked]>
>> >
>> >> 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".))
>> >
>> >An example, the trusted relationships between UNIX nodes.  One can
>> >make the point that the Rhost kind of trust is similar to the
>> >cross-certification model.  Rhost type of trust has done nothing
>> >but get lots of people into lots and lots of trouble.
>> >
>> >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."
>> >
>> >Some people think banks trust each other through their Am Bnks Ass
>> >number (like on the checks).  Anyone who has gotten a bounced check
>> >knows this is not the case.  Knowing the "naming" and "addressing"
>> >(name constraints!) does not increase the level of trust.
>> >
>> >Keeping naming constraints current - or even manageable - is the
>> >full time task for lots of people in the mainframe world.
>> >Keeping that trust (usually in one place - like RACF or ACF2)
>> >is a full time job that often goes horribly wrong.
>> >
>> >
>> >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?
>> >
>> >-   -    -    -    -    -    -    -    -    -    -    -    -
>> >Mack Hicks (415) 278-7230  -- Interactive Banking Division
>> >425 1st St m/s3671, SF CA 94105 <[email-masked]>
>> >
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Date:         Sun, 4 Jan 1998 16:47:12 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Dwight Arthur <[email-masked]>
Subject:      Re: [IETF-PKIX] NO SUBJECT
Comments: cc: Mack Hicks <[email-masked]>, Russ Housley <[email-masked]>
To: [email-masked]
Status:

On trust and cross certification:

I believe that there is a persistent misperception among technologists
in this field that an RP will trust someone because of the
certificate(s) that person can produce. On the contrary I would suggest
that in many cases the RP represents an enterprise that causes a
certificate to be granted because of a pre-existing relationship of
trust. In other words, trust leads to certificates, certificates do not
lead to trust.

If my enterprise operates a system which we have agreed to make
accessible to you, it is because we already have some reason to trust
you, such as a contractual relationship with your employer, or
collateral that you have deposited with us, or maybe a line of credit
that you have identified and we have verified.

The certificate plays an important role: it allows my system to validate
your identity at the time that you access it, and allows you to create
"digital signatures" as lasting verifiable indications that you commit
yourself and/or your enterprise to various transactions. In order to
achieve these benefits without the overhead and expense of personally
issuing certificates to everyone I trust, I will rely in some cases on
CAs operated by others to issue the certificates. To be able to validate
these certificates, I may require some relationship with the external CA
that may require cross-certification (although there may be other
simpler ways such as bilateral exchange of keys).

BUT IN NO CASE does the fact that I cross certify an external CA make me
willing to trust any and all certs issued by that CA. All it does is
that when I receive a signature from someone I am inclined to trust, it
provides me with a path for validation of the signture, a method to
determine that the private key is apparently free of compromise to this
point, and perhaps a pointer into a directory from which other relevant
data might be retrieved.

What will, however, be quite useful in the future will be a certificate
granted by my trade association, or by the CPA firm that audits the
organization that operates the CA, or maybe some other body stating that
the CA's CPS meets my trade association's requirements for accreditation
at some level and that the CPA's scheduled and unscheduled audits
demonstrate an acceptable degree of operational compliance with the
policies specified in the CPS. If I find this certificate revoked I will
definitely consider withholding trust from holders of certificates
issued by the disaccredited (discredited ?) CA. Despite the fact that I
have good reason (other than the cert) to trust the subject party, the
discreditation (?) may signal that the cert is no longer a reliable
indicator that the person holding it is in fact the person I trust.

Question: it the CPA-to-CA certificate a cross-certificate under the
recently circulated definitions of terms? I do not recall any mention of
accreditation.

-Dwight Arthur

On 12/19/97, Russ Housley wrote:
> Mack:
>
> I understand your issues, and in the banking community, there may be very
> limited corss certification.
>
> I was simply trying to point out that the issuance of a cross certificate
> from CA_a to CA_b need not cause every certificate issued by CA_b become
> valid to the community that consider CA_a to be a trusted root.  If there
> is an easily identified subset of CA_b's community and CA_a trusts CA_b
> correctly validate the membership in that subset, then cross certification
> is an appropriate mechanism.  Trust is the center of this issue.  You
> correctly point out that bankers like to minimize the number of people (and
> orgianizations) that they need to trust.  It greatly simplifies the risk
> analysis and risk management.
>
> Russ
>
> At 01:43 PM 12/17/97 -0800, Mack Hicks wrote:
> >For: IETF-PKIX Mailing list
> >
> >From: "Russ Housley"<[email-masked]>
> >
> >> 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".))
> >
> >An example, the trusted relationships between UNIX nodes.  One can
> >make the point that the Rhost kind of trust is similar to the
> >cross-certification model.  Rhost type of trust has done nothing
> >but get lots of people into lots and lots of trouble.
> >
> >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."
> >
> >Some people think banks trust each other through their Am Bnks Ass
> >number (like on the checks).  Anyone who has gotten a bounced check
> >knows this is not the case.  Knowing the "naming" and "addressing"
> >(name constraints!) does not increase the level of trust.
> >
> >Keeping naming constraints current - or even manageable - is the
> >full time task for lots of people in the mainframe world.
> >Keeping that trust (usually in one place - like RACF or ACF2)
> >is a full time job that often goes horribly wrong.
> >
> >
> >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?
> >
> >-   -    -    -    -    -    -    -    -    -    -    -    -
> >Mack Hicks (415) 278-7230  -- Interactive Banking Division
> >425 1st St m/s3671, SF CA 94105 <[email-masked]>
> >

Date:         Sun, 4 Jan 1998 21:57:40 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
To: [email-masked]
Status:

Alan Buffett
01/04/98 09:57 PM

subscribe

Date:         Sat, 3 Jan 1998 12:22:14 -0700
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: [email-masked]
Subject:      Re: [IETF-PKIX] OCSP Change Request
To: [email-masked]
Status:

Steve,

At 12:56 PM 12/31/97 +0000, Stephen Farrell wrote:
>Hi Mike,
>
>> >1. The standard response message should include a MessageId field. This
>> >allows the client to reference a response previously received which
>> >contains a path deemed unacceptable by the OCSP client. Note that this
>> >does not affect caching of responses. (A HREF would also suffice.)
>>
>> A MessageId field sounds like a useful request extension.  It would however
>> predictably extend the complexity of an OCSP server such it must maintain
>> this state information in addition to, for example, nonce information.
>
>I agree that MessageId is a request extension, but would like it to
>be a standard part of the response. I can see that it introduces some
>state into a server which supports the request extension, however,
>that statefulness is required in order to produce a "next" path
>for the same request.

Would it be sufficient for your needs that MessageID be present in the
response if present in the request?

>
>> >2. The standard response should include the base64 encoding of the entire
>> >path and set of CRLs used to verify the certificate. There is very little
>> >overhead involved as the OCSP server must possess all the relevant
>> >items.
>>
>> I agree the OCSP server may have this information on hand, but its
>> inclusion in the default case would be overkill for environments with
>> well-defined trust paths.  Also, I hadn't seen OCSP as an alternate CRL
>> retrieval mechanism.  In some instances OCSP deployment, there may not be
>> any CRLs to send back.
>
>I guess we're assuming different environments. I'd like that the
>OCSP server and its clients needn't necessarily share well-defined
>trust paths.
>
>How about if the standard response were to contain the full certification
>path used by the OCSP server with a way of using the extension mechanism
>for the client to ask for a copy of the CRLs used?

I would expect in most instances the full certification path would be
redundant information.  SSL and SMIME clients already have means of
receiving (and do receive) this information as an aspect of those security
protocols.  What value is there in receiving what I already have stored on
my machine?

I would like to look at some details of how this is actually going to work
in practice first.  How do you see chaining working?  Are cross
certificates involved?  How is each signature in the chain validated?
>
>> >3. A request extension should be defined which means "give me the next
>> >path for response <<MessageId>>". The response should contain an
>> >alternate certification path (+ CRLs) for the initial request. Of
course the
>> >second response contains a different MessageId so that iteration is
>> >supported. Again this response can be cached without problems. (Or
>> >nothing is needed if a HREF is present.)
>>
>> Might I ask that a draft of this proposed use of OCSP extensibility be
>> drawn up, roughly in line with the briefing of this approach to extensions
>> as discussed in D.C.?
>
>Fair enough. I'll try to do that in the next week or so.

OK.

>
>Meanwhile, I think it'd be worthwhile addressing the issue below on
>the list.
>
>> >In addition I'd note that the OCSP server should be chosen by (e.g.
>> >configured into) the OCSP client. Using a cert extension to name the OCSP
>> >server seems to open up security holes - e.g. it would allow the OCSP
server
>> >to masquerade as a CA to any of its clients..
>>
>> The contents of the certificate would be trusted to the extent the
>> signature on the certificate is trusted.
>
>I guess I basically don't like the situation where a certificate
>contains the location of the OCSP server - it seems too much like making
>the OCSP server into a root CA for the client (unless the OCSP server
>actually is a root CA for the client, which is maybe what you had in
>mind).

An OCSP server is simply another means of acquiring the same information we
would otherwise acquire via CRLs, albeit in a more timely fashion.  It is
to a large degree equivalent to a URL in CRLDistributionPoints locating a
CRL on a particular Web server.

>
>How do you actually see this working? Do you in fact expect that certs
>will contain the location of the OCSP server? If so, how does a client
>know that it should trust the named OCSP server? Maybe I'm just
>misreading the draft, but I'd like to see this spelt out.

The use of AuthorityInfoAccess in end-entity certificate maps to the
well-defined notion of CRLDistributionPoints.  Now, if one doesn't trust
the CRLDistributionPoints asserted by the issuer of a certificate, one is
free to configure one's client to acquire this same information elsewhere.
Similarly, if one doesn't trust the AuthorityInfoAccess content a CA places
into a certificate, local configuration of the client can override.

Mike

Date:         Thu, 1 Jan 1998 15:57:43 -0500
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject:      Re: [IETF-PKIX] Dave's Critical Proposal
To: [email-masked]
Status:

Dave:

At 02:35 PM 12/31/97 -0500, David P. Kemp wrote:
>Warwick (and Bob),
>  You are correct; I did not make a distinction between "recognize"
>and "support".  A hypothetical implementation might recognize a particular
>extension but not, for some reason, claim for compliance purposes to
>support it.  Would the following rule be more suitable?
>
>  "If an implementation claims PKIX-compliant support for a particular
>   extension, where the scope of "support" is specified in the
>   extension definition, then when processing that extension the value
>   of the critical flag SHALL be ignored."
>
>
>In the case of certificatePolicies, "recognize" or "support" means that
>the application must support both the certificatePolicies extension
>{ id-ce 32 } itself and at least one of the policies (specified by
>the policyIdentifier field) contained in the extension.

No, I don't think this solves the whole problem.  I think John is right in
pointing out a design weakness in X.509, with respect to the definition of
the Certificate Policies extension.  Fact of the matter is that "Critical
Certificate Policies" extension and "Noncritical Certificate Policies"
extension really should be two different extension types, since they have
quite different semantics.  Use of the criticality indicator to signify
different behaviour is not a good thing.

In fact, there is an even bigger problem ... I have run across scenarios
where you might want to have both a "Critical Certificate Policies"
extension and a "Noncritical Certificate Policies" extension in the one
cert, and that, of course, is not permitted.

In retrospect, I feel we should have defined two extension types (they can
both have the same syntax) -- say, "Certificate Policies Restriction" and
"Supported Certificate Policies".  I am unsure, however, if it would be a
good thing to try to fix this in X.509 at this stage.  (I can certainly
raise this as a new defect at the January X.500 meeting if the PKIX group
thinks this a good idea.)

Warwick
-------------

>> From: John Pawling <[email-masked]>
>>
>> Dave,
>>
>> X.509, Sec 12.4.3, certificate check, bullet 6 states:
>> "d) If the certificate policies extension is present and is flagged
>> critical, compute the intersection of the policies in that extension and
the
>> authority-constrained-policy-set and put the result as the new value of
>> authority-constrained-policy-set. Check that the intersection of
>> authority-constrained-policy-set and user-constrained-policy-set is
non-empty."
>>
>> If certificate-processing software followed your proposed rule, then it
>> wouldn't be allowed to use the value of the certificate policies extension
>> critical flag as part of the certification path validation process
specified
>> in X.509, Sec 12.4.3.  Therefore, your statement is contradictory to X.509
>> and should not be added to PKIX I.
>
>
>I submit that this contradiction is a red flag that a design inconsistency
>exists in X.509.
>
>A CA has three options with respect to including a particular extension in
>a certificate:  not present, non-critical, and critical.
>
>An application has two options: claim support for an extension or not claim
>support.
>
>The processing of a particular extension by an application may have the
>following outcomes:
>
>                 |           Application:
>      Cert:      | Not supported     Supported
>                 |----------------|-------------
>    absent       |     N/A        |    N/A
>                 |                |
>    non-critical |    Ignore      |  Process
>                 |                |
>    critical     |  Reject cert   |  Process
>
>
>The path validation procedure described in section 12.4.3 introduces
>a third column to processing model:
>
>                 |---------------
>    absent       |     N/A
>                 |
>    non-critical |   Process-A
>                 |
>    critical     |   Process-B
>
>
>The use of a single flag for two independent purposes (managing
>compatibility with non-supporting applications, and selecting different
>processing in supporting applications) sounds like a mistake.
>
>Is there really a need for the phrase "and is flagged critical" to be
>included in certificate checks paragraph d)?  If not, it should be
>removed from X.509.
>
>If there is an operational requirement for both certificatePolicies
>that are used as input to authority-constrained-policy-set, and
>policies that are present in a cert but not used as input to a-c-p-s,
>then two different extensions should be defined to specify the two
>different processing procedures.  My suspicion is that there is no such
>operational requirement.
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------