Subject: [IETF-PKIX] CMP Progression
From: Warwick Ford <[email-masked]>
To: [email-masked]
Date: Fri, 27 Feb 1998 11:49:11 -0800

The CMP editors have completed the editorial changes resulting from Last
Call and IESG member comments, and implemented the document-split as agreed
at the Washington IETF PKIX meeting.  The result is a pair of documents
just posted in the I-D directories as:
     "draft-ietf-pkix-ipki3cmp-07.txt"  and
     "draft-ietf-pkix-crmf-00.txt"

These documents will now be submitted back to the IESG with a
recommendation for publication as RFCs specifying Proposed Standards.

Congratulations to the editors for their relentless efforts to resolve the
issues surrounding these documents!

Warwick

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

Approved-By: [email-masked]
Date:         Thu, 26 Feb 1998 16:52:15 -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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]
Status:

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjYvMTk5OCAxOjIyOjQzUE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjYvMTk5OCAxMjozOTo0NlBNDQpU
bzogSUVURi1QS0lYQExJU1RTLlRBTkRFTS5DT01fYXRfSU5URVJORVQgYXQgWDQwMFBPDQpi
Y2M6IEtFVklOIFNIQVZFUg0KU3ViamVjdDogUmU6IFtJRVRGLVBLSVhdIE9DU1AgQ3VycmVu
dCBTdGF0dXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0NCg==

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authoriz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authoriz"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogcGF1bGhAaW1jLm9yZ19hdF9JTlRFUk5F
VCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov

>>I vote for striking it and saying all responses SHOULD be signed. Further,
>you
>>should add something saying that a client SHOULD check if the response is
>>signed and if it's not, to check a policy for whether or not it should
>trust
>>unsigned responses
>
>But aren't these statements inconsistent?  Noting reliance on a local
>security policy configuration to enforce non-use of unsigned responses
>strongly suggests that OCSP clients implement the capability to do so.  I
>agree that noting the security risks of unsigned responses can make our
>intent more clear.

I don't think they're inconsistent. The first sentence says, in a backward
way,
some valid responses might not be signed. Thus, the second sentence says, in
essence, "because there are two kinds of responses (signed and unsigned), a
client should have a policy for each". Obviously, the policy for signed
responses is to accept them, but the second sentence stresses that there
should
be a policy for unsigned responses. Different wording to the same end would
be
fine with me.

>>>Regarding the notion of an element in the query to specify signed vs.
>>>unsigned responses, I would put it the other way around: the client
SHOULD
>>>be capable of handling either.
>>
>>Nope, I disagree. I think it is fine to create a client that always
rejects
>>unsigned responses.
>
>I would distinguish between a client which is technically incapable of
>handling unsigned responses from one that has a configurable capability to
>not to do so.

Yup.

>  I agree the former is compliant to an interpretation of
>SHOULD.  However, my model here is to compare this capability to an SMIME
UA
>that can only handle signed mail.

We had this argument last year in the S/MIME WG, and it wasn't resolved. My
take on this level of argument is "a client that refuses to do XYZ has a
policy
that says 'don't do XYZ'." If the protocol says "clients {SHOULD|MAY} do
XYZ",
clients that refuse to do XYZ still conform because they have a policy that
says "XYZ is always wrong in this environment".

>>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
>problem
>>with getting two independant interoperable implementations, then you have
>to
>>move to ASN.1. There's already been questions about the extensibility of
>the
>>ABNF.
>
>
>I must disagree.  I have seem more interoperability problems with ASN.1
than
>things such as ABNF, particularly if the problem wasn't an ASN.1-class
>problem in the first place.

Please note that your response ignored mine. This working group has the
option
of deciding whether or not a specification has any chance of getting two
independant interoperable implementations. If it decides that the way you've
specified your protocol will make that hard, the working group can demand
that
your protocol be changed, even if the bits on the wire don't change. Further,

if this working group decides that your ABNF works for OCSP 1 but is
non-extensible, the working group can reject it for that reason alone. I'm
not
advocating this, since I happen to like ABNF more than ASN.1, but it is up
to
the working group, not the draft editor.

>I agree that the list is our most productive tool for closure. That said,
>small focussed groups can and do help improve the pace of the standards
>process. The S/MIME group's efforts are good example.

Good example. The proprietary S/MIME v2 standard moved forward based on
small,
closed group meetings. It took forever to stabalize. The last closed
meeting of
that group (where you and I shared pizza) ended up muddying the waters with
respect to S/MIME v2's certificate handling.

Since S/MIME v3 has come into the IETF, essentially all of the movement has
been made based on the mailing list. Very little new came from the
Washington
DC meeting, and the small ad hoc meeting that happened in San Francisco in
January did help move a few things, but in fact those things have been
mostly
changed since being discussed openly on the mailing list.

I still urge you not to delay OCSP by waiting for the LA meeting. You have
lots
of input for the current draft. A new draft will help get even more input
and
move towards closure (modulo the Entrust submarine patent, of course).

--Paul Hoffman, Director
--Internet Mail Consortium

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov--

Approved-By: [email-masked]
Date:         Thu, 26 Feb 1998 13:22: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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]
Status:

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjYvMTk5OCAxMjozOTo0NlBNDQpU
bzogSUVURi1QS0lYQExJU1RTLlRBTkRFTS5DT01fYXRfSU5URVJORVQgYXQgWDQwMFBPDQpi
Y2M6IEtFVklOIFNIQVZFUg0KU3ViamVjdDogUmU6IFtJRVRGLVBLSVhdIE9DU1AgQ3VycmVu
dCBTdGF0dXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0NCg==

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogcGF1bGhAaW1jLm9yZ19hdF9JTlRFUk5F
VCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov

>>I vote for striking it and saying all responses SHOULD be signed. Further,
>you
>>should add something saying that a client SHOULD check if the response is
>>signed and if it's not, to check a policy for whether or not it should
>trust
>>unsigned responses
>
>But aren't these statements inconsistent?  Noting reliance on a local
>security policy configuration to enforce non-use of unsigned responses
>strongly suggests that OCSP clients implement the capability to do so.  I
>agree that noting the security risks of unsigned responses can make our
>intent more clear.

I don't think they're inconsistent. The first sentence says, in a backward
way,
some valid responses might not be signed. Thus, the second sentence says, in
essence, "because there are two kinds of responses (signed and unsigned), a
client should have a policy for each". Obviously, the policy for signed
responses is to accept them, but the second sentence stresses that there
should
be a policy for unsigned responses. Different wording to the same end would
be
fine with me.

>>>Regarding the notion of an element in the query to specify signed vs.
>>>unsigned responses, I would put it the other way around: the client
SHOULD
>>>be capable of handling either.
>>
>>Nope, I disagree. I think it is fine to create a client that always
rejects
>>unsigned responses.
>
>I would distinguish between a client which is technically incapable of
>handling unsigned responses from one that has a configurable capability to
>not to do so.

Yup.

>  I agree the former is compliant to an interpretation of
>SHOULD.  However, my model here is to compare this capability to an SMIME
UA
>that can only handle signed mail.

We had this argument last year in the S/MIME WG, and it wasn't resolved. My
take on this level of argument is "a client that refuses to do XYZ has a
policy
that says 'don't do XYZ'." If the protocol says "clients {SHOULD|MAY} do
XYZ",
clients that refuse to do XYZ still conform because they have a policy that
says "XYZ is always wrong in this environment".

>>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
>problem
>>with getting two independant interoperable implementations, then you have
>to
>>move to ASN.1. There's already been questions about the extensibility of
>the
>>ABNF.
>
>
>I must disagree.  I have seem more interoperability problems with ASN.1
than
>things such as ABNF, particularly if the problem wasn't an ASN.1-class
>problem in the first place.

Please note that your response ignored mine. This working group has the
option
of deciding whether or not a specification has any chance of getting two
independant interoperable implementations. If it decides that the way you've
specified your protocol will make that hard, the working group can demand
that
your protocol be changed, even if the bits on the wire don't change. Further,

if this working group decides that your ABNF works for OCSP 1 but is
non-extensible, the working group can reject it for that reason alone. I'm
not
advocating this, since I happen to like ABNF more than ASN.1, but it is up
to
the working group, not the draft editor.

>I agree that the list is our most productive tool for closure. That said,
>small focussed groups can and do help improve the pace of the standards
>process. The S/MIME group's efforts are good example.

Good example. The proprietary S/MIME v2 standard moved forward based on
small,
closed group meetings. It took forever to stabalize. The last closed
meeting of
that group (where you and I shared pizza) ended up muddying the waters with
respect to S/MIME v2's certificate handling.

Since S/MIME v3 has come into the IETF, essentially all of the movement has
been made based on the mailing list. Very little new came from the
Washington
DC meeting, and the small ad hoc meeting that happened in San Francisco in
January did help move a few things, but in fact those things have been
mostly
changed since being discussed openly on the mailing list.

I still urge you not to delay OCSP by waiting for the LA meeting. You have
lots
of input for the current draft. A new draft will help get even more input
and
move towards closure (modulo the Entrust submarine patent, of course).

--Paul Hoffman, Director
--Internet Mail Consortium

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov--

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 26 Feb 1998 09:35:27 -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] OCSP Current Status
To: [email-masked]
Status:

>>I vote for striking it and saying all responses SHOULD be signed. Further,
>you
>>should add something saying that a client SHOULD check if the response is
>>signed and if it's not, to check a policy for whether or not it should
>trust
>>unsigned responses
>
>But aren't these statements inconsistent?  Noting reliance on a local
>security policy configuration to enforce non-use of unsigned responses
>strongly suggests that OCSP clients implement the capability to do so.  I
>agree that noting the security risks of unsigned responses can make our
>intent more clear.

I don't think they're inconsistent. The first sentence says, in a backward
way,
some valid responses might not be signed. Thus, the second sentence says, in
essence, "because there are two kinds of responses (signed and unsigned), a
client should have a policy for each". Obviously, the policy for signed
responses is to accept them, but the second sentence stresses that there
should
be a policy for unsigned responses. Different wording to the same end would be
fine with me.

>>>Regarding the notion of an element in the query to specify signed vs.
>>>unsigned responses, I would put it the other way around: the client SHOULD
>>>be capable of handling either.
>>
>>Nope, I disagree. I think it is fine to create a client that always rejects
>>unsigned responses.
>
>I would distinguish between a client which is technically incapable of
>handling unsigned responses from one that has a configurable capability to
>not to do so.

Yup.

>  I agree the former is compliant to an interpretation of
>SHOULD.  However, my model here is to compare this capability to an SMIME UA
>that can only handle signed mail.

We had this argument last year in the S/MIME WG, and it wasn't resolved. My
take on this level of argument is "a client that refuses to do XYZ has a
policy
that says 'don't do XYZ'." If the protocol says "clients {SHOULD|MAY} do XYZ",
clients that refuse to do XYZ still conform because they have a policy that
says "XYZ is always wrong in this environment".

>>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
>problem
>>with getting two independant interoperable implementations, then you have
>to
>>move to ASN.1. There's already been questions about the extensibility of
>the
>>ABNF.
>
>
>I must disagree.  I have seem more interoperability problems with ASN.1 than
>things such as ABNF, particularly if the problem wasn't an ASN.1-class
>problem in the first place.

Please note that your response ignored mine. This working group has the option
of deciding whether or not a specification has any chance of getting two
independant interoperable implementations. If it decides that the way you've
specified your protocol will make that hard, the working group can demand that
your protocol be changed, even if the bits on the wire don't change. Further,
if this working group decides that your ABNF works for OCSP 1 but is
non-extensible, the working group can reject it for that reason alone. I'm not
advocating this, since I happen to like ABNF more than ASN.1, but it is up to
the working group, not the draft editor.

>I agree that the list is our most productive tool for closure. That said,
>small focussed groups can and do help improve the pace of the standards
>process. The S/MIME group's efforts are good example.

Good example. The proprietary S/MIME v2 standard moved forward based on small,
closed group meetings. It took forever to stabalize. The last closed
meeting of
that group (where you and I shared pizza) ended up muddying the waters with
respect to S/MIME v2's certificate handling.

Since S/MIME v3 has come into the IETF, essentially all of the movement has
been made based on the mailing list. Very little new came from the Washington
DC meeting, and the small ad hoc meeting that happened in San Francisco in
January did help move a few things, but in fact those things have been mostly
changed since being discussed openly on the mailing list.

I still urge you not to delay OCSP by waiting for the LA meeting. You have
lots
of input for the current draft. A new draft will help get even more input and
move towards closure (modulo the Entrust submarine patent, of course).

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By: [email-masked]
Date:         Thu, 26 Feb 1998 09:26: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-crmf-00.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           : Certificate Request Message Format
        Author(s)       : D. Solo, C. Adams, D. Kemp, M. Myers
        Filename        : draft-ietf-pkix-crmf-00.txt
        Pages           : 18
        Date            : 25-Feb-98

This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'',
and ''MAY'' in this document (in uppercase, as shown)
are to be interpreted as described in RFC 2119.

Please send comments on this document to the [email-masked]
mail list.

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-crmf-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-00.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-crmf-00.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 2 (EuSn/CSOm) (0001EC20)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-crmf-00.txt";
        site="ftp.ietf.org";
        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-crmf-00.txt (AURL/Arch) (0001EC21)
Content-Type: text/plain
Content-ID:     <[email-masked]>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 26 Feb 1998 09:50: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

>From: Michael Myers <[email-masked]>
>
> >From: Paul Hoffman / IMC <[email-masked]>
> >
> > True, but I think that this argument argues even more strongly for the
> > removal
> > of marketing words like "efficiently and rapidly" and "timely" from the
> > spec.
>
> We probably have a wordsmithing problem if that's the case since we need to
> state the existence of the timeliness requirement.  OCSP owes its existence
> to this requirement.  My point being that this draft is not a design spec
> intending to constrain implementors so as to ensure they develop products
> that will deliver timely service.

There certainly is a timeliness requirement.  OCSP has been proposed
and advertised as a solution that can satisfy that requirement,
whereas others have expressed skepticism backed up by preliminary
analysis indicating that OCSP alone is not a scalable solution, and
that CRLs fetched in online queries would present far less computational
and communication burden on a large CA than would OCSP.

The wordsmithed text must either describe where in a system
architecture OCSP is suited for use and where it is less well suited,
or it must confine itself to technical interoperability
specifications only and make no advertising claims about timeliness.

Entrust has proposed a timely revocation solution based on CRLs using
the patented crlDistributionPoint method.  I believe that an equally
efficient and more dynamically adjustable solution can be
constructed using online queries for non-patented delta-CRLs over a
monolithic subscriber base.  Both of these methods may use OCSP
for the final end-user to local-status-server link, but OCSP is
useless without a method for efficiently distributing timely
status information away from the CA.

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 25 Feb 1998 18:24: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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>

>At 08:59 PM 2/23/98 -0700, Michael Myers wrote:
>>OCSP is an interface specification; it exists to ensure interoperability
>>between two endpoints.  The quality of service delivered by those
endpoints
>>is more a matter of system engineering.
>
>True, but I think that this argument argues even more strongly for the
removal
>of marketing words like "efficiently and rapidly" and "timely" from the
spec.

We probably have a wordsmithing problem if that's the case since we need to
state the existence of the timeliness requirement.  OCSP owes its existence
to this requirement.  My point being that this draft is not a design spec
intending to constrain implementors so as to ensure they develop products
that will deliver timely service.

>
>>Provision for unsigned responses was in response to an observation that
>>within an enterprise, one may already be operating with a secure enclave
and
>>so have little need of the overhead of signature production.  If you and
>>others agree that this provision is unwise, I have no problem striking it
>>from the draft.
>
>I vote for striking it and saying all responses SHOULD be signed. Further,
you
>should add something saying that a client SHOULD check if the response is
>signed and if it's not, to check a policy for whether or not it should
trust
>unsigned responses

But aren't these statements inconsistent?  Noting reliance on a local
security policy configuration to enforce non-use of unsigned responses
strongly suggests that OCSP clients implement the capability to do so.  I
agree that noting the security risks of unsigned responses can make our
intent more clear.

>
>>Regarding the notion of an element in the query to specify signed vs.
>>unsigned responses, I would put it the other way around: the client SHOULD
>>be capable of handling either.
>
>Nope, I disagree. I think it is fine to create a client that always rejects
>unsigned responses.

I would distinguish between a client which is technically incapable of
handling unsigned responses from one that has a configurable capability to
not to do so.  I agree the former is compliant to an interpretation of
SHOULD.  However, my model here is to compare this capability to an SMIME UA
that can only handle signed mail.

>
>>>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>>>would seem more appropriate, and general purpose.
>>
>>In short, yes. This topic was discussed and closed at D.C.  It enables
ease
>>of implementation.
>
>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
problem
>with getting two independant interoperable implementations, then you have
to
>move to ASN.1. There's already been questions about the extensibility of
the
>ABNF.

I must disagree.  I have seem more interoperability problems with ASN.1 than
things such as ABNF, particularly if the problem wasn't an ASN.1-class
problem in the first place.

>
>On a separate note, I do not think this discussion should wait until the LA
>meeting. That's more than a month away. Put out another draft and keep
>discussing it here. The IETF is designed to do most of its work on mailing
>lists (even ones with no working archives, as this one is), and use the
>face-to-face meetings for finalizing work and correcting misguided drafts.
>Unless you are lablelling this draft as misguided already, there is no need
to
>postpone the discussion on this list.

I agree that the list is our most productive tool for closure. That said,
small focussed groups can and do help improve the pace of the standards
process. The S/MIME group's efforts are good example.

>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Wed, 25 Feb 1998 16:48: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

We are in the process of producing the next version of this draft.  It
should be available by the end of this week, and certainly before the
submission deadline in a couple of weeks.

        Robert.

>----------
>From:  Rich Ankney[SMTP:[email-masked]]
>Sent:  Wednesday, February 25, 1998 10:18 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
>
>So what's the status of the notary protocol?  I'm inclined to use
>that, rather than OCSP, for any important (high-value) apps.
>
>Regards,
>Rich
>
>----------
>> From: Robert Zuccherato <[email-masked]>
>> To: [email-masked]
>> Subject: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
>> Date: Wednesday, February 25, 1998 9:09 AM
>>
>> I submitted this message to the list yesterday, but I haven't seen it
>> show up yet.  My apologies to anyone who receives it twice.
>>
>[snip]
>

Approved-By:  Rich Ankney <[email-masked]>
Date:         Wed, 25 Feb 1998 10:18: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: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

So what's the status of the notary protocol?  I'm inclined to use
that, rather than OCSP, for any important (high-value) apps.

Regards,
Rich

----------
> From: Robert Zuccherato <[email-masked]>
> To: [email-masked]
> Subject: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
> Date: Wednesday, February 25, 1998 9:09 AM
>
> I submitted this message to the list yesterday, but I haven't seen it
> show up yet.  My apologies to anyone who receives it twice.
>
[snip]

Approved-By: [email-masked]
Date:         Wed, 25 Feb 1998 09:09: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: Robert Zuccherato <[email-masked]>
Subject:      [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

I submitted this message to the list yesterday, but I haven't seen it
show up yet.  My apologies to anyone who receives it twice.

>----------
>From:  Robert Zuccherato
>Sent:  Tuesday, February 24, 1998 11:46 AM
>To:    'IETF X.509-based public key infrastructure mailing list'
>Cc:    [email-masked]'
>Subject:       RE: [IETF-PKIX] OCSP Current Status
>
>Mike;
>
>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Monday, February 23, 1998 10:59 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP Current Status
>
>You raise a number of very good points which I hope to resolve at the LA
>IETF.   These are my views.  In the interests of expediency, I suggest  we
>convene an ad-hoc subgroup at LA to deal with these issues and deliver to
>PKIX our joint resolution.
>
>I think that there are more than just a few people who are interested in this
>draft.  Meeting in the back room of a smokey bar doesn't allow for full,
>public discussion of these ideas.  Why don't we try and resolve these issues
>on the list.
>
>-----Original Message-----
>From: Robert Zuccherato <[email-masked]>
>To: 'IETF X.509-based public key infrastructure mailing list'
>
>>1) You continue to maintain that OCSP gives "timely" status information
>>and does so "efficiently and rapidly".  I guess this statement depends
>>on what your definition of "timely" is.  It seems to me however, that
>>there is a tradeoff.  In order to get current status information, the
>>responder must produce only fresh responses and sign each one.  This
>>does not seem to be efficient and rapid, and certainly isn't scalable.
>>In order to be scalable, the responder must use pre-produced responses
>>and chaching.  This doesn't provide timely status information (at least
>>no more than using a CRL).  I think the document should make this choice
>>clear.  Many people still believe that OCSP can give them both current
>>status information and scalability.
>
>OCSP is an interface specification; it exists to ensure interoperability
>between two endpoints.  The quality of service delivered by those endpoints
>is more a matter of system engineering.   By analogy, consider that some
>Internet throughput needs are met by a 28K modem while other environments
>need, say, an OC3-size pipe.  In either case, TCP/IP flows across the wire
>to accomplish the interface.
>
>Presently, the draft talks about "timely" status information, being able to
>"efficiently and rapidly determine status information", using caching and
>response pre-production, using a nonce, etc.  It doesn't mention that using a
>nonce to produce timely status information does not allow efficient and rapid
>status information to be provided to a large number of people.  It doesn't
>mention that using caching and response pre-production doesn't allow timely
>status information.  These are not only system engineering problems, they are
>security issues.  This service has been advertised as providing up-to-date
>revocation status, but it cannot do so under all circumstances.  This should
>be made clear to all those using the service.
>
>>2) The draft still has no explanation of how one is to get the
>>verification key for the OCSP responder.  The document should clearly
>>explain that there are (at least) two options.  You can have the key
>>installed, but then you cannot revoke it.  If you run into trouble with
>>the responder's key, it is the same as losing the CA's key, you have to
>>start over.  Or, you can issue the OCSP responder a certificate and
>>revocation is possible by placing the certificate on an ARL.
>
>Here again I would assign this scope to a systems-level key management
>document. The diversity of options at this layer of the architecture
>strongly suggests there can be no one standard way of managing an OCSP
>responder's key(s).   Further, there's no reason that OCSP should operate in
>isolation of CRLs.  Again, I would leave this up to the PKI systems
>engineers to choose the configuration that best meets their local security
>policy needs.  Bearing in mind that the primary intent of revocation in this
>case would be to inhibit further use of a private key, one very effective
>way of revoking a responder's key is to take away its PCMCIA token, assuming
>that particulary key management decision was made by the system architect.
>
>I agree that there doesn't have to be one standard way to manage an OCSP
>responder's key(s).  Implementer's must be made aware, however, that if you
>choose one option, revocation is not possible, and if you choose another
>option, revocation is possible, but you must place the responder's key on an
>ARL.  This is a basic security requirement for an OCSP responder and should
>be discussed in the document, regardless of some future systems-level key
>management document.
>
>>3) The server still responds with VALID and INVALID, but certificates
>>are only valid with respect to a specific certification path and
>>explicitly stated policy.  There is a policy extension, but there is no
>>way to pass in a certification path for which validity is to be
>>determined.  Also, it appears to me that the responder doesn't have to
>>pay attention to the policy extension.  The service as presently
>>designed, really indicates whether or not a certificate is revoked, and
>>the responses should reflect this.
>
>May I ask that you provide a link-by-link example of how such chains would
>work in practice, starting with the public key needed to validate the
>signature on the subject certificate?  By "link" I mean "x-signs-y".
>
>Surely I don't have to explain how to do certificate path validation.  In
>order to validate a certificate, both a certificate path and a policy OID are
>required.  Policy mappings will not allow this to be done one certificate at
>a time.  If you do not want to allow both a certificate chain and policy OID
>in the request, then the best you can do is to determine the revocation
>status of the certificate.  If you want to determine certificate validity,
>then you must give the responder both the certificate chain and policy.
>
>>4) Unsigned error messages are still allowed.  This, of course, allows
>>anyone to produce responses to an OCSP request.  The statement is made
>>"It is reasonable to ask for error messages to be signed to address this
>>vulnerability."  I do not see how to ask for only signed responses in
>>the request however.
>
>Provision for unsigned responses was in response to an observation that
>within an enterprise, one may already be operating with a secure enclave and
>so have little need of the overhead of signature production.  If you and
>others agree that this provision is unwise, I have no problem striking it
>from the draft.  I do fear however that such a practice would evolve anyway,
>so we should also keep in mind  the utility of maintaining the provision as
>a means of achieving some level of interoperability.
>
>Again, since this is a security issue, the fact that unsigned messages should
>only be used within a secure enclave should be explicitly mentioned in the
>draft.  Otherwise, signed error messages must be used.
>
>Regarding the notion of an element in the query to specify signed vs.
>unsigned responses, I would put it the other way around: the client SHOULD
>be capable of handling either.  I doubt that an organization operating a
>responder that produces signed responses (ostensibly for the purposes of
>non-repudiation) would be willing upon request to produce any other type.
>Similarly, an organization that choses for reasons of expediency to not
>sign responses would most likely not be well positioned to selectively
>produce signed responses.
>
>Presently, the draft allows a server to produce all signed, all unsigned, or
>any combination of signed/unsigned error responses.  Your comment in the
>third paragraph of Section 5 seems to indicate that signed messages can be
>requested by the client.  Unless we specify exactly when signed/unsigned
>responses can be used (for example in a secure enclave, as discussed above),
>we should provide the mechanism that you allude to.  We should allow clients
>to request a signed error message in situations where it is not clear what
>they will get back, and they want to be sure someone isn't just sending back
>the unsigned response.
>
>>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>>would seem more appropriate, and general purpose.
>
>In short, yes. This topic was discussed and closed at D.C.  It enables ease
>of implementation.
>
>See other messages on the list, posted by others, on this topic.
>
>       Robert.
>
>
>

Approved-By: [email-masked]
Date:         Tue, 24 Feb 1998 14:39:15 -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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]
Status:

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjQvMTk5OCAxOjUwOjQ4UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBBQkEgSVNDIE1lZXRpbmcs
IEFwcmlsDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogd2ZvcmRAdmVyaXNpZ24uY29tX2F0X0lO
VEVSTkVUIGF0IFg0MDBQTw0KDQo=

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov

For information...

>INFORMATION SECURITY COMMITTEE MEETING NOTICE
>
>5-7 April, 1998 - Patent & Trademark Office (PTO), Crystal City
>  (Wash., D.C. metro area)
>
>                                       Please correspond with:
>                                               Michael S. Baum, Esq.
>                                               One Alewife Center, Suite
350
>                                               Cambridge, MA 02140 USA
>                                               V: +1 617.661.1234
>                                               F: +1 617.661.0716
>                                               N: [email-masked]
>
>
>Dear Committee Member and Prospective Members:
>
>You are cordially invited to participate in a meeting of the Information
>Security Committee, Section of Science & Technology, American Bar
>Association, on Sunday-Tuesday, April 5-7, 1998, at the PTO in Crystal
>City (a quick cab ride from National Airport). The Committee will
>continue its advancement of public key infrastructure legal and control
>issues, and will include further work on CA accreditation, commercial
>key recovery guidelines, PKI evidentiary issues, certificate policy,
>and user liability, among other matters.
>
>Consistent with Section policy, ISC meeting participants must be members
>of both the ABA and the ABA Section of Science and Technology. Please
>contact Ann Kowalsky, Manager Section of Science & Technology, at ABA
>headquarters in Chicago by phone: +1 (312) 988.5599, fax: +1 (312)
>988.5628, or email: [email-masked] for membership information.
>You can become a paid member of the ABA and the ISC at the April 5-7
>meeting -- and associate ABA membership is available for non-lawyers.
>
>Meeting details appear below. I look forward to seeing you at the PTO.
>
>Sincerely,
>
>Michael S. Baum
>Chair, Information Security Committee
>Section of Science & Technology, ABA
>
>
>
>------------------------------------------------------------------------
>
>INFORMATION SECURITY COMMITTEE
>Section of Science & Technology, ABA
>5-7 April 1998
>
>Proposed Agenda (in extended sessions, breaks will be taken as needed.)
>
>
>5 April 1998 - Sunday (casual attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters (note: all times
>are "local")
>0900 - 0930 Introductions, meeting logistics, general announcements
>0930 - 1030 Working Group updates
>1030 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Dave W. Fillingham, NSA, Office of Network
>Security Infrastructure
>
>1300 - 1700 WG breakouts
>1700 - ????  Watering hole discussions; possible continuation of WG
meetings
>
>6 April 1998 - Monday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Commissioner of the PTO (tentative)
>1300 - 1700 WG breakouts
>1700 -  ???? Watering hole discussions; possible continuation of WG
meetings
>
>7 April 1998 - Wednesday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Representative from the OMB (tentative)
>1300 - 1500 WG wrap-ups
>1500 - 1600 WG presentations
>1600 - 1630 Path Forward, close
>
>Additional proposed agenda items and speakers should be emailed to
>Michael Baum ([email-masked]).
>
>
>------------------------------------------------------------------------
>
>
>Information Security Committee - PTO/Crystal City
>Electronic Commerce Division, Section of Science and Technology
>
>MEETING DETAILS - Work Groups
>5-7 April 1998
>
>
>Members are urged to participate in at least one of the Working Groups
>that will be presenting/meeting during the ISC's meeting. Please contact
>Ruven Schwartz, committee vice chair, or a working group co-chair
>directly, for further information.
>
>**Accreditation Working Group
>Contacts: Bill Burr ([email-masked])
>Charlie Merrill, Esq. ([email-masked])
>Lynn McNulty ([email-masked])
>
>The Accreditation Work Group (About 50 technologists and attorneys in
>three sections: Process, Technical Standards, and Legal and Business
>Standards) will continue work on its draft document, "Guidelines for
>Certificate Policies and Accreditation Criteria", with a view toward
>distributing a draft on the Internet for industry comments shortly
thereafter.
>
>
>**Certificate Services Agreements Working Group
>Contacts: Kevin O'Neill ([email-masked])
>Stephen Wu ([email-masked])
>
>The Certification Services Agreements Work Group is charged with writing
>"Certification Services Agreements," which is an outgrowth of the ISC's
>accreditation and cert. policies activity. The purpose of "Certification
>Services Agreements" is to assist the authors of a certificate policy
>definition, certification practice statement, subscriber agreement,
>relying party agreement, or other agreement relating to certification
>services by providing model forms and a menu of alternative legal
>wording for use in particular clauses of such documents. The document
>will include comments and annotations to the Guidelines for Certificate
>Policies and Accreditation Criteria. The group will review the current
>draft of the document and discuss plans for further development.
>
>
>**Comparative Law Working Group
>Contacts: Serge Parisien, Esq. ([email-masked])
>Suzanne Thibodeau ([email-masked])
>
>The Comparative Law work group will continue its exploration of the
>requirements for PKI in civil law and other legal jurisdictions. It will
>also continue efforts to harmonize legal infrastructure with the common
>law.
>
>
>**Digital Signatures Laws & Regulations Working Group
>Contacts: Kenneth Allen, Esq. ([email-masked])
>David Danner, Esq. ([email-masked])
>Dan Greenwood, Esq. ([email-masked])
>
>The Legislative and Regulatory Working Group will hold its periodic
>conference call, to discuss updates to legislation and regulation
>regarding electronic authentication. The Leg./Reg. Working Group
>will continue/finalize its study of a need for model regulations to
>support the electronic and digital signature legislative laws enacted in
>several states to date.
>
>
>**Evidentiary Working Group
>Contacts: Gary Fresen, Esq. ([email-masked])
>Serge Parisien, Esq. ([email-masked])
>
>The Evidentiary Work Group will continue its drafting of the judicial
>tutorial (a tutorial for judges to admit technology into evidence) and
>report on its coordination activities with record management standards
>authorities. The working group members will also assist the other
>working groups on their evidentiary issues.
>
>
>**Global Trade Working Group
>Contacts: Joseph Alhadeff, Esq. ([email-masked])
>Lisa Kinard ([email-masked])
>Linda Macintosh ([email-masked])
>
>The Global Trade Work Group identifies and collaborates with trade
>groups whose work influences secure global trade and reports critical
>issues back to the ISC. The WG is developing an overall framework to
>structure and analyze secure trade issues; and is preparing an issues
>statement concerning cooperation between legal, business and
>technological professionals to reduce secure electronic international
>trade barriers.
>
>
>**Key Recovery Working Group (KRWG)
>Contacts: Emily Frye, Esq. ([email-masked])
>Dwight Olson, Esq. ([email-masked])
>Randy Sabett, Esq. ([email-masked])
>
>The KRWG monitors proposed legislation and regulations, both here
>and abroad, that address key recovery, and offers comments where
>appropriate. The KRWG's major initiative documents the
>framework and operation of a key recovery center. Work is in the
>advanced outline stage and will focus on fleshing out draft text.
>
>
>**Liability Working Group
>Contacts: Maureen Adamache, Esq. ([email-masked])
>Elise Reed, Esq. ([email-masked])
>
>The Liability Work Group will continue its work with the Accreditation
>Group on the liability issues, including preparing liability policy
>statements and also suitable clauses for inclusion in PKI/CA-user and
>PKI/CA cross-certification agreements. It will also continue its
>analyses of the liability of application software providers, and for
>other (non-digital signature, non-confidentiality encryption)
>applications of public key cryptography. Finally, it will consider
>technical methods of solving the legal problem of binding relying
>parties.
>
>
>
>------------------------------------------------------------------------
>
>LOGISTICS
>
>Recommended attire: Sunday - casual; Monday/Tuesday - business attire.
>
>First-time participants planning to attend the April 5-7 meeting: Please
>contact Ruven Schwartz, ISC ViceChair, at 612-687-8095 or
>[email-masked] to coordinate meeting work-product
contributions.
>
>Meeting Location:  Patent & Trademark Office, Crystal Park Building 1,
>Suite 601
>(2011 Crystal Drive, Crystal City, Virginia).  Note: this is NOT where we
>last met at the PTO.
>
>Meals: TBD
>
>Lodging: tbd
>
>RSVP: Please confirm your intention to participate to Ann Kowalsky,
>Section Manager, Section of Science and Technology
>([email-masked]) as soon as possible.
>
>See you at the PTO.
>
>
>                                           ***
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov--

Approved-By:  Warwick Ford <[email-masked]>
Date:         Tue, 24 Feb 1998 14:04:24 -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] ABA ISC Meeting, April
To: [email-masked]
Status:

For information...

>INFORMATION SECURITY COMMITTEE MEETING NOTICE
>
>5-7 April, 1998 - Patent & Trademark Office (PTO), Crystal City
>  (Wash., D.C. metro area)
>
>                                       Please correspond with:
>                                               Michael S. Baum, Esq.
>                                               One Alewife Center, Suite 350
>                                               Cambridge, MA 02140 USA
>                                               V: +1 617.661.1234
>                                               F: +1 617.661.0716
>                                               N: [email-masked]
>
>
>Dear Committee Member and Prospective Members:
>
>You are cordially invited to participate in a meeting of the Information
>Security Committee, Section of Science & Technology, American Bar
>Association, on Sunday-Tuesday, April 5-7, 1998, at the PTO in Crystal
>City (a quick cab ride from National Airport). The Committee will
>continue its advancement of public key infrastructure legal and control
>issues, and will include further work on CA accreditation, commercial
>key recovery guidelines, PKI evidentiary issues, certificate policy,
>and user liability, among other matters.
>
>Consistent with Section policy, ISC meeting participants must be members
>of both the ABA and the ABA Section of Science and Technology. Please
>contact Ann Kowalsky, Manager Section of Science & Technology, at ABA
>headquarters in Chicago by phone: +1 (312) 988.5599, fax: +1 (312)
>988.5628, or email: [email-masked] for membership information.
>You can become a paid member of the ABA and the ISC at the April 5-7
>meeting -- and associate ABA membership is available for non-lawyers.
>
>Meeting details appear below. I look forward to seeing you at the PTO.
>
>Sincerely,
>
>Michael S. Baum
>Chair, Information Security Committee
>Section of Science & Technology, ABA
>
>
>
>------------------------------------------------------------------------
>
>INFORMATION SECURITY COMMITTEE
>Section of Science & Technology, ABA
>5-7 April 1998
>
>Proposed Agenda (in extended sessions, breaks will be taken as needed.)
>
>
>5 April 1998 - Sunday (casual attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters (note: all times
>are "local")
>0900 - 0930 Introductions, meeting logistics, general announcements
>0930 - 1030 Working Group updates
>1030 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Dave W. Fillingham, NSA, Office of Network
>Security Infrastructure
>
>1300 - 1700 WG breakouts
>1700 - ????  Watering hole discussions; possible continuation of WG meetings
>
>6 April 1998 - Monday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Commissioner of the PTO (tentative)
>1300 - 1700 WG breakouts
>1700 -  ???? Watering hole discussions; possible continuation of WG meetings
>
>7 April 1998 - Wednesday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Representative from the OMB (tentative)
>1300 - 1500 WG wrap-ups
>1500 - 1600 WG presentations
>1600 - 1630 Path Forward, close
>
>Additional proposed agenda items and speakers should be emailed to
>Michael Baum ([email-masked]).
>
>
>------------------------------------------------------------------------
>
>
>Information Security Committee - PTO/Crystal City
>Electronic Commerce Division, Section of Science and Technology
>
>MEETING DETAILS - Work Groups
>5-7 April 1998
>
>
>Members are urged to participate in at least one of the Working Groups
>that will be presenting/meeting during the ISC's meeting. Please contact
>Ruven Schwartz, committee vice chair, or a working group co-chair
>directly, for further information.
>
>**Accreditation Working Group
>Contacts: Bill Burr ([email-masked])
>Charlie Merrill, Esq. ([email-masked])
>Lynn McNulty ([email-masked])
>
>The Accreditation Work Group (About 50 technologists and attorneys in
>three sections: Process, Technical Standards, and Legal and Business
>Standards) will continue work on its draft document, "Guidelines for
>Certificate Policies and Accreditation Criteria", with a view toward
>distributing a draft on the Internet for industry comments shortly
thereafter.
>
>
>**Certificate Services Agreements Working Group
>Contacts: Kevin O'Neill ([email-masked])
>Stephen Wu ([email-masked])
>
>The Certification Services Agreements Work Group is charged with writing
>"Certification Services Agreements," which is an outgrowth of the ISC's
>accreditation and cert. policies activity. The purpose of "Certification
>Services Agreements" is to assist the authors of a certificate policy
>definition, certification practice statement, subscriber agreement,
>relying party agreement, or other agreement relating to certification
>services by providing model forms and a menu of alternative legal
>wording for use in particular clauses of such documents. The document
>will include comments and annotations to the Guidelines for Certificate
>Policies and Accreditation Criteria. The group will review the current
>draft of the document and discuss plans for further development.
>
>
>**Comparative Law Working Group
>Contacts: Serge Parisien, Esq. ([email-masked])
>Suzanne Thibodeau ([email-masked])
>
>The Comparative Law work group will continue its exploration of the
>requirements for PKI in civil law and other legal jurisdictions. It will
>also continue efforts to harmonize legal infrastructure with the common
>law.
>
>
>**Digital Signatures Laws & Regulations Working Group
>Contacts: Kenneth Allen, Esq. ([email-masked])
>David Danner, Esq. ([email-masked])
>Dan Greenwood, Esq. ([email-masked])
>
>The Legislative and Regulatory Working Group will hold its periodic
>conference call, to discuss updates to legislation and regulation
>regarding electronic authentication. The Leg./Reg. Working Group
>will continue/finalize its study of a need for model regulations to
>support the electronic and digital signature legislative laws enacted in
>several states to date.
>
>
>**Evidentiary Working Group
>Contacts: Gary Fresen, Esq. ([email-masked])
>Serge Parisien, Esq. ([email-masked])
>
>The Evidentiary Work Group will continue its drafting of the judicial
>tutorial (a tutorial for judges to admit technology into evidence) and
>report on its coordination activities with record management standards
>authorities. The working group members will also assist the other
>working groups on their evidentiary issues.
>
>
>**Global Trade Working Group
>Contacts: Joseph Alhadeff, Esq. ([email-masked])
>Lisa Kinard ([email-masked])
>Linda Macintosh ([email-masked])
>
>The Global Trade Work Group identifies and collaborates with trade
>groups whose work influences secure global trade and reports critical
>issues back to the ISC. The WG is developing an overall framework to
>structure and analyze secure trade issues; and is preparing an issues
>statement concerning cooperation between legal, business and
>technological professionals to reduce secure electronic international
>trade barriers.
>
>
>**Key Recovery Working Group (KRWG)
>Contacts: Emily Frye, Esq. ([email-masked])
>Dwight Olson, Esq. ([email-masked])
>Randy Sabett, Esq. ([email-masked])
>
>The KRWG monitors proposed legislation and regulations, both here
>and abroad, that address key recovery, and offers comments where
>appropriate. The KRWG's major initiative documents the
>framework and operation of a key recovery center. Work is in the
>advanced outline stage and will focus on fleshing out draft text.
>
>
>**Liability Working Group
>Contacts: Maureen Adamache, Esq. ([email-masked])
>Elise Reed, Esq. ([email-masked])
>
>The Liability Work Group will continue its work with the Accreditation
>Group on the liability issues, including preparing liability policy
>statements and also suitable clauses for inclusion in PKI/CA-user and
>PKI/CA cross-certification agreements. It will also continue its
>analyses of the liability of application software providers, and for
>other (non-digital signature, non-confidentiality encryption)
>applications of public key cryptography. Finally, it will consider
>technical methods of solving the legal problem of binding relying
>parties.
>
>
>
>------------------------------------------------------------------------
>
>LOGISTICS
>
>Recommended attire: Sunday - casual; Monday/Tuesday - business attire.
>
>First-time participants planning to attend the April 5-7 meeting: Please
>contact Ruven Schwartz, ISC ViceChair, at 612-687-8095 or
>[email-masked] to coordinate meeting work-product
contributions.
>
>Meeting Location:  Patent & Trademark Office, Crystal Park Building 1,
>Suite 601
>(2011 Crystal Drive, Crystal City, Virginia).  Note: this is NOT where we
>last met at the PTO.
>
>Meals: TBD
>
>Lodging: tbd
>
>RSVP: Please confirm your intention to participate to Ann Kowalsky,
>Section Manager, Section of Science and Technology
>([email-masked]) as soon as possible.
>
>See you at the PTO.
>
>
>                                           ***
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 24 Feb 1998 09:34: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Attachment converted: Lutefisk:Re- [IETF-PKIX] OCSP Current St (TEXT/MPGP) (0001EBF5)

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 24 Feb 1998 09:33: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

At 08:59 PM 2/23/98 -0700, Michael Myers wrote:
>OCSP is an interface specification; it exists to ensure interoperability
>between two endpoints.  The quality of service delivered by those endpoints
>is more a matter of system engineering.

True, but I think that this argument argues even more strongly for the removal
of marketing words like "efficiently and rapidly" and "timely" from the spec.

>Provision for unsigned responses was in response to an observation that
>within an enterprise, one may already be operating with a secure enclave and
>so have little need of the overhead of signature production.  If you and
>others agree that this provision is unwise, I have no problem striking it
>from the draft.

I vote for striking it and saying all responses SHOULD be signed. Further, you
should add something saying that a client SHOULD check if the response is
signed and if it's not, to check a policy for whether or not it should trust
unsigned responses.

>Regarding the notion of an element in the query to specify signed vs.
>unsigned responses, I would put it the other way around: the client SHOULD
>be capable of handling either.

Nope, I disagree. I think it is fine to create a client that always rejects
unsigned responses.

>>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>>would seem more appropriate, and general purpose.
>
>In short, yes. This topic was discussed and closed at D.C.  It enables ease
>of implementation.

If this group thinks that chosing ABNF instead of ASN.1 will lead to a problem
with getting two independant interoperable implementations, then you have to
move to ASN.1. There's already been questions about the extensibility of the
ABNF.

On a separate note, I do not think this discussion should wait until the LA
meeting. That's more than a month away. Put out another draft and keep
discussing it here. The IETF is designed to do most of its work on mailing
lists (even ones with no working archives, as this one is), and use the
face-to-face meetings for finalizing work and correcting misguided drafts.
Unless you are lablelling this draft as misguided already, there is no need to
postpone the discussion on this list.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 24 Feb 1998 09:43:00 -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] OCSP comments
Comments: To: [email-masked]
To: [email-masked]
Status:

Mike,

I heartily endorse Ambarish's arguments, and would vote for ASN.1. I have
already talked about the need for one extension (to handle
confirmation of the certificate status for a particular digital signature,
and to allow for an insurance mechanisms as well), and I strongly
suspect that there will be others. ASN.1 has clearly demonstrated the ability
to handle extensions in the form of new attributes, to handle support for
multi-byte alphabets for supporting internationalization, etc. Although other
competing metalanguages might offer the same things (but always "more or less"),
I don't want to have to go through the intellectual effort of walking
through the entire spec to convince myself that that is true.

>From my perspective as an architect, I would strongly prefer one uniform
way of handling all of the functionality involved in PKI, and that clearly should
be ASN.1 driven.  I'll be happy to leave the "light-weight" protocols to the SPKI folks,
and/or to the LDAP proponents, for I believe that experience has shown that
when they get through, the protocol is no longer light weight, but it isn't
easily extensible either.

We have a considerable investment in ASN.1 tools, compiler, etc.,
as I assume almost anyone who is serious in this business does. The last
thing I want to do is have to do is either write or buy yet another toolkit,
probably with incompatible interfaces, another entire library of functions
necessary to support it, etc.. It just causes enormous code bloat, adds that
much more to the pile that has to be documented, maintained, etc. And converting
certificate elements back and forth from ASN.1 to any other format just
means more code that has to be written, more latency, and lots more chances for
errors and ambiguities to creep in. For high performance applications such as firewalls
and virtual private networks, where all of the code has to be resident in RAM
in order to be instantly available, this additional functionality on top of the ASN.1
that is already required translates into real dollars and cents hardware costs.

I don't want to draw a line in the sand and say that if OCSP isn't written in ASN.1
we won't support it, but it would be a considerable factor in our decision -- that
and some of the other things it doesn't yet do.

I also support Peter Sylvester's argument that OCSP should be divorced from http.
It shouldn't matter what the underlying protocol is -- I can imagine DAM, LDAP,
RPCs, and other potential transport layer mechanisms being used, for example.
On the other hand, if http is used, an ASN.1 request/response is no more difficult
to handle than say a MPEG-2 image.  It's just a bucket of bits.

Bob

>
>
>>>> Ambarish Malpani <[email-masked]> 02/23 7:54 PM >>>
>Hi Mike,
>    I am definintely not religious about ASN.1 and I know we have talked
>in the past about leaving ASN.1 out of OCSP, to allow it to stay a
>lightweight protocol. However, after reading the latest version of the
>OCSP spec and spending some time thinking about it, I really think we
>should use ASN.1 in OCSP. Here are the reasons:
>
>1. The syntax of both queries and responses in OCSP is getting quite
>complicated. Inventing a new way of describing this syntax is both more
>error prone (might introduce bugs/ambiguities in trying to describe the
>protocol - for examples, see below) and more difficult to implement (you
>need to write a new parser that now treats another set of characters (&,
>/, # etc) as separators.
>
>2. Adding extensions to this new description is going to be much more
>difficult - it is very likely that new extensions will break parsers
>written for older versions - a problem that has already been addressed
>for ASN.1 because people have done it many times before.
>
>3. There are multiple encoding steps, where things are first DER
>encoded, then base64 encoded, then URL encode. If the request needs to
>be signed, the signature is computed on this encoded data and *then*
>needs to be base64 and URL encoded -- a much more bug prone process.
>
>Here are some bugs/issues from an initial read of the spec:
>
>1. In the query, there is an extra '/'
>    i.e. a query will look like: http://<servername>//ocsp/ver/1...
>
>2. In responses, there is a bug in the specification of a cert id, where
>you send back the base64 encoding of the cert id in the response, even
>though the base64 encoding can contain a '/'. You would need to escape
>the forward slashes in the encoding to prevent parsers from mistaking it
>for a separator. (see Page 6 and 7)
>
>3. There are a bunch of %x22 kind of statements (is that a standard
>format that I don't know of)?
>
>4. In signed requests, where the whole cert is provided, is the cert
>included in the data to be signed?
>
>5. I am  assuming all signatures are computed *after* URL encoding of
>the previous part of the request and then base64 encoded and then URL
>encoded. Is this correct? Is the signature then DER/base64/URL encoded?
>
>
>Regards,
>Ambarish
>
>--
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                              (650) 849-9880
>ValiCert, Inc.                                  [email-masked]
>3160 W. Bayshore Road                         http://www.valicert.com
>Palo Alto, CA 94303

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
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."

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Tue, 24 Feb 1998 11:50:42 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

A little nit-picking:

- There is a need for an 'pretty online' service to find out the
  status of certificates. One might consider to define this service
  without referencing to http, and then selecting http
  as 'use of lower layers'.
  In the actual text these things seems to be tied together.

- The mentioned keyword/value pairs might be given as such
  (using whatever textual means to describe it) but not in
  the rather implicit way through its encoding in an http request.

- The text should be written in ASCII or ISO-latin-1 (not with
  quotes coming from some well known word-processing-$ware.)

- In the description of a request, there is a definition of
  'time' which is not used anywhere?

Peter Sylvester -- EdelWeb France

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Feb 1998 20:59: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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
Comments: To: Robert Zuccherato <[email-masked]>
To: [email-masked]
Status:

Rob,

You raise a number of very good points which I hope to resolve at the LA
IETF.   These are my views.  In the interests of expediency, I suggest  we
convene an ad-hoc subgroup at LA to deal with these issues and deliver to
PKIX our joint resolution.

Mike

-----Original Message-----
From: Robert Zuccherato <[email-masked]>
To: 'IETF X.509-based public key infrastructure mailing list'

>Mike;
>
>I have read through your latest OCSP draft and unfortunately I still
>have some problems with it.
>
>1) You continue to maintain that OCSP gives "timely" status information
>and does so "efficiently and rapidly".  I guess this statement depends
>on what your definition of "timely" is.  It seems to me however, that
>there is a tradeoff.  In order to get current status information, the
>responder must produce only fresh responses and sign each one.  This
>does not seem to be efficient and rapid, and certainly isn't scalable.
>In order to be scalable, the responder must use pre-produced responses
>and chaching.  This doesn't provide timely status information (at least
>no more than using a CRL).  I think the document should make this choice
>clear.  Many people still believe that OCSP can give them both current
>status information and scalability.

OCSP is an interface specification; it exists to ensure interoperability
between two endpoints.  The quality of service delivered by those endpoints
is more a matter of system engineering.   By analogy, consider that some
Internet throughput needs are met by a 28K modem while other environments
need, say, an OC3-size pipe.  In either case, TCP/IP flows across the wire
to accomplish the interface.

>
>2) The draft still has no explanation of how one is to get the
>verification key for the OCSP responder.  The document should clearly
>explain that there are (at least) two options.  You can have the key
>installed, but then you cannot revoke it.  If you run into trouble with
>the responder's key, it is the same as losing the CA's key, you have to
>start over.  Or, you can issue the OCSP responder a certificate and
>revocation is possible by placing the certificate on an ARL.

Here again I would assign this scope to a systems-level key management
document. The diversity of options at this layer of the architecture
strongly suggests there can be no one standard way of managing an OCSP
responder's key(s).   Further, there's no reason that OCSP should operate in
isolation of CRLs.  Again, I would leave this up to the PKI systems
engineers to choose the configuration that best meets their local security
policy needs.  Bearing in mind that the primary intent of revocation in this
case would be to inhibit further use of a private key, one very effective
way of revoking a responder's key is to take away its PCMCIA token, assuming
that particulary key management decision was made by the system architect.

>
>3) The server still responds with VALID and INVALID, but certificates
>are only valid with respect to a specific certification path and
>explicitly stated policy.  There is a policy extension, but there is no
>way to pass in a certification path for which validity is to be
>determined.  Also, it appears to me that the responder doesn't have to
>pay attention to the policy extension.  The service as presently
>designed, really indicates whether or not a certificate is revoked, and
>the responses should reflect this.

May I ask that you provide a link-by-link example of how such chains would
work in practice, starting with the public key needed to validate the
signature on the subject certificate?  By "link" I mean "x-signs-y".

>4) Unsigned error messages are still allowed.  This, of course, allows
>anyone to produce responses to an OCSP request.  The statement is made
>"It is reasonable to ask for error messages to be signed to address this
>vulnerability."  I do not see how to ask for only signed responses in
>the request however.

Provision for unsigned responses was in response to an observation that
within an enterprise, one may already be operating with a secure enclave and
so have little need of the overhead of signature production.  If you and
others agree that this provision is unwise, I have no problem striking it
from the draft.  I do fear however that such a practice would evolve anyway,
so we should also keep in mind  the utility of maintaining the provision as
a means of achieving some level of interoperability.

Regarding the notion of an element in the query to specify signed vs.
unsigned responses, I would put it the other way around: the client SHOULD
be capable of handling either.  I doubt that an organization operating a
responder that produces signed responses (ostensibly for the purposes of
non-repudiation) would be willing upon request to produce any other type.
Similarly, an organization that choses for reasons of expediency to not
sign responses would most likely not be well positioned to selectively
produce signed responses.

>
>5) In the request the cert-id is a SHA-1 hash of the Issuer DN and cert
>serial number, in the response it is an MD5 hash.  Could we be
>consistent?

Yes, the MD5 in the response should have been a SHA-1 specification.

>
>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>would seem more appropriate, and general purpose.

In short, yes. This topic was discussed and closed at D.C.  It enables ease
of implementation.

>
>Regards,
>
> Robert Zuccherato.
>

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Feb 1998 20:31:02 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Dave,

It it very likely the case that an OCSP query would not be translated into
ASN.1 at the server.  Rather, I would expect a more direct translation to,
say, SQL or some other database interface.

Mike

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, February 23, 1998 1:54 PM
Subject: Re: [IETF-PKIX] OCSP Current Status

> . . . .
>Admittedly, OCSP itself isn't so complex as to absolutely require
>ASN.1.  But applications are already capable of using ASN.1 to break
>out the contents of a certificate, otherwise they wouldn't need OCSP at
>all.  Translating certificate fields from ASN.1 to EBNF in OCSP
>clients, and then translating again at the server to compare against
>ASN.1 CRLs sounds error prone and inflexible.  A more consistent
>approach would avoid the translation problem.  Isn't "unnecessary"
>internal consistency better than internal inconsistency?
>

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 23 Feb 1998 18:54: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP comments
To: [email-masked]
Status:

Hi Mike,
    I am definintely not religious about ASN.1 and I know we have talked
in the past about leaving ASN.1 out of OCSP, to allow it to stay a
lightweight protocol. However, after reading the latest version of the
OCSP spec and spending some time thinking about it, I really think we
should use ASN.1 in OCSP. Here are the reasons:

1. The syntax of both queries and responses in OCSP is getting quite
complicated. Inventing a new way of describing this syntax is both more
error prone (might introduce bugs/ambiguities in trying to describe the
protocol - for examples, see below) and more difficult to implement (you
need to write a new parser that now treats another set of characters (&,
/, # etc) as separators.

2. Adding extensions to this new description is going to be much more
difficult - it is very likely that new extensions will break parsers
written for older versions - a problem that has already been addressed
for ASN.1 because people have done it many times before.

3. There are multiple encoding steps, where things are first DER
encoded, then base64 encoded, then URL encode. If the request needs to
be signed, the signature is computed on this encoded data and *then*
needs to be base64 and URL encoded -- a much more bug prone process.

Here are some bugs/issues from an initial read of the spec:

1. In the query, there is an extra '/'
    i.e. a query will look like: http://<servername>//ocsp/ver/1...

2. In responses, there is a bug in the specification of a cert id, where
you send back the base64 encoding of the cert id in the response, even
though the base64 encoding can contain a '/'. You would need to escape
the forward slashes in the encoding to prevent parsers from mistaking it
for a separator. (see Page 6 and 7)

3. There are a bunch of %x22 kind of statements (is that a standard
format that I don't know of)?

4. In signed requests, where the whole cert is provided, is the cert
included in the data to be signed?

5. I am  assuming all signatures are computed *after* URL encoding of
the previous part of the request and then base64 encoded and then URL
encoded. Is this correct? Is the signature then DER/base64/URL encoded?

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 23 Feb 1998 17:59:30 -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] Defining Terms w.r.t. Cross Cert...
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Hi Denis,

>----------
>From:  Denis Pinkas[SMTP:[email-masked]]
>Sent:  Monday, February 23, 1998 7:50 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>> Allowing for WG members in different time zones, I propose to wait until
>> Wednesday for responses to the above definition.
>
>My time zone was quite different since I was in a different week zone
>(in the Alps, for a very good skying last week).  :-)

Unfortunately, your time zone was so different that you missed the
opportunity for responses (I ended up waiting until Friday instead of
Wednesday to submit the document in order to give as many people as
possible a chance to post their input).  However, thank you for your
comments; I have a couple of comments in return.

>> "cross-certification request":  One CA requests issuance of a
>> cross-certificate from another CA.
>
>    I think that "CA-Certificate request" and "Cross-certificate
>    request" should be defined instead. This is what we describe
>    in terms of the protocols.

I tend to think of "cross-certification" as the process of issuing a
cross-certificate (just as "certification" is the process of issuing a
certificate).  Therefore, I can't say that I see much/any difference
between "cross-certification request" and "cross-certificate request"
(with respect to this protocol).  If there is a distinction, it seems to
me that it argues in favour of "cross-certification request", since the
purpose of this message in CMP is to ask the other side to *issue* a
cross-certificate (whereas the semantics of the term "cross-certificate
request" can conceivably mean "please give me any cross-certificate that
you happen to have lying around").  In other words, the name
"cross-certificate request" does not necessarily imply issuance, which
seems like a shortcoming to me.

>> When it is necessary to distinguish more finely, the following terms
>> may be used: a cross-certificate is called an "inter-domain
>> cross-certificate" if the subject and issuer CAs belong to different
>> administrative domains; it is called an "intra-domain
>> cross-certificate" otherwise.
>
>    The term "cross-certificate" means that some boundary is
>    being crossed. Using the more general term, it is a domain
>    crossing. If you are in the same domain there is no crossing.

The difficulty is that not everyone views the term "cross" in the sense
of crossing a boundary.  It is legitimate to think of a
"cross-certificate" as an object existing "across" two CAs (irrespective
of administrative domains).

>    I would thus only see a cross-certificate being equivalent to
>    an "inter-domain certificate".

Note 2 in the definition was put there specifically to accommodate this
view and to ensure that it is an acceptable view within the scope of
PKIX while not ruling out the possibility that other views may exist.
This seems to me to be the fairest way to come to agreement on a term
that means quite different things to different people (and sometimes to
the same people at different points in time :-).

The problem is that this definition (a fairly minor part of the CMP
spec.) has been holding up the document for some time.  PKIX needs to
get some RFCs issued (last time I looked we still didn't have any!).  I
tried to find a compromise that I felt would satisfy the largest number
of people on this list (in order to reach "rough consensus"),
recognizing that it is impossible to satisfy everyone.  I think that
Warwick's modification to the text I posted meets this criterion.
[Don't forget, by the way, that the WG is only trying to achieve a
Proposed Standard here; there's lots of time to re-visit this definition
if we ever want to progress to Draft Standard or Internet Standard.  I
don't see much benefit in continuing to hold up the PKIX documents (CMP
and the Profiles spec.) over this issue...]

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

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Mon, 23 Feb 1998 16:12:19 -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] OCSP Current Status
To: [email-masked]
Status:

Just a small plea:

Could we PLEASE avoid an ASN.1 flame war?

        Phill

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Feb 1998 16:20: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Todd,
  I agree with everything you say, but can't you please say it
in normal ASCII text?

I believe the consensus is that IETF mail lists should be text-only;
not everyone uses MIME.

Regards,
  dpk

Approved-By: [email-masked]
Date:         Mon, 23 Feb 1998 12:18: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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Rich Salz wrote:

> >I also support this ASN.1 Notation. ASN.1 is virtually the standard everywhere,
> >lets stick with it to keep the interoperability of our various standards an
> >easier thing to accomplish.
>
> Those who want OCSP recast as an ASN.1/DER protocol are missing one of
> its key points.  OCSP is an "http application" and designed to provide
> a low-cost way for the http-speaking world to find out the status of
> a certificate.

No Rich, I understand this very clearly - Its always been an issue with me that we
don't need to manage the overhead or possible liability of the interoperability of
three bazillion different certificate access/management methods and especially the
standards for certificate validation and revocation.

> OCSP is basically "hitching a ride" on top of the
> ubiquity and reachability of port 80; defining some new binary protocol
> and getting a new reserved port assigned would raise all sorts of practical
> deployment barriers for the sake of unnecessary internal consistency.
>         /r$

While I agree that the intent behind the OCSP effort is valuable I wonder if it
introduces yet another worm to the bigger issue of Certificate and CRL management.
Personally I disagree with your opinion that this is "unnecessary internal
consistency". I think that the consistancey is the key for building an
interoperability framework and that is the only way Business is going to adopt our
technologies for their use models. Futher that we are fighting an uphill political
battle with respect to the three bazillion different standards,  until we come to
grips with this concept.

--
Todd's Latest Rant --
---------------------
"UCC, Commercial Law and numerous international Treaties are the
basis of the 'transaction requirements'. Technologies must adapt
to support them without making them conform to the technologies..."

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 2 (TEXT/R*ch) (0001EBE2)
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 2 (????/----) (0001EBE3)

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Feb 1998 15:32:44 -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] OCSP Current Status
To: [email-masked]
Status:

> From: Rich Salz <[email-masked]>
>
> Those who want OCSP recast as an ASN.1/DER protocol are missing one of
> its key points.  OCSP is an "http application" and designed to provide
> a low-cost way for the http-speaking world to find out the status of
> a certificate.   OCSP is basically "hitching a ride" on top of the
> ubiquity and reachability of port 80; defining some new binary protocol
> and getting a new reserved port assigned would raise all sorts of practical
> deployment barriers for the sake of unnecessary internal consistency.
>         /r$

Defining OCSP using ASN.1 may raise the practical deployment barrier
of not fitting the "http mindset"; some people are not familiar with
it, are not fluent in reading it, or do not have the libraries in place
to process it.

But claiming that it is "some new binary protocol" requiring a port
other than 80 to be assigned is not a credible objection. Why do
you believe ASN.1/DER data is any less http-compatible than .jpg data?

The real deployment barrier is getting C, java, perl, tcl, and python
modules that can parse ASN.1 structures as easily as comma-separated
lists of name=value pairs. Those modules only have to be written once
by toolkit suppliers; the majority of application programmers just
use what's provided in their favorite libraries or scripting engines.

ASN.1 is desirable not just for the sake of internal consistency, but
as a foundation suitable for building more capable applications
more easily.  Programming is easier in a compiled language than
in machine language, even though it is reasonably difficult to write
a compiler.  Cryptography is easier with a bignum library than without.
Similarly, ASN.1 tools will ultimately enable the development of
more capable http applications than is practical with current
techniques.

Admittedly, OCSP itself isn't so complex as to absolutely require
ASN.1.  But applications are already capable of using ASN.1 to break
out the contents of a certificate, otherwise they wouldn't need OCSP at
all.  Translating certificate fields from ASN.1 to EBNF in OCSP
clients, and then translating again at the server to compare against
ASN.1 CRLs sounds error prone and inflexible.  A more consistent
approach would avoid the translation problem.  Isn't "unnecessary"
internal consistency better than internal inconsistency?

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Mon, 23 Feb 1998 11:04:01 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
Comments: To: [email-masked]
To: [email-masked]
Status:

At 04:50 PM 2/23/98 -0800, Denis Pinkas wrote, in part:

>    The term "cross-certificate" means that some boundary is
>    being crossed. Using the more general term, it is a domain
>    crossing. If you are in the same domain there is no crossing.
>    I would thus only see a cross-certificate being equivalent to
>    an "inter-domain certificate".
>
>I would then attempt to explain the difference between a
>"Cross-certificate request" and a "CA-Certificate request".
>
>A "Cross-Certificate request" is done by an already established CA
>wishing to be certified by an already established CA from a different
>(administrative) domain.
>
>A "CA-Certificate request" is done either by a new CA wishing to be
>established by CA from the same (administrative) domain or by an already
>established CA, wishing, to be certified by an already established CA
>from a different (administrative) domain.

I can see why the term "cross-certificate" is problematic;)

With due respect, you say that "cross" implies a domain crossing, and yet
your second example allows "CA-Certificate request" to cross domains.  Is
this a "cut-and-paste" error?

Two additional questions/points:

By what (universal) means are the parties, especially in different
"administrative domains," to detemine that one or the other is an
"already established CA?"  This is the first time, I believe, that
this has been offered as a distinguishing characteristic.

I note that in both examples given, the requesting party is asking to
be certified in a subordinating role.  That is, (speaking naively) they
ask that the keys they certify be accepted (validate) further up the
chain, making them acceptable to users (relying parties) in the requestee's
domain.  Earlier, there was talk in the other direction, wherein I want
the users in my domain to accept certificates rooted in another domain,
and I effect this by unilaterally countersigning the root key of this
foreign domain.

The central point of all of this, I thought, was to allow the elements
of any such chain to be gathered automatically, in any case.

Thanks.  ___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Rich Salz <[email-masked]>
Date:         Mon, 23 Feb 1998 13:57:17 -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: Rich Salz <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

>I also support this ASN.1 Notation. ASN.1 is virtually the standard everywhere,
>lets stick with it to keep the interoperability of our various standards an
>easier thing to accomplish.

Those who want OCSP recast as an ASN.1/DER protocol are missing one of
its key points.  OCSP is an "http application" and designed to provide
a low-cost way for the http-speaking world to find out the status of
a certificate.   OCSP is basically "hitching a ride" on top of the
ubiquity and reachability of port 80; defining some new binary protocol
and getting a new reserved port assigned would raise all sorts of practical
deployment barriers for the sake of unnecessary internal consistency.
        /r$

Approved-By: [email-masked]
Date:         Mon, 23 Feb 1998 09:57: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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

<html><HTML>
&nbsp;Robert Zuccherato wrote:
<BLOCKQUOTE TYPE=CITE>Mike;

<P>I have read through your latest OCSP draft and unfortunately I still
<BR>have some problems with it.

<P>1) You continue to maintain that OCSP gives "timely" status information
<BR>and does so "efficiently and rapidly".&nbsp; I guess this statement
depends
<BR>on what your definition of "timely" is.&nbsp; It seems to me however,
that
<BR>there is a tradeoff.&nbsp; In order to get current status information,
the
<BR>responder must produce only fresh responses and sign each one.&nbsp;
This
<BR>does not seem to be efficient and rapid, and certainly isn't scalable.
<BR>In order to be scalable, the responder must use pre-produced responses
<BR>and chaching.&nbsp; This doesn't provide timely status information
(at least
<BR>no more than using a CRL).&nbsp; I think the document should make this
choice
<BR>clear.&nbsp; Many people still believe that OCSP can give them both
current
<BR>status information and scalability.</BLOCKQUOTE>
Robert's right as far as I can tell. OCSP suffers from the time distortion
issue and as such needs to have some framework for formalizing the revocation
window or period...
<BLOCKQUOTE TYPE=CITE>&nbsp;

<P>2) The draft still has no explanation of how one is to get the
<BR>verification key for the OCSP responder.&nbsp; The document should
clearly
<BR>explain that there are (at least) two options.</BLOCKQUOTE>

<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>
You can have the key installed, but then you cannot revoke it.&nbsp; If
you run into trouble with the responder's key, it is the same as losing
the CA's key, you have to start over.</LI>
</UL>
</BLOCKQUOTE>
In this case you might want to create a "pending state" as well so that
certificate transactions can be escrow based until such time as they are
actually validated. This might unburden some of the cycle-based pain of
restarting the whole transaction from scratch.
<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>
Or, you can issue the OCSP responder a certificate and revocation is possible
by placing the certificate on an ARL.</LI>
</UL>
3) The server still responds with VALID and INVALID, but certificates
<BR>are only valid with respect to a specific certification path and
<BR>explicitly stated policy.&nbsp; There is a policy extension, but there
is no
<BR>way to pass in a certification path for which validity is to be
<BR>determined.&nbsp; Also, it appears to me that the responder doesn't
have to
<BR>pay attention to the policy extension.&nbsp; The service as presently
<BR>designed, really indicates whether or not a certificate is revoked,
and
<BR>the responses should reflect this.

<P>4) Unsigned error messages are still allowed.&nbsp; This, of course,
allows
<BR>anyone to produce responses to an OCSP request.&nbsp; The statement
is made
<BR>"It is reasonable to ask for error messages to be signed to address
this
<BR>vulnerability."&nbsp; I do not see how to ask for only signed responses
in
<BR>the request however.

<P>5) In the request the cert-id is a SHA-1 hash of the Issuer DN and cert
<BR>serial number, in the response it is an MD5 hash.&nbsp; Could we be
<BR>consistent?

<P>6) Do we really have to do this using ABNF grammar and HTTP?&nbsp; ASN.1
<BR>would seem more appropriate, and general purpose.</BLOCKQUOTE>
I also support this ASN.1 Notation. ASN.1 is virtually the standard everywhere,
lets stick with it to keep the interoperability of our various standards
an easier thing to accomplish.&nbsp;

<P>Todd
<BR>&nbsp;</HTML>

</html>Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 1 (TEXT/R*ch) (0001EBD5)
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 1 (????/----) (0001EBD6)

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Feb 1998 16:50:20 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

> Allowing for WG members in different time zones, I propose to wait until
> Wednesday for responses to the above definition.

My time zone was quite different since I was in a different week zone
(in the Alps, for a very good skying last week).  :-)

As many, I appreciate the efforts to converge but I would like that we
focuss on the text changes that we need. Some of the proposals and
wordings are going beyond what is necessary.

I would appreciate that we discuss text changes in their context. There
are very few places where the term cross-certificate or
cross-certification are used. Could we see the old text and a revised
text, before making a new full BIG draft available ?

Re-using the text from Warwick, I will now make a few technical
comments, that go in a different direction:

> "cross-certification request":  One CA requests issuance of a
> cross-certificate from another CA.

    I think that "CA-Certificate request" and "Cross-certificate
    request" should be defined instead. This is what we describe
    in terms of the protocols.

> For the purposes of this standard, the following terms are defined.
> A "cross-certificate" is a certificate in which the subject CA and
> the issuer CA are distinct and SubjectPublicKeyInfo contains a
> verification key (i.e., the certificate has been issued for the
> subject CA's signing key pair).

    The above definition should apply to a CA-Certificate instead.

> When it is necessary to distinguish more finely, the following terms
> may be used: a cross-certificate is called an "inter-domain
> cross-certificate" if the subject and issuer CAs belong to different
> administrative domains; it is called an "intra-domain
> cross-certificate" otherwise.

    The term "cross-certificate" means that some boundary is
    being crossed. Using the more general term, it is a domain
    crossing. If you are in the same domain there is no crossing.
    I would thus only see a cross-certificate being equivalent to
    an "inter-domain certificate".

I would then attempt to explain the difference between a
"Cross-certificate request" and a "CA-Certificate request".

A "Cross-Certificate request" is done by an already established CA
wishing to be certified by an already established CA from a different
(administrative) domain.

A "CA-Certificate request" is done either by a new CA wishing to be
established by CA from the same (administrative) domain or by an already
established CA, wishing, to be certified by an already established CA
from a different (administrative) domain.

The protocol is the same. I hope this may help and not add more
confusion. :-)

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Mon, 23 Feb 1998 14:20:39 +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] protocolEncKey
To: [email-masked]
Status:

In relation to the draft 'Certificate Management Protocols'.

I have a question about the component 'protocolEncKey' present various
places, e.g. in InitReqContent

InitReqContent ::= SEQUENCE {
      protocolEncKey      [0] SubjectPublicKeyInfo  OPTIONAL,
      fullCertTemplates       FullCertTemplates
  }

Can someone tell me, where (i.e. in which applications) and why this
component is present?

The actual draft 'Certificate Mangement Protocols' explains in details
the various intended use of
 structures in a PKIX (e.g. a PKI message consists of header, body,
optional protection etc.,
 the body is intended for message-specific inofmation, the header is
intended for ..., very good!).
But when reading the document, it happens that one cannot see the use of
a specific component
(e.g. the component 'protocolEncKey' above).

Is there any further readings available?

- Jakob

Approved-By: [email-masked]
Date:         Fri, 20 Feb 1998 15:10: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
Comments: cc: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Mike;

I have read through your latest OCSP draft and unfortunately I still
have some problems with it.

1) You continue to maintain that OCSP gives "timely" status information
and does so "efficiently and rapidly".  I guess this statement depends
on what your definition of "timely" is.  It seems to me however, that
there is a tradeoff.  In order to get current status information, the
responder must produce only fresh responses and sign each one.  This
does not seem to be efficient and rapid, and certainly isn't scalable.
In order to be scalable, the responder must use pre-produced responses
and chaching.  This doesn't provide timely status information (at least
no more than using a CRL).  I think the document should make this choice
clear.  Many people still believe that OCSP can give them both current
status information and scalability.

2) The draft still has no explanation of how one is to get the
verification key for the OCSP responder.  The document should clearly
explain that there are (at least) two options.  You can have the key
installed, but then you cannot revoke it.  If you run into trouble with
the responder's key, it is the same as losing the CA's key, you have to
start over.  Or, you can issue the OCSP responder a certificate and
revocation is possible by placing the certificate on an ARL.

3) The server still responds with VALID and INVALID, but certificates
are only valid with respect to a specific certification path and
explicitly stated policy.  There is a policy extension, but there is no
way to pass in a certification path for which validity is to be
determined.  Also, it appears to me that the responder doesn't have to
pay attention to the policy extension.  The service as presently
designed, really indicates whether or not a certificate is revoked, and
the responses should reflect this.

4) Unsigned error messages are still allowed.  This, of course, allows
anyone to produce responses to an OCSP request.  The statement is made
"It is reasonable to ask for error messages to be signed to address this
vulnerability."  I do not see how to ask for only signed responses in
the request however.

5) In the request the cert-id is a SHA-1 hash of the Issuer DN and cert
serial number, in the response it is an MD5 hash.  Could we be
consistent?

6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
would seem more appropriate, and general purpose.

Regards,

        Robert Zuccherato.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 19 Feb 1998 09:52: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on ESS and Privacy Marks
To: [email-masked]
Status:

For those who haven't been following the following discussion on the
S/MIME list, the "[0] IMPLICIT UTF8String" syntax would have similar
advantages wherever UTF8String is used in the next versions of
the Cert Profile and CMP.

> To: [email-masked]
> From: [email-masked] (John Pawling)
>
> All,
>
> I agree with Bancroft Scott that ESSPrivacyMark should be re-defined as follows:
>
> > ESSPrivacyMark ::= CHOICE {
> >    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
> >    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
> > }
>
>
> Note Bancroft's point as follows:
>
> >Another
> >benefit is that if someone is using a tool that does not support
> >UTF8String they can simply change it to "[0] OCTET STRING" and get the
> >same encoding.

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Wed, 18 Feb 1998 13:31: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: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

> A status protocol should
>thus support "hash of the certificate DER encoding" to allow the access
>to revocation information only to entities that are having the
>certificate in question available. Neither issuer and serial (anyone can
>construct such a hash) nor sending the complete certificate (breaching
>privacy laws) are acceptable.
>
>Any ideas on this? While the hash could be included in the extensions, I
>feel that it is not a proper place to do so. I would rather like to see
>this as yet another method for certificate identification.

I would prefer to take the approach of defining a generic URI to
refer to _any_ concrete data structure by the hash of its content.

A concrete data structure in this case would be an actual stream
of bits. Variant documents such as HTML documents generated on
the fly to support multiple clients would not count.

The digest would need armouring in some fashion, despite the
additional characters I believe that Base16 is preferable to Base64
singe the former can be read over a telephone line. It would be
prudent to allow use of more than one digest method and so the
protocol tag needs to be followed by an algorithm tag.

How about

digest:algorithm/value
digest:SHA1/81A72C368E126DD38EE61FF27F8A6

There is currently a URI working group but I can't recomend it
as a venue at the moment. Better to propose a label that is
usefull and sensible and if it proves to be valuable propose it
as a general standard.

Those who actually do understand URIs such as Dave Raggett
and Tim B-L have proposed similar schemes in the past.

    Phill

Approved-By: [email-masked]
Date:         Wed, 18 Feb 1998 11:46: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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Michael Myers wrote:
>
> All,
>
> You should be hearing from IETF soon of an update to the OCSP draft.  It
> takes into account comments in D.C. regarding extensibility, both in the
> request and in the response.  Several other tweaks have been made, such as a
> more formal BNF specification of request and response syntax.  Many thanks
> to Rich Ankey of Certco for his contributions to this draft.
>
> Interested parties should review the draft for responsiveness to
> requirements and technical completeness in anticipation of a formal Last
> Call going in to L.A.
>
> Mike
The German Digital Signature Law needs an OCSP-like service (provided by
a trusted directory service) that allows clients to ask for the validity
status of certificates. This status can be inquired at any point in time
about any previous point in time, like "what was the status of the
certificate at 10:13 on 1/13/97". The additional information -- the time
-- can easily added in the OCSP extension field.

What is missing to support this feature is an additonal method of
identifying a certificate. OCSP uses either a hash over the DN an serial
number or the complete certificate. Since certificates contain privacy
relevant data, persons can choose not to publish the certificate at all
(only providing it with any message they send). A status protocol should
thus support "hash of the certificate DER encoding" to allow the access
to revocation information only to entities that are having the
certificate in question available. Neither issuer and serial (anyone can
construct such a hash) nor sending the complete certificate (breaching
privacy laws) are acceptable.

Any ideas on this? While the hash could be included in the extensions, I
feel that it is not a proper place to do so. I would rather like to see
this as yet another method for certificate identification.

Andreas
--
Wissen haelt nicht laenger als Fisch.
  -- Alfred North Whitehead, Logiker und Philosoph 1861-1947
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 (????/----) (0001EB7F)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 17 Feb 1998 18:32:22 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Bill,

>----------
>From:  Bill Burr[SMTP:[email-masked]]
>Sent:  Tuesday, February 17, 1998 3:28 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>The problem I have is that what you claim "people think of as a
>cross-certificate" is not at all, not even a little bit, what I think of as
>a cross-certificate.  I think a cross-certificate is a cross-certificate
>pair.   No more and no less.  And X.509 (June 1997 version) never uses
>"cross-certificate" except as a part of cross-certificate pair (unless
>there is some mysterious new amendment I've never seen that changes
>everything, and at this point I don't care about further amendments to
>X.509),

I suppose it depends on how you read the spec.  To me, X.509 defines
cross-certificate by implication, in that a "cross-certificate pair" is
a pair of cross-certificates (so that what goes in the "forward"
parameter is a cross-certificate and what goes in the "reverse"
parameter is another cross-certificate).  Read your way,
"cross-certificate pair" is a single item, not a pair of items (in this
case, what goes in the "forward" and "reverse" parameters are presumably
CA-certificates).

It is exactly this kind of ambiguity in X.509 that has led to all the
confusion over terminology in this area.  My preference is for PKIX to
define the terms clearly and unambiguously (at least for its own
purposes; i.e., within its own documents).  I don't see why trying to
align with the X.509 terminology is necessarily the optimum choice,
given that the ambiguous X.509 terminology is the problem we're trying
to solve...

Carlisle.

Approved-By:  Russ Housley <[email-masked]>
Date:         Tue, 17 Feb 1998 18:26: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: Russ Housley <[email-masked]>
Subject:      [IETF-PKIX] Nortel Patent and Authority Information Access
To: [email-masked]
Status:

All:

I just read the Nortel patent, and I am very concerned.  I am not a lawyer
(thank goodness), but my reading of the patent leads me to believe that it
covers more than CRL Distribution points.  Claim 1 is very broad.  In
particular, it seems to cover the use of the Authority Information Access
extension to point to a OCSP server.

I think that we need some lawyers to look at PKIX Part 1 and the Nortel
patent.  I would hope that companies with the appropriate legal resources
could have them take a look and post the findings.

Russ

Approved-By: [email-masked]
Date:         Tue, 17 Feb 1998 15:28:34 -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: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

At 12:12 PM 2/16/98 -0500, you wrote:
>Hi All,
>
>I appreciate all the recent feedback on this topic; this is what a
>mailing list is all about!  Since, however, this seems to be the last
>remaining issue for PKIX-CMP, it would be great if we could wrap up this
>definition and get the draft submitted (CMP has been on hold for weeks
>now while we debated the definition of cross-certification, which is
>unfortunate, given that this is such a small part of the whole
>draft...).
>
>As far as I can tell, the following proposal is sensitive to all the
>e-mails (both public and private) that I've seen.
>
>"cross-certification:  Any process that results in the creation of a
>cross-certificate.  For the purposes of this standard, the following
>terms are defined.  A "CA-certificate" is any certificate in which both
>the subject and issuer are CAs.  A "cross-certificate" is a
>CA-certificate in which the subject CA and the issuer CA are distinct
>and  SubjectPublicKeyInfo contains a verification key (i.e., the
>certificate has been issued for the subject CA's signing key pair).
>When it is necessary to distinguish more finely, the following terms may
>be used:  a cross-certificate is called an "inter-domain
>cross-certificate" if the subject and issuer CAs belong to different
>administrative domains; it is called an "intra-domain cross-certificate"
>otherwise.  (Note:  in many environments the term "cross-certificate",
>unless further qualified, will be understood to be synonymous with
>"inter-domain cross-certificate" as defined above.).  Issuance of
>cross-certificates may be, but is not necessarily, mutual; that is, two
>CAs may issue cross-certificates for each other."
>
>
>Some comments.
>
>1) The first sentence addresses those who were concerned that the
>previous definition of cross-certification mandated a request from the
>subject CA and a response from the issuer CA.  This now makes it clear
>that the so-called "spontaneous" decision by the issuer still
>constitutes "cross-certification".
>
>2) The definition of "CA-certificate" aligns with that given in X.509.
>The definition of "cross-certificate" is slightly more restrictive in
>that a self-signed certificate is explicitly *not* a cross-certificate,
>but I believe this would correspond with everyone's understanding and
>use of the term today.
>
>3) The note at the end addresses those who feel that cross-certification
>applies only to CAs in different administrative domains.  This note
>makes it clear that such will be the common interpretation without
>completely closing the door to other possible interpretations.
>
>4) I recognize that some wanted to drop the term cross-certificate (or
>cross-certification) completely and move to something else (such as
>CA-certificate or one of the other candidates).  However, the following
>two reasons might be offered for keeping "cross-certificate" in these
>documents.
>
>- For better or worse, rightly or wrongly, the industry (including the
>media) has adopted the term "cross-certificate".  It is true that
>different people often mean different things when they use it.  However,
>it seems much more sensible to define the term than to, at this late
>stage, try to introduce a new term that no one is familiar with.  It's a
>bit like "certificate", or "signature", or a number of other terms; I'm
>not sure we have the luxury of choosing names for these concepts any
>more, but we *can* define what PKIX means when they are used in PKIX
>documents.
>
>- Again, for better or worse, rightly or wrongly, the X.500 Directory
>standard defines attributes called "ca-certificate" and
>"cross-certificate".  If PKIX takes what we all intuitively think of as
>a cross-certificate and calls it a CA-certificate, where would such a
>thing likely be put in the Directory (despite any warnings we might put
>in that the two terms are unrelated)?  If PKIX calls it some new name,
>where would it be put?  All this would really accomplish would be to
>complicate path-finding procedures unnecessarily.  I fail to see much
>value in taking what people think of as a cross-certificate, calling it
>a CA-certificate, and then encouraging Directory users to put it in the
>cross-certificate attribute rather than the ca-certificate attribute...

The problem I have is that what you claim "people think of as a
cross-certificate" is not at all, not even a little bit, what I think of as
a cross-certificate.  I think a cross-certificate is a cross-certificate
pair.   No more and no less.  And X.509 (June 1997 version) never uses
"cross-certificate" except as a part of cross-certificate pair (unless
there is some mysterious new amendment I've never seen that changes
everything, and at this point I don't care about further amendments to X.509),

Moreover, it seems to me that the meaning of the term "CA-certificate" is
pretty obvious, and the term defined in X.509 as: "A certificate for one CA
issued by another CA" and is used 19 times in X.509.  And to my reading,
where X.509 says "CA-certificate" or "CA certificate"  you would have PKIX
say "cross-certificate."  I have a really hard time with that.  I think
that it's confusing as hell.

I favor using cross-certificate as equivalent to cross-certificate pair,
and CA -certificate, as it us used in X.509, for any certificate, as
anything that is not an end-entity certificate.

This may cause problems with drafts of X.500 I've never seen.  It seems to
me that the thing to do is to make X.500 attributes align with X.509
terminology.

But to have PKIX use the term "cross-certificate" where X.509 apparently
always uses "CA-certificate" would be a spectacularly confusing choice.
Regards,

Bill Burr

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Tue, 17 Feb 1998 10:48: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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Charles,
We all agree that the information in the certificates drives the certificate
validation process.
What does not play any part in the process is any metadata that the
cross-certificate may or may not belong to a pair of entities within  an
administrative domain. I could have a set of CA within my domain that has
the same constraints as a CA external to my domain. If the policy within the
certificates is the same, they get treated  the same. I do not change what I
do because of where they are found, only by what I find in the certificates.

I would go further to say that by using separate directory attributes of
CAcertificate and cross-certificate, and user-certificate we are confusing
the picture. There is no information within the issuer or subject DN. that
would guarantee to tell you whether the subject and issuer belonged to the
same or different administrative domains. Placing a CA certificate in the
user-certificates attribute does not change the certificate type or what I
trust about the certificate. Should we not just have one attribute on a
directory object called simply "certificates".
Trevor
> -----Original Message-----
> From: Charles Moore [SMTP:[email-masked]]
> Sent: Monday, February 16, 1998 5:43 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>
> -----Original Message-----
> From: Trevor Freeman <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Tuesday, 17 February 1998 10:51
> Subject: Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>
> >Hi Carlisle,
> >When I am walking the chain, I do not know the nature of the superior CA
> >therefore if you logic is followed, I must be prepared to search the
> >Cross-certificates attribute, then the CA-certificate attribute resulting
> in
> >two directory hits in some instances as well as additional complexity of
> >code. Is it not simpler to  just search one attribute of an object with
> the
> >certainty of all certificate will be in that attribute, so it would make
> >sense to select the name of attribute would contains all CA certificates
> in
> >which case this would imply using the CA-certificate attribute.
>
> Certpath processing depends on the certificate policy, i.e the rules that
> must be followed.
>
> So if I start at the user certificate, I know it will be signed by a
> CAcertificate, I get this from the Ca Certificate attribute
> Now I look at the cert policy and know the rules to apply to the path
> processing. A policy may decied that only hiearchical ( i.e subordination
> rules will apply, in which case I would look in the CA attribute to find
> the
> path ( Xcerts would not apply even if they exist as this is against the
> policy ) .
>
> Now in other cases my policy may allow for Xcerts in which case I look for
> the cross certificate pair as my policy may require a bialateral
> arrangement
> i.e that there exists a forward and reverse certificates or just one way
>  it very difficult to do this with
> just a CAcertificate) as cross implies direction ( I will agree not
> impossible, but not something I would not willingly do when their are
> simpler ways).
>
> So I use the symantics and the syntax associated with cross certificate
> pairs to good use ( that why they exist).
> I may use CA CACertificate attribute to do certpath navigation, but not to
> find cross certs or cross cert pairs.
>
> What rules I follow are determined by the certificate policy, which is
> contained within each certificate.
>
> So in summary, I dont make arbitary decisions, I follow the certificate
> policy rules, and I use the available mechanims to help simplify the path
> processing.
>
> I have sent a couple of simple cross certificate defintions to the list
> with
> no one disagreeing, but still see this CACertificate line. My last thought
> was to just to not bother, as a) I realy dont need a on-line cross
> certificate request mechanism ( numerious peole have outlined why, but
> then
> if this is useful I dont disagree with the mechanism being available), b)
> the market will determine what policies will be acceptable and what
> solutions meet those policies. We will make use of available mechanisms to
> meet the different types of policy requirements.
>
> The one thing we have learned and it is also evident in this list is that
> there is no single right way, but some are easier than others.
>
> PKIX had an opportunity to assist with clarification of the above issues
>  value add ), but I just see a value subtract and increased confusion.
>
> The over loading of the terms CAcertificate ( and all the minor variations
> cACertificate etc)  and now cross certificate are not helpful to anyone,
> who
> wants to build and deploy  PKIs.
>
> We also need to be careful, 12mths ago people thought that self signed
> root
> certificates were the basis of any PKI; experience has shown this not to
> be
> so. Due to a number of issues cross certificates are seen to be the
> answer,
> experience will show that these mechamisms all have their place, but none
> alone are the universal answer to PKI deployment, scaleability or Trust
> issues.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >We only have two types of entity, CA and End entity. Can we not reflect
> this
> >in the directory by CA's using CA-Certificate attribute and end entities
> use
> >the user-certificates attribute?
> >Trevor

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 17 Feb 1998 09:48:19 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Carlisle,

  Your proposed text looks great!

Dave

P.S. I just found out that I will be in London during the LA IETF
meeting; I hope there are no open issues left to resolve by then
anyway :-).

Approved-By:  Phillip Hallam-Baker <[email-masked]>
Date:         Tue, 17 Feb 1998 10:10:46 -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] Defining Terms w.r.t. Cross Cert...
Comments: To: "Michael J. Aikins" <[email-masked]>
To: [email-masked]
Status:

Michael J. Aikins wrote:
>
> why is it Charlie that every time you send me an email message.........I get
> a note that the digital signature on the message is invalid. I do have a
> certificate for you in my address book but maybe you have changed or it has
> expired ???

The list manager software performs some message transformation that
modified
the content of the message. Regardless of whether a certificate is
trusted or
not any message sent in the 'readable' signature mode is unlikely to
verify.

                Phill

Approved-By:  "Michael J. Aikins" <[email-masked]>
Date:         Tue, 17 Feb 1998 14:53:41 +1100
Reply-To: "Michael J. Aikins" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Michael J. Aikins" <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

why is it Charlie that every time you send me an email message.........I get
a note that the digital signature on the message is invalid. I do have a
certificate for you in my address book but maybe you have changed or it has
expired ???

Boy Vienna is really cold.....

MikeA.

-----Original Message-----
From: Charles Moore <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 17 February 1998 13:27
Subject: Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...

>snip
>>
>>However, the point I was trying to make (in the discussion, if not the
>>text) is that PKIX should use the term "cross-certificate" rather than
>>"CA-certificate" in its documents precisely to try and diminish/remove
>>possible confusion (i.e., so that people would be more inclined to put
>>the result in the cross-certificate attribute than in the cACertificate
>>attribute).  The argument I was making (which I believe we're in violent
>>agreement on) is that it would not make sense for PKIX to call it a
>>"CA-certificate" and then encourage people *not* to put it in the
>>cACertificate attribute.  Life seems less error-prone if we simply call
>>it a cross-certificate and then encourage people to put it in the
>>cross-certificate attribute...
>
>You are right, I do agree with you.
>
>

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

Attachment converted: Lutefisk:smime.p7s 76 (????/----) (0001EAD8)

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 11:42:45 +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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

-----Original Message-----
From: Trevor Freeman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 17 February 1998 10:51
Subject: Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...

>Hi Carlisle,
>When I am walking the chain, I do not know the nature of the superior CA
>therefore if you logic is followed, I must be prepared to search the
>Cross-certificates attribute, then the CA-certificate attribute resulting
in
>two directory hits in some instances as well as additional complexity of
>code. Is it not simpler to  just search one attribute of an object with the
>certainty of all certificate will be in that attribute, so it would make
>sense to select the name of attribute would contains all CA certificates in
>which case this would imply using the CA-certificate attribute.

Certpath processing depends on the certificate policy, i.e the rules that
must be followed.

So if I start at the user certificate, I know it will be signed by a
CAcertificate, I get this from the Ca Certificate attribute
Now I look at the cert policy and know the rules to apply to the path
processing. A policy may decied that only hiearchical ( i.e subordination
rules will apply, in which case I would look in the CA attribute to find the
path ( Xcerts would not apply even if they exist as this is against the
policy ) .

Now in other cases my policy may allow for Xcerts in which case I look for
the cross certificate pair as my policy may require a bialateral arrangement
i.e that there exists a forward and reverse certificates or just one way
 it very difficult to do this with
just a CAcertificate) as cross implies direction ( I will agree not
impossible, but not something I would not willingly do when their are
simpler ways).

So I use the symantics and the syntax associated with cross certificate
pairs to good use ( that why they exist).
I may use CA CACertificate attribute to do certpath navigation, but not to
find cross certs or cross cert pairs.

What rules I follow are determined by the certificate policy, which is
contained within each certificate.

So in summary, I dont make arbitary decisions, I follow the certificate
policy rules, and I use the available mechanims to help simplify the path
processing.

I have sent a couple of simple cross certificate defintions to the list with
no one disagreeing, but still see this CACertificate line. My last thought
was to just to not bother, as a) I realy dont need a on-line cross
certificate request mechanism ( numerious peole have outlined why, but then
if this is useful I dont disagree with the mechanism being available), b)
the market will determine what policies will be acceptable and what
solutions meet those policies. We will make use of available mechanisms to
meet the different types of policy requirements.

The one thing we have learned and it is also evident in this list is that
there is no single right way, but some are easier than others.

PKIX had an opportunity to assist with clarification of the above issues
 value add ), but I just see a value subtract and increased confusion.

The over loading of the terms CAcertificate ( and all the minor variations
cACertificate etc)  and now cross certificate are not helpful to anyone, who
wants to build and deploy  PKIs.

We also need to be careful, 12mths ago people thought that self signed root
certificates were the basis of any PKI; experience has shown this not to be
so. Due to a number of issues cross certificates are seen to be the answer,
experience will show that these mechamisms all have their place, but none
alone are the universal answer to PKI deployment, scaleability or Trust
issues.

>We only have two types of entity, CA and End entity. Can we not reflect
this
>in the directory by CA's using CA-Certificate attribute and end entities
use
>the user-certificates attribute?
>Trevor

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

Attachment converted: Lutefisk:smime.p7s 67 (????/----) (0001EACE)

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 16 Feb 1998 17:09: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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

All,

You should be hearing from IETF soon of an update to the OCSP draft.  It
takes into account comments in D.C. regarding extensibility, both in the
request and in the response.  Several other tweaks have been made, such as a
more formal BNF specification of request and response syntax.  Many thanks
to Rich Ankey of Certco for his contributions to this draft.

Interested parties should review the draft for responsiveness to
requirements and technical completeness in anticipation of a formal Last
Call going in to L.A.

Mike

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 10:52:23 +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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

snip
>
>However, the point I was trying to make (in the discussion, if not the
>text) is that PKIX should use the term "cross-certificate" rather than
>"CA-certificate" in its documents precisely to try and diminish/remove
>possible confusion (i.e., so that people would be more inclined to put
>the result in the cross-certificate attribute than in the cACertificate
>attribute).  The argument I was making (which I believe we're in violent
>agreement on) is that it would not make sense for PKIX to call it a
>"CA-certificate" and then encourage people *not* to put it in the
>cACertificate attribute.  Life seems less error-prone if we simply call
>it a cross-certificate and then encourage people to put it in the
>cross-certificate attribute...

You are right, I do agree with you.

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

Attachment converted: Lutefisk:smime.p7s 63 (????/----) (0001EACA)

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Mon, 16 Feb 1998 16:24:41 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Carlisle,
When I am walking the chain, I do not know the nature of the superior CA
therefore if you logic is followed, I must be prepared to search the
Cross-certificates attribute, then the CA-certificate attribute resulting in
two directory hits in some instances as well as additional complexity of
code. Is it not simpler to  just search one attribute of an object with the
certainty of all certificate will be in that attribute, so it would make
sense to select the name of attribute would contains all CA certificates in
which case this would imply using the CA-certificate attribute.
We only have two types of entity, CA and End entity. Can we not reflect this
in the directory by CA's using CA-Certificate attribute and end entities use
the user-certificates attribute?
Trevor

Approved-By: [email-masked]
Date:         Mon, 16 Feb 1998 15:30: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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Carlisle Adams wrote:

> Hi Trevor,
>
> >----------
> >From:  Trevor Freeman[SMTP:[email-masked]]
> >Sent:  Monday, February 16, 1998 5:08 PM
> >To:    [email-masked]
> >Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
> >
> >I would disagree that cross-certificate attribute should be used at all. I
> >see this as falling into the same camp as Authority Revocation List, another
> >obsolete inheritance.
>
> Many CAs seem to find it useful to publish self-signed certificates in
> whatever public repository they use.  While this may have value, it
> typically does not have value during the certificate path-finding and
> path-validation process.  An easy thing to do that can simplify and
> speed up such processing, therefore, is to put self-signed certs and
> cross-certs in different places (so that path-finding / path-validation
> software gets only the certificates that it actually needs to look at).
> In the Directory, it seems to make sense to put cross-certificates in
> the cross-certificate attribute; this implies that self-signed certs go
> in the cACertificate attribute.
>
> >You do not intrinsically process an intra-domain
> >cross-certificate any different from an inter-domain cross-certificate. You
> >still obey the information contained in the certificate.
>
> I agree.
>
> >I would hope that
> >an organization when creating an inter-domain certificate would constrain is
> >use by setting the appropriate extensions, but that is a policy issue for
> >the organization.
>
> I agree.
>
> >I would not alter any of the processing because I found a
> >certificate in a different directory attribute so what is the point.
>
> The point is to try and simplify things so that you can easily get the
> certificates you need (and only the certificates you need).

and to not drown in the process under the weight of the veritable plethora of
certs that are bound to crop up at the CA's as we all deploy these services to
our users...

>
>
> >All certificates for a CA should be stored in the same attribute.
>
> It seems to me that there is benefit in separating self-signed certs
> from cross-certs.

I would agree, self-signed certs may or may not have commercial import so
burdening systems checking for commercial stuff when you have to plow through a
bunch of SS certs that were bundled into a secondary reference system is s
tremendous amount of potential overhead.

>
>
> Carlisle.

Todd
--
Todd's Latest Rant --
---------------------
"UCC, Commercial Law and numerous international Treaties are the
basis of the 'transaction requirements'. Technologies must adapt
to support them without making them conform to the technologies..."

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 16 (TEXT/R*ch) (0001EAC7)
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 62 (????/----) (0001EAC8)

Approved-By: [email-masked]
Date:         Mon, 16 Feb 1998 11:03:31 -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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] PKIX WG Charter Amendment Text
Comments: To: Michael McNeil <[email-masked]>, Stuart Haber <[email-masked]>, Robert Zuccherato <[email-masked]>, Pat Cain <[email-masked]>, Denis Pinkas <[email-masked]>, Carlisle Adams <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, Stephen Kent <[email-masked]>, Jeffery Schiller <[email-masked]>
To: [email-masked]
Status:

<html><HTML>
Hi all,
<BR>in the December meeting that took place in DC we took a straw pole
that resulted in an action item to add timestamping and non-repudiation
technologies into the breadth of the PKIX WG charter.

<P>To that end Robert Zuccherato and I have come up with this charter that
we would like to submit for your approval and commentary - We would like
to get some discussion and potentially approval of the additions so that
further work on time and timestamping standards can be done within the
WG.

<P>Here then for your review in the charter text update:

<P>----- BEGINING OF CHARTER TEXT ----

<P>Public-Key Infrastructure (X.509) (PKIX)
<BR>--------------------------------------------------
<BR>&nbsp;
<BR>&nbsp;Charter
<BR>&nbsp;Last Modified: February 13, 1998
<BR>&nbsp;
<BR>&nbsp;Current Status: Active Working Group
<BR>&nbsp;
<BR>&nbsp;Chair(s):
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Stephen Kent &lt;[email-masked]>
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Warwick Ford &lt;[email-masked]>
<BR>&nbsp;
<BR>&nbsp;Security Area Director(s):
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Jeffrey Schiller&nbsp; &lt;[email-masked]>
<BR>&nbsp;
<BR>&nbsp;Security Area Advisor:
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Jeffrey Schiller&nbsp; &lt;[email-masked]>
<BR>&nbsp;
<BR>&nbsp;Mailing Lists:
<BR>&nbsp;&nbsp;&nbsp;&nbsp; General Discussion Email:&nbsp; [email-masked]
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Archive:&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;
<A HREF="ftp://ftp.tandem.com/pub/ietf-pkix.current">ftp://ftp.tandem.com/pub/ietf-pkix.current</A>
<BR>&nbsp;&nbsp;&nbsp;&nbsp; To Subscribe:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In Body of email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
subscribe &lt;email address> ietf-pkix

<P>&nbsp;
<BR>Description of Working Group:
<BR>Many Internet protocols and applications which use the Internet employ
public-key technology for security purposes and require a public-key infrastructure
(PKI) to securely manage public keys for widely-distributed users or systems.&nbsp;
The X.509 standard constitutes a widely-accepted basis for such an infrastructure,
defining data formats and procedures related to distribution of public
keys via certificates digitally signed by certification authorities (CAs).

<P>For example, RFC 1422 specified the basis of an X.509-based PKI, targeted
primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).&nbsp;
Since RFC 1422 was issued, application requirements for an Internet PKI
have broadened tremendously, and the capabilities of X.509 have advanced
with the development of standards defining the X.509 version 3 certificate
and version 2 certificate revocation list (CRL).

<P>Charter of the Working Group:
<BR>The charter of the working group will be to develop Internet standards
needed to support the use of an X.509-based PKI.&nbsp; The goal of this
Working Group (WG) will be to further facilitate the use of X.509 certificates
in applications that make use of the Internet and to promote interoperability
between different implementations choosing to make use of X.509 certificates.

<P>The resulting PKI is intended to provide a framework, which will support
a range of trust/hierarchy environments and a range of usage environments
(RFC1422 is an example of one such model).

<P>Candidate applications to be served by this PKI include, but are not
limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols,
Internet payment protocols, timestamping, and www protocols.

<P>This project will not preclude use of non-infrastructural public-key
distribution techniques nor of non-X.509 PKIs by such applications.&nbsp;
Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
project.

<P>The group will focus on tailoring and profiling the features available
in the v3 X.509 certificate to best match the requirements and characteristics
of the Internet environment.

<P>Other topics to be addressed potentially include:
<UL>* Alternatives for CA-to-CA certification links and structures, including
guidelines for constraints

<P>* Revocation alternatives, including profiling of X.509 v2 CRL extensions

<P>* Certificate and CRL distribution options (X.500-based,&nbsp; non-X.500-based)

<P>* Guidelines for policy definition and registration

<P>* Administrative protocols and procedures, including certificate generation,
revocation notification, cross-certification, and&nbsp; key-pair updating

<P>* Naming and name forms (how entities are identified, e.g., email address,
URN, DN, misc.)

<P>* Generation of client key pairs by the PKI

<P>* Services that support non-repudiation.&nbsp; This can include sources
of credible time data and/or certificate path validation services.</UL>
----- END OF CHARTER TEXT ----

<P>Thanks for your consideration -

<P>Todd Glassey (Coastek) and Robert Zuccherato (Entrust)
<BR>&nbsp;
<BR>&nbsp;</HTML>

</html>Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 15 (TEXT/R*ch) (0001EAC5)
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 61 (????/----) (0001EAC6)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 18:00: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Trevor,

>----------
>From:  Trevor Freeman[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 5:08 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>I would disagree that cross-certificate attribute should be used at all. I
>see this as falling into the same camp as Authority Revocation List, another
>obsolete inheritance.

Many CAs seem to find it useful to publish self-signed certificates in
whatever public repository they use.  While this may have value, it
typically does not have value during the certificate path-finding and
path-validation process.  An easy thing to do that can simplify and
speed up such processing, therefore, is to put self-signed certs and
cross-certs in different places (so that path-finding / path-validation
software gets only the certificates that it actually needs to look at).
In the Directory, it seems to make sense to put cross-certificates in
the cross-certificate attribute; this implies that self-signed certs go
in the cACertificate attribute.

>You do not intrinsically process an intra-domain
>cross-certificate any different from an inter-domain cross-certificate. You
>still obey the information contained in the certificate.

I agree.

>I would hope that
>an organization when creating an inter-domain certificate would constrain is
>use by setting the appropriate extensions, but that is a policy issue for
>the organization.

I agree.

>I would not alter any of the processing because I found a
>certificate in a different directory attribute so what is the point.

The point is to try and simplify things so that you can easily get the
certificates you need (and only the certificates you need).

>All certificates for a CA should be stored in the same attribute.

It seems to me that there is benefit in separating self-signed certs
from cross-certs.

Carlisle.

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 17:36:45 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Charles,

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 5:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>>Given that we are both saying exactly the same thing, are you still in
>>violent disagreement?
>
>Can you please provide the text ( not the discussion)  that I am now
>violently agreeing with.

There is no text, only discussion (because it is not the job of CMP to
mandate where things go in an X.500 Directory; that is the job of a
Directory Schema document (which the WG has agreed to take on as a work
item)).

However, the point I was trying to make (in the discussion, if not the
text) is that PKIX should use the term "cross-certificate" rather than
"CA-certificate" in its documents precisely to try and diminish/remove
possible confusion (i.e., so that people would be more inclined to put
the result in the cross-certificate attribute than in the cACertificate
attribute).  The argument I was making (which I believe we're in violent
agreement on) is that it would not make sense for PKIX to call it a
"CA-certificate" and then encourage people *not* to put it in the
cACertificate attribute.  Life seems less error-prone if we simply call
it a cross-certificate and then encourage people to put it in the
cross-certificate attribute...

Carlisle.

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 17:12:46 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Warwick,

I'm quite happy with the proposed modifications.

Do others on the list have other modifications to suggest?

Carlisle.

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 8:09 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>"cross-certification request":  One CA requests issuance of a
>cross-certificate from another CA.  For the purposes of this standard, the
>following terms are defined.  A "cross-certificate" is a certificate in
>which the subject CA and the issuer CA are distinct and
>SubjectPublicKeyInfo contains a verification key (i.e., the certificate has
>been issued for the subject CA's signing key pair).  When it is necessary
>to distinguish more finely, the following terms may be used:  a
>cross-certificate is called an "inter-domain cross-certificate" if the
>subject and issuer CAs belong to different administrative domains; it is
>called an "intra-domain cross-certificate" otherwise.
>
>Notes:
>1. The above definition of "cross-certificate" aligns with the defined term
>"CA-certificate" in X.509.  Note that this term is not to be confused with
>the X.500 "cACertificate" attribute type, which is unrelated.
>2. In many environments the term "cross-certificate", unless further
>qualified, will be understood to be synonymous with "inter-domain
>cross-certificate" as defined above.
>3. Issuance of cross-certificates may be, but is not necessarily, mutual;
>that is, two CAs may issue cross-certificates for each other."

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 08:16: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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

snip
>Given that we are both saying exactly the same thing, are you still in
>violent disagreement?

Can you please provide the text ( not the discussion)  that I am now
violently agreeing with.

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

Attachment converted: Lutefisk:smime.p7s 59 (????/----) (0001EAC1)

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Mon, 16 Feb 1998 14:08:01 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

I would disagree that cross-certificate attribute should be used at all. I
see this as falling into the same camp as Authority Revocation List, another
obsolete inheritance. You do not intrinsically process an intra-domain
cross-certificate any different from an inter-domain cross-certificate. You
still obey the information contained in the certificate. I would hope that
an organization when creating an inter-domain certificate would constrain is
use by setting the appropriate extensions, but that is a policy issue for
the organization. I would not alter any of the processing because I found a
certificate in a different directory attribute so what is the point. All
certificates for a CA should be stored in the same attribute.
Trevor

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 16 Feb 1998 17:09:32 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Carlisle:

Thank you for your admirable efforts to reach a compromise definition!  I
generally agree with your proposal.  However, I think the text needs small
changes in a couple of places.

What is probably not generally known is that X.509 has an inherent problem
in that the defined term "CA-certificate" bears absolutely no relationship
to the cACertificate attribute.  This was an unfortunate terminology snafu
in X.509, and is undoubtedly a big part of the confusion we have faced in
PKIX.

The main point is that the intended use of the defined term
"CA-certificate" is precisely the same as your definition of
"cross-certificate".  The term was coined in X.509 for the purposes of
specifying the chain-validation algorithm, i.e., to be able to easily
distinguish between an end-entity certificate (the last one in the chain)
and the CA-certificates, i.e., all the other certificates in the chain.  I
don't believe self-signed certificates come into it, since X.509 (including
the chain validation algotithm) never recognizes the existence of such
things.

The cACertificate attribute is a different beast ... its intended usage has
never been clear.  The latest resolution of the X.509 group has been to
suggest that it might be used for storing a self-signed certificate, but it
might be used for other things too (to accommodate implementors who may
have used that attribute for other purposes).

Regardless of PKIX, X.509 has had to resolve this issue.  The resolution
reached at the Jan X.509 meeting was to include a note that said explicitly
that the defined term and the attribute were not related and should not be
confused.

Given that background, I believe your "definition" of CA-certificate could
be misleading, and not in line with the X.509 intent.  Let's fix that, and
let's also include the note saying not to confuse the CA-certificate
defined term with the X.500 attribute.

As a separate point, I don't believe it is useful to define
"cross-certification" as "Any process that...".  If we wanted to move into
that territory we would need to identify the various stages of request,
approval, issuance, acceptance, etc.  I think Denis Pinkas was on the ball
in saying that what we really need to define in PKIX is
"Cross-certification request", which is what CMP does, rather than the
abstract concept of cross-certification overall.

Accordingly, I propose some slight modifications to your text:

"cross-certification request":  One CA requests issuance of a
cross-certificate from another CA.  For the purposes of this standard, the
following terms are defined.  A "cross-certificate" is a certificate in
which the subject CA and the issuer CA are distinct and
SubjectPublicKeyInfo contains a verification key (i.e., the certificate has
been issued for the subject CA's signing key pair).  When it is necessary
to distinguish more finely, the following terms may be used:  a
cross-certificate is called an "inter-domain cross-certificate" if the
subject and issuer CAs belong to different administrative domains; it is
called an "intra-domain cross-certificate"
otherwise.

Notes:
1. The above definition of "cross-certificate" aligns with the defined term
"CA-certificate" in X.509.  Note that this term is not to be confused with
the X.500 "cACertificate" attribute type, which is unrelated.
2. In many environments the term "cross-certificate", unless further
qualified, will be understood to be synonymous with "inter-domain
cross-certificate" as defined above.
3. Issuance of cross-certificates may be, but is not necessarily, mutual;
that is, two CAs may issue cross-certificates for each other."

Warwick

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

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 16:19: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Charles,

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 4:07 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>> where would such a
>>thing likely be put in the Directory (despite any warnings we might put
>>in that the two terms are unrelated)?
>> If PKIX calls it some new name,
>>where would it be put?  All this would really accomplish would be to
>>complicate path-finding procedures unnecessarily.  I fail to see much
>>value in taking what people think of as a cross-certificate, calling it
>>a CA-certificate, and then encouraging Directory users to put it in the
>>cross-certificate attribute rather than the ca-certificate attribute...
>
>Because a cross certificate should go in a cross certificate pair attribute.
>
>Lets look at this for a while, we go to the directory looking for cross
>certificates, we find a cross certificate pair attribute but NO we dont use
>this to find a cross certificate we go looking for a CA Attribute. Is this
>realy what is seriously being proposed!!!

No, this is *not* what is seriously being proposed.  In fact, I am
proposing exactly the opposite:  that we try to ensure that we *don't*
look in the CA-certificate attribute for cross-certificates, but instead
look only in the cross-certificate attribute (in the forward, or
reverse, or both, parameter of the cross-certificate pair).

>>Allowing for WG members in different time zones, I propose to wait until
>>Wednesday for responses to the above definition.  Unless there is
>>violent disagreement with the wording, I will include this definition in
>>CMP and submit it at that time.
>
>Ok, you have the violent disagreement, you were waiting for.

Given that we are both saying exactly the same thing, are you still in
violent disagreement?

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

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 07:07:35 +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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

-----Original Message-----
From: Carlisle Adams <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 17 February 1998 3:55
Subject: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...

snip: disagreed stuff.

>- Again, for better or worse, rightly or wrongly, the X.500 Directory
>standard defines attributes called "ca-certificate" and
>"cross-certificate".  If PKIX takes what we all intuitively think of as
>a cross-certificate and calls it a CA-certificate,

This is not what we ALLintuitively think. And given the lack of cross
certificate deployments
within a hetrogenious envionment I dont believe that this statement has
basis.

> where would such a
>thing likely be put in the Directory (despite any warnings we might put
>in that the two terms are unrelated)?
> If PKIX calls it some new name,
>where would it be put?  All this would really accomplish would be to
>complicate path-finding procedures unnecessarily.  I fail to see much
>value in taking what people think of as a cross-certificate, calling it
>a CA-certificate, and then encouraging Directory users to put it in the
>cross-certificate attribute rather than the ca-certificate attribute...

Because a cross certificate should go in a cross certificate pair attribute.

Lets look at this for a while, we go to the directory looking for cross
certificates, we find a cross certificate pair attribute but NO we dont use
this to find a cross certificate we go looking for a CA Attribute. Is this
realy what is seriously being proposed!!!

>
>
>Allowing for WG members in different time zones, I propose to wait until
>Wednesday for responses to the above definition.  Unless there is
>violent disagreement with the wording, I will include this definition in
>CMP and submit it at that time.

Ok, you have the violent disagreement, you were waiting for.

>  Thanks again to everyone for all the
>input!
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------

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

Attachment converted: Lutefisk:smime.p7s 58 (????/----) (0001EAC0)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 12:12: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: Carlisle Adams <[email-masked]>
Subject:      [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi All,

I appreciate all the recent feedback on this topic; this is what a
mailing list is all about!  Since, however, this seems to be the last
remaining issue for PKIX-CMP, it would be great if we could wrap up this
definition and get the draft submitted (CMP has been on hold for weeks
now while we debated the definition of cross-certification, which is
unfortunate, given that this is such a small part of the whole
draft...).

As far as I can tell, the following proposal is sensitive to all the
e-mails (both public and private) that I've seen.

"cross-certification:  Any process that results in the creation of a
cross-certificate.  For the purposes of this standard, the following
terms are defined.  A "CA-certificate" is any certificate in which both
the subject and issuer are CAs.  A "cross-certificate" is a
CA-certificate in which the subject CA and the issuer CA are distinct
and  SubjectPublicKeyInfo contains a verification key (i.e., the
certificate has been issued for the subject CA's signing key pair).
When it is necessary to distinguish more finely, the following terms may
be used:  a cross-certificate is called an "inter-domain
cross-certificate" if the subject and issuer CAs belong to different
administrative domains; it is called an "intra-domain cross-certificate"
otherwise.  (Note:  in many environments the term "cross-certificate",
unless further qualified, will be understood to be synonymous with
"inter-domain cross-certificate" as defined above.).  Issuance of
cross-certificates may be, but is not necessarily, mutual; that is, two
CAs may issue cross-certificates for each other."

Some comments.

1) The first sentence addresses those who were concerned that the
previous definition of cross-certification mandated a request from the
subject CA and a response from the issuer CA.  This now makes it clear
that the so-called "spontaneous" decision by the issuer still
constitutes "cross-certification".

2) The definition of "CA-certificate" aligns with that given in X.509.
The definition of "cross-certificate" is slightly more restrictive in
that a self-signed certificate is explicitly *not* a cross-certificate,
but I believe this would correspond with everyone's understanding and
use of the term today.

3) The note at the end addresses those who feel that cross-certification
applies only to CAs in different administrative domains.  This note
makes it clear that such will be the common interpretation without
completely closing the door to other possible interpretations.

4) I recognize that some wanted to drop the term cross-certificate (or
cross-certification) completely and move to something else (such as
CA-certificate or one of the other candidates).  However, the following
two reasons might be offered for keeping "cross-certificate" in these
documents.

- For better or worse, rightly or wrongly, the industry (including the
media) has adopted the term "cross-certificate".  It is true that
different people often mean different things when they use it.  However,
it seems much more sensible to define the term than to, at this late
stage, try to introduce a new term that no one is familiar with.  It's a
bit like "certificate", or "signature", or a number of other terms; I'm
not sure we have the luxury of choosing names for these concepts any
more, but we *can* define what PKIX means when they are used in PKIX
documents.

- Again, for better or worse, rightly or wrongly, the X.500 Directory
standard defines attributes called "ca-certificate" and
"cross-certificate".  If PKIX takes what we all intuitively think of as
a cross-certificate and calls it a CA-certificate, where would such a
thing likely be put in the Directory (despite any warnings we might put
in that the two terms are unrelated)?  If PKIX calls it some new name,
where would it be put?  All this would really accomplish would be to
complicate path-finding procedures unnecessarily.  I fail to see much
value in taking what people think of as a cross-certificate, calling it
a CA-certificate, and then encouraging Directory users to put it in the
cross-certificate attribute rather than the ca-certificate attribute...

Allowing for WG members in different time zones, I propose to wait until
Wednesday for responses to the above definition.  Unless there is
violent disagreement with the wording, I will include this definition in
CMP and submit it at that time.  Thanks again to everyone for all the
input!

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

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Fri, 13 Feb 1998 13:38:31 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key usage. No, wait, *extended* key usage
Comments: To: "Ietf-Smime (E-mail)" <[email-masked]>
To: [email-masked]
Status:

I am inclined to agree with both Jim and John.
I agree with Jim that the contents of the extended key usage extension may
have implication on the cert chain. The difficulty with extended key usage
is that the set of possible values will never be constrained, so we don't
know what all the possible outcome would be of a check. I also agree with
john that the right place to clarify this point as what the right thing to
do is in the pkix workgroup.
Trevor
> -----Original Message-----
> From: [email-masked] [SMTP:[email-masked]]
> Sent: Friday, February 13, 1998 12:50 PM
> To:   Ietf-Smime (E-mail)
> Subject:      RE: Key usage. No, wait, *extended* key usage
>
> Jim,
>
> For some extensions, the X.509 and PKIX I specs specify when there are
> relationships that must be checked between the values in each of the
> extensions present in the certs that compose a cert path (ex:
> nameConstraints extension).  I can't find any text in X.509 or PKIX I that
> states any requirements for checking any relationship between the values
> in
> the extendedKeyUsage extension present in each cert in the cert path.
>
> Therefore, I don't agree with your implication that the S/MIME v3 Cert
> Handling spec should state any requirements about checking the
> extendedKeyUsage extension values in CA certs.  Furthermore, I agree with
> Pat Cain's "less-is-more" philosophy (see attached message) regarding
> minimizing the mandatory requirements included in the S/MIME v3 Cert
> Handling spec (CERT3).  I agree with Pat that CERT3 should not require any
> checks of the extendedKeyUsage extension.
>
> - John Pawling
>
>
> At 12:00 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
> >John,
> >
> >>
> >> I agree with your suggestion to add wording like:  "Prior to using the
> >> public key included in a certificate to support S/MIME
> >> security services, if
> >> the extendedKeyUsage extension is present in the certificate and is
> >> indicated as being critical, then the S/MIME software MUST
> >> ensure that the
> >> id-kp-emailProtection OID is present.  This check is only
> >> required for the
> >> end-entity certificates."
> >
> >The above is not the way that I had read the docs and how
> >extendedKeyUsage would/should be evaluated,  I am curious why you think
> >that only the end-entity certificate should be checked?  I had thought
> >that the entire chain should be checked even though I did not really
> >expect to see any extendedKeyUsage extensions once I got off the
> >end-entity certificate.
> >
> >I can see the case occuring where a super-CA might say that this CA can
> >only be used for issuing certifiate with the e-mail purpose and I am not
> >sure this should be so explicity disabled.
> >
> >jim
> >
>
>
> >Return-Path: <[email-masked]>
> >X-Sender: [email-masked]
> >Date: Fri, 06 Feb 1998 16:05:41 -0600
> >To: [email-masked]
> >From: Pat Cain <[email-masked]>
> >Subject: Re: un-*extended* key usage
> >Sender: [email-masked]
> >Precedence: bulk
> >
> >Friends,
> >
> >I worry that we may end up putting too many constraints on the SMIME
> >certificate(s)
> >that are not related to interoperability of the protocol. We originally
> >specified the
> >key-usage and name extensions because they really (REALLY) did impact
> >interoperability.
> >Almost all of the other useful X.509 extensions effect how the signature
> or
> >encrypted/random data is interpreted and/or used. For example, if I, as a
> >CA, issue certificates that are good for any number of protocols, it is
> >hard for me to beleive
> >that SMIME (the protocol) really cares. Think of this in the 'Do I
> support
> >delta-CRLs' vain. I hope (pray) that we don't specify the CRL-ing
> technique
> >-- it's a CA policy decision. Much like what uses a particular
> certificate
> >is good for.
> >
> >I vote to leave specific recommendations for extended key usage, beyond
> >what X.509 discusses for criticality and other stuff, out of the spec. If
> a
> >particular CA wants
> >to require extended OIDs in their certiifcates, so be it. But that's one
> of
> >those
> >CA 'policy kind of' things.
> >
> >Pat
> >
> >

Approved-By:  Tolga Acar <[email-masked]>
Date:         Thu, 12 Feb 1998 10:49:47 -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:      [IETF-PKIX] Authority Key Identifier Cert. Extension
To: [email-masked]
Status:

In the PKIX Draft, X.509, sec. 4.2.1.1 Authority Key Identifier extension, the first sentence should be corrected as follows:

old:
"The authority key identifier extension provides a means of identifying the particular public key used to sign a certificate."

new:
"The authority key identifier extension provides a means of identifying the particular private key used to sign a certificate."

change: public --> private

-- Tolga

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Thu, 12 Feb 1998 08:21: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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Warwick,

Glad to hear that we are in agreement that the biggest challenge is NOT
technology.

Also I agree that the complexity of the business, legal etc issues are
particularly
key to public CAs. When a pair of organizations operating internal CAs
decide to cross-certify they may have an existing business relationship,
which can be
extended to address the cross-certification support for that business
relationship. This is clearly a different "business" model than a public
CA cross-certifying with another public CA or with an enterprise CA.

Since the PKIX specifications which are on the standards track are not
dealing with the business relationship issues, but the supporting
technology, lets remove the business relationship issues from the table
and focus on the technology to support them.

------------------
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:  February 12, 1998 1:17 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
>
>Apologies, all.  That message was not intended for distribution to the
>list.  For clarification as requested, I was reflecting my belief that
>inter-domain certification (cross-certification to some) is a complex
>subject still requiring a lot of work - however, the biggest challenges lie
>not in technology but in the business, legal, and information management
>issues faced, in particular, by commercial CAs and their corresponding-CA
>communities.  My apologies for taking another vendor's name in vain.  Shall
>be more careful in future.
>
>Warwick
>
>
>At 12:56 PM 2/9/98 -0500, Sharon Boeyen wrote:
>>Warwick -  an unfortunate style choice ...
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
>

Approved-By:  Warwick Ford <[email-masked]>
Date:         Wed, 11 Feb 1998 22:17: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] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Apologies, all.  That message was not intended for distribution to the
list.  For clarification as requested, I was reflecting my belief that
inter-domain certification (cross-certification to some) is a complex
subject still requiring a lot of work - however, the biggest challenges lie
not in technology but in the business, legal, and information management
issues faced, in particular, by commercial CAs and their corresponding-CA
communities.  My apologies for taking another vendor's name in vain.  Shall
be more careful in future.

Warwick

At 12:56 PM 2/9/98 -0500, Sharon Boeyen wrote:
>Warwick -  an unfortunate style choice ...

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

Approved-By:  Charles Moore <[email-masked]>
Date:         Thu, 12 Feb 1998 06:40:07 +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 Clarification
To: [email-masked]
Status:

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, 12 February 1998 1:36
Subject: Re: [IETF-PKIX] Cross Certification Clarification

:> From: Charles Moore <[email-masked]>
:>
:> A CA-Certificate is a certificate, a cross certificate may optionly  be
both
:> an forward and reverse certificate.
:
:
:Ah haaaaah.  So that's the (at least one) source of confusion.
:Fortunately, this one is easily cleared up.
:
:One group of folks is using "cross-certificate" to refer to a single
:X.509 Certificate which is issued across domain boundaries (as opposed
:to within a heirarchy).
:
:Another group of folks is using "cross-certificate" to refer to the
:X.509 attribute type "crossCertificatePair", which has syntax
:"CertificatePair".
:

:Well, the mates have been quaffing too much Foster's :-).  They should be
:using the term CertificatePair to refer to the structure which optionally
:contains forward and reverse certificates.

I can agree with your suggestion, if I was directly referring to the syntax.

The discussion to date, has forced me to have to agree with Warwick that we
need a definition.

The cross certificate pair supports both requirements, including aribitary
direction.

I dont believe we need to define a specific subset. There is also the issue
of how to use what you have specified.

We use cross certificate pairs to find cross certificates, my problem with
the proposal to make it a CACertificate is that it just complicates the cert
path processing without any gain ( that I understand).

So with a couple of XXXX ( much better than Fosters), perhaps a better
question is, to the cross-certificate = certificate camp. Is there anything
that you want to do that can not be done with a cross certificate pair ?

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

Attachment converted: Lutefisk:smime.p7s 52 (????/----) (0001E8A8)

Approved-By:  [email-masked]
Date:         Wed, 11 Feb 1998 13:21:09 EST
Reply-To: "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] Cross Certification Clarification
To: [email-masked]
Status:

Another point I'd like to make is that even though CA-certificate and
cross-certificate have the same syntax, that is not sufficient reason to not
use one of them. For instance, surname and generationQualifier have the same
syntax but not the same meaning. Even though CA-certificate and
cross-certificate have the same syntax, their meanings are different. I believe
that a cross-certificate may be a CA-certificate (a certificate for a CA issued
by another CA), but a CA-certificate may not be a cross-certificate (a
certificate for a CA issued by another CA in a different domain). I'm not
offering these as suggested definitions but simply to make the point that (in
my mind at least) these terms have different meanings.

Dave Oshman
Price Waterhouse
Electronic Commerce/Internet

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 11 Feb 1998 13:28: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
Comments: To: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Status:

Phill,

I concur with your observation, in most cases.  When a CA issues a cert to
another CA, it ought to include name constraints to limit the scope of
identities for which the target CA is authorized to certify.  This works
well for CA models where the CAs are authoritative for name spaces, not so
well for third-party CAs who have no such standing.  In the latter case,
name constraints generally don't well, so in that context distinguishing
cross-certs from other CA certs seems potentially useful.  However, if the
distinction appears only in the directory entry format, the utility may be
minimal.  This is the same problems we used to have with v1 certs, where
there was a presumption that one could rely on directory attributes to
learn important features about certs, since these attributes were not
present in the certs per se.

Steve

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 11 Feb 1998 10:02:14 -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 Clarification
To: [email-masked]
Status:

> From: Charles Moore <[email-masked]>
>
> A CA-Certificate is a certificate, a cross certificate may optionly  be both
> an forward and reverse certificate.

Ah haaaaah.  So that's the (at least one) source of confusion.
Fortunately, this one is easily cleared up.

One group of folks is using "cross-certificate" to refer to a single
X.509 Certificate which is issued across domain boundaries (as opposed
to within a heirarchy).

Another group of folks is using "cross-certificate" to refer to the
X.509 attribute type "crossCertificatePair", which has syntax
"CertificatePair".

Well, the mates have been quaffing too much Foster's :-).  They should be
using the term CertificatePair to refer to the structure which optionally
contains forward and reverse certificates.

Approved-By: [email-masked]
Date:         Tue, 10 Feb 1998 14:23: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: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] CMP draft question
Comments: To: [email-masked]
To: [email-masked]
Status:

        Hi!

        I have a question about the root CA fingerprint mentioned in
the CMP draft-ietf-pkix-ipki3cmp-06.txt. I was wondering if someone
could please clarify the procedure in section 4.1.  In particular,
in the second paragraph, I find the use of the terms "this information"
and "this value" unclear when several values are referred to in the section.
Also, how does the fingerprint allow an end entity to securely use the CAs
self-certificate, as mentioned in section 4.7.2?

        Thank you for your 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:  "David M. Balenson" <[email-masked]>
Date:         Wed, 11 Feb 1998 00:00:23 -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 M. Balenson" <[email-masked]>
Subject:      [IETF-PKIX] REMINDER: ISOC 1998 Network and Distributed Security Symposium
To: [email-masked]
Status:

Ok, now that I got your attention, here's the missing text ...

1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
March 11-13, 1998
Catamaran Resort Hotel
San Diego, California
Sponsored by the Internet Society
Program Chairs:  Matt Bishop, University of California at Davis
                 Steve Kent, BBN Technologies

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss98
EARLY REGISTRATION DISCOUNT DEADLINE:  February 13, 1998

This 5th annual Symposium brings together researchers, implementers,
and users of network and distributed system security technologies
to discuss today's important security issues and challenges.  The
Symposium provides a mix of technical papers and panel presentations
that describe promising new approaches to security problems that
are practical and, to the extent possible, have been implemented.
NDSS'98 fosters the exchange of technical information and encourages
the Internet community to deploy available security technologies
and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security
Products Group at Bell Laboratories, Lucent Technologies

THIS YEAR'S TOPICS INCLUDE:
- Internet and Intranet security
- Implementation issues for electronic commerce
- All-optical networks security
- Secure single login
- Timestamping protocols
- Remote password protocols
- Mobile agent systems security
- Java security
- Trust management
- Traffic analysis of TCP gateways
- Secure bootstrapping
- Firewalls and IP security

NEW THIS YEAR!  PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Kerberos  (Jeffrey I. Schiller, MIT)
- Internet Security with Firewalls  (Fred Avolio, TIS)
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)

FOR MORE INFORMATION contact the Internet Society:
     Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
     Phone: +1 703 648 9888
     Fax: + 1 703 648 9887
     E-mail: [email-masked]
     URL: http://www.isoc.org/ndss98/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Torryn P. Brazell at the Internet Society
at +1 703 648 9888 or send e-mail to [email-masked].
Sponsorship Chair: George Conrades, GTE Internetworking

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.

Approved-By:  Charles Moore <[email-masked]>
Date:         Wed, 11 Feb 1998 14:33:23 +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 Clarification
To: [email-masked]
Status:

> -----Original Message-----
> From: Carlisle Adams [SMTP:[email-masked]]
> Sent: Wednesday, February 11, 1998 8:24 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Cross Certification Clarification
>
> Hi Charles,
>
> >----------
> >From:  Charles Moore[SMTP:[email-masked]]
> >Sent:  Tuesday, February 10, 1998 5:15 PM
> >To:    [email-masked]
> >Subject:       Re: [IETF-PKIX] Cross Certification Clarification
> >
> >Do you have a suggested term for repesenting the kind of certificate
> that is
> >created unilaterally by one entity (normally a CA) which includes
> another
> >entity's (normally another CA) public key, NOT necessarily as a
> result of a
> >request by CA which is being certified?
> ...
> >I don't object to the proposed terminology, but it leaves me without
> an
> >agreed term for what I believe may be the most common occurance
> >of what I would have otherwise called a cross-certificate.
        [Charles Moore]  Not my text actually ( problem with threads).

> The proposed text says:
>
> "For the purposes of this standard, a cross-certificate (also known as
> CA-certificate) is considered to be any certificate issued by one CA
> for
> another CA's signing key pair (that is, for another CA's public
> verification key)..."
>
> Why exactly do you think that this does not cover what you want?
>
>
>
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------

Approved-By:  Charles Moore <[email-masked]>
Date:         Wed, 11 Feb 1998 11:40:44 +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 Clarification
To: [email-masked]
Status:

-----Original Message-----
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, 11 February 1998 1:18
Subject: Re: [IETF-PKIX] Cross Certification Clarification

:Michael Bungert wrote:
:
:> IMO, a cross-certificate should clearly be distinguished from a CA
:> certificate issued by a parent CA to a subordinated CA. I think that
:> this distinction emphasizes the important property of the PKIX
:> infrastructure that it does not rely on a global hierarchie of CAs
:> but allows a web of independent trust domains which can be linked by
:> 'real' cross-certificates.
:
:Funnily enough I think the terms should be defined to be the same for
:precisely the same reason.
:
:The question is whether there is an objective, semantic difference
:created when a certificate becomes a CA cert rather than a cross
:cert. I have a sneaking feeling that some people believe that the
:problems of inter-domain certification that are involved with
:CA certificates somehow magically disappear if they are called
:a 'cross-certificate'. In fact the only justification for introducing
:a special class for subordinated CA certificates would be if the
:problems of inter-domain certification disappeared in that special
:case which they don't.

A CA-Certificate is a certificate, a cross certificate may optionly  be both
an forward and reverse certificate.
If I want to find a cross cert ( symantics) I go look for a  cross cert
attribute ( if this only has one of the two, so what), if I want to find a
CA certificate I go look for a CA-certificate attribute. With the above I
can find the things I need to make a certifiaction path.
Thats the only different that matters for PKIX.

I have real difficulty with overloading CA-certificate with the symantics of
a cross cert.

:
:
:Unless there is a semantic difference defined between subordinate
:name CA certs and non-subordinate name certs why introduce confusion?

I belive it is useful to use a cross-certificate attribute to find cross
certificates, and CA-attribute to find CA-certificates, the difference in
symantics is very useful.

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

Attachment converted: Lutefisk:smime.p7s 51 (????/----) (0001E842)

Approved-By:  "David M. Balenson" <[email-masked]>
Date:         Tue, 10 Feb 1998 18:33:29 -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 M. Balenson" <[email-masked]>
Subject:      [IETF-PKIX] REMINDER: ISOC 1998 Network and Distributed System Security Symposium
To: [email-masked]
Status:

----------------------------------------------------------------------------
David M. Balenson, AR&E Cryptographic Technologies Group
Trusted Information Systems, 3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 10 Feb 1998 17:24:14 -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 Clarification
To: [email-masked]
Status:

Hi Charles,

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  Tuesday, February 10, 1998 5:15 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross Certification Clarification
>
>Do you have a suggested term for repesenting the kind of certificate that is
>created unilaterally by one entity (normally a CA) which includes another
>entity's (normally another CA) public key, NOT necessarily as a result of a
>request by CA which is being certified?
...
>I don't object to the proposed terminology, but it leaves me without an
>agreed term for what I believe may be the most common occurance
>of what I would have otherwise called a cross-certificate.

The proposed text says:

"For the purposes of this standard, a cross-certificate (also known as
CA-certificate) is considered to be any certificate issued by one CA for
another CA's signing key pair (that is, for another CA's public
verification key)..."

Why exactly do you think that this does not cover what you want?

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

Approved-By:  Charles Moore <[email-masked]>
Date:         Wed, 11 Feb 1998 08:15:36 +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 Clarification
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: Tuesday, 10 February 1998 4:35
Subject: Re: [IETF-PKIX] Cross Certification Clarification

My question to both the Australian mates and the Canadians (at least 2 out
of 3,
I assume, not being sure about Tim):

I tried to set out a simple defintion some time ago.

I would like the definition to be useful to support a variety of PKI
requirements.

Today we support the cross-certificate attribute defintion as the means to
find cross certificates, I dont realy care if some one wants one way two way
or any combination to meet the policy requirements. Certification path
navigation with Xcerts is difficult at the best of times  in a hetrogenious
envionment, having  a cross cert defined as a CA-certificate does not help
anyone ( or at least people that want to build this stuff).

Do you have a suggested term for repesenting the kind of certificate that is
created unilaterally by one entity (normally a CA) which includes another
entity's (normally another CA) public key, NOT necessarily as a result of a
request by CA which is being certified?

CertificatePair    ::= SEQUENCE {
 forward   [0] Certificate OPTIONAL,
 reverse   [1] Certificate OPTIONAL
       -- at least one of the pair shall be present -- }

Its just a cross certificate with only one of the options selected.

As a CA-certificate is defined as a certificate rather than a certificate
pair, the cross cert must work for the CA certificate case right?

Or is there something that I have just not understood here.

I don't object to the proposed terminology, but it leaves me without an
agreed term for what I believe may be the most common occurance
of what I would have otherwise called a cross-certificate.

I dont like the proposed text at all, but if we MUST have one then at least
it should, a) make some sense, b) be consistant with what exists in the
X.509 standards and not break stuff that is based on this.

If its not broken, dont fix it.

I raly dont see why there is such a problem, and the proposed solution just
confuses me.

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

Attachment converted: Lutefisk:smime.p7s 50 (????/----) (0001E835)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 10 Feb 1998 16:16: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] CMP draft question
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Hi Gina,

>----------
>From:  [email-masked][SMTP:[email-masked]]
>Sent:  Tuesday, February 10, 1998 2:23 PM
>To:    Carlisle Adams; [email-masked]
>Subject:       CMP draft question
>
>       Hi!
>
>       I have a question about the root CA fingerprint mentioned in
>the CMP draft-ietf-pkix-ipki3cmp-06.txt. I was wondering if someone
>could please clarify the procedure in section 4.1.  In particular,
>in the second paragraph, I find the use of the terms "this information"
>and "this value" unclear when several values are referred to in the section.

Is the following clearer?

"In  order to make the CA's self certificate useful to end entities that
do not acquire the self certificate via "out-of-band" means, the CA
must also produce a fingerprint for its public key.  End entities that
acquire this fingerprint securely via some "out-of-band" means can then
verify the CA's self-certificate and hence the other attributes
contained therein."

>Also, how does the fingerprint allow an end entity to securely use the CAs
>self-certificate, as mentioned in section 4.7.2?

In order to trust the CA's public key, I either need a trusted copy of
the key itself or I need a trusted fingerprint of the key.  If I have
the latter I can verify the self-signed certificate (which I may have
acquired by any untrusted means) because I can compute the fingerprint
of the key in the certificate, compare it with the fingerprint that I
have, and (if they are equal) use the key to verify the certificate.

Carlisle.

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 10 Feb 1998 12:50:43 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

At 02:50 PM 2/10/98 -0500, you wrote:

[snip]

>In terms of the protocol itself, and in terms of the actual syntax of
>the resulting certificate, does it matter whether the two CAs involved
>are brother-and-sister or distant-cousins?  Does it matter whether they
>are housed in the same building or separated by oceans?  Does it matter
>whether they are owned by the same corporation or owned by different
>corporations?  Again, in terms of the *protocol* itself and in terms of
>the *syntax* of the resulting certificate, no it does not.

Why not take the argument a step further.  I.e., "Does it matter that
either party is actually a CA or not." To answer in the affirmative
presumes some globally accepted definition of CA qualification.  But as
one writer pointed out (with regard to registering extensions) "What if
I want to be my own CA, and certify my family members."  By extension,
perhaps a husband-and-wife wish both to be CAs, and "cross-certify".

Sometimes "PKI" seems less apt than "CKI" (Commercial Key Infrastructure;)

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

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 10 Feb 1998 14:50: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Bob,

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, February 10, 1998 10:36 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross Certification Clarification
>
>As was probably demonstrated by Warwick's recent message, there appear to be
>political forces at work here that would like to institutionalize certain
>existing terminology and practices, whether or not they appear to make sense
>to the rest of the community.

It seems to me that those who look for politics everywhere tend to see
politics everywhere, whether or not it actually exists.  It's a
self-fulfilling prophecy.  There is no reason (or room) for politics in
this discussion; what PKIX is trying to define is a single piece of
syntax and a protocol for creating it.  All this Working Group is trying
to achieve in this instance is a name for a certificate which has a CA
as a subject and another CA as an issuer, along with a specification for
how the subject CA can request such a beast.

In terms of the protocol itself, and in terms of the actual syntax of
the resulting certificate, does it matter whether the two CAs involved
are brother-and-sister or distant-cousins?  Does it matter whether they
are housed in the same building or separated by oceans?  Does it matter
whether they are owned by the same corporation or owned by different
corporations?  Again, in terms of the *protocol* itself and in terms of
the *syntax* of the resulting certificate, no it does not.

Certainly, there may be differences in operating policies and
procedures.  Trust may already be inherent in the relationship or it may
need to be explicitly established by out-of-band means.  But this does
not affect the protocol or the certificate itself.

>To me, and apparently to you, the differences are quite distinct, and I am
>reluctant to blur them in our terminology.  These issues are difficult enough
>without obfuscation and  imprecision.

In the past few messages alone I've seen five or more different terms
for this stuff (CA-certificate, subordinate and non-subordinate name
certificate, normal certificate, cross-certificate, inter-domain
certificate, etc.).  Is this really helping to clarify things?

The PKIX-CMP protocol is perfectly general:  *any* CA-a asks *any* CA-b
to create a certificate which includes CA-a's public verification key.
The policies and procedures, the operational paradigms, the business
decisions which limit this protocol to specific purposes for specific
environments (such as "only within this hierarchy", or "only between two
organizations", etc.) have no place in the PKIX specifications.
Limiting the definition of cross-certificate or of the
cross-certification protocol in the PKIX documents simply results in the
documents not being applicable to all environments in the Internet.

Does it really make sense to do this?

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

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 10 Feb 1998 11:59:18 -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: Marc Branchaud <[email-masked]>
Organization: Xcert Software Inc.
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

David P. Kemp wrote:
>
> > From: Marc Branchaud <[email-masked]>
> >
> > Unfortunately, there's not much syntactic difference between the two types
> > of certificates.  Rather, they're distinguished by what they represent.
>
> I disagree with both "Unfortunately" and "not much".
>
> I would rephrase the sentence as:
>
> Fortunately, there is no syntactic difference between the two types of:
>  1) certificate contents and path validation procedures, (PKIX part 1)
>  2) protocol messages used to retrieve them from a repository (PKIX part 2), or
>  3) protocol messages used to issue/revoke them (PKIX part 3).
>
> There are operational considerations that arise when the system
> architecture allows multiple issuers for a single entity (path
> discovery or path development, DSA/DH parameter inheritance,
> legal/policy agreement between CAs, population of directory attributes,
> etc).  But none of those differences have any effect on what client and
> server applications need to implement in order to be PKIX-compliant.
>
> In the unlikely event that PKIX accepts the work item of profiling
> (defining compliance requirements for) various trust models (strict
> heirarchy, web/mesh, list-of-trusted-CAs, etc), then a distinction
> between "subordinate" CA certification and "cross" CA certification
> will have some meaning in the PKIX context.  But even then, the
> certificate syntax and protocols are not affected by the difference.
> Or in other words, the mechanisms are policy independent and trust
> model independent.
>
> Wouldn't you agree that this is a fortunate situation?
>
> Dave Kemp

Perhaps "unfortunate" was an unfortunate word to use.  I do agree with you
that PKIX is barely affected by this issue.  This line of reasoning leads to
the conclusion that defining cross-certification is outside the current scope
of PKIX's work, and that the drafts should just talk about CA-certificates
(perhaps defining cross-certificate as a synonym, like Warwick suggested).

I'm as open to that as to any of the other suggestions.

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Feb 1998 14:00: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

> From: Marc Branchaud <[email-masked]>
>
> Unfortunately, there's not much syntactic difference between the two types
> of certificates.  Rather, they're distinguished by what they represent.

I disagree with both "Unfortunately" and "not much".

I would rephrase the sentence as:

Fortunately, there is no syntactic difference between the two types of:
 1) certificate contents and path validation procedures, (PKIX part 1)
 2) protocol messages used to retrieve them from a repository (PKIX part 2), or
 3) protocol messages used to issue/revoke them (PKIX part 3).

There are operational considerations that arise when the system
architecture allows multiple issuers for a single entity (path
discovery or path development, DSA/DH parameter inheritance,
legal/policy agreement between CAs, population of directory attributes,
etc).  But none of those differences have any effect on what client and
server applications need to implement in order to be PKIX-compliant.

In the unlikely event that PKIX accepts the work item of profiling
(defining compliance requirements for) various trust models (strict
heirarchy, web/mesh, list-of-trusted-CAs, etc), then a distinction
between "subordinate" CA certification and "cross" CA certification
will have some meaning in the PKIX context.  But even then, the
certificate syntax and protocols are not affected by the difference.
Or in other words, the mechanisms are policy independent and trust
model independent.

Wouldn't you agree that this is a fortunate situation?

Dave Kemp

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 10 Feb 1998 09:59:31 -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: Marc Branchaud <[email-masked]>
Organization: Xcert Software Inc.
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Moshe Litvin wrote:
>
> I disagree.
>
> There is no difference in the validation process between a cross
> certificate (whatever that means) and a "normal" CA certificate.
> When you have a certificate chain from your trusted CA to some
> certificate you don't need to know which certificate along the way is a
> cross certificate and which is a "normal" CA certificate.
>

The key phrase there is "When you have a certificate chain..."  One of the
problems in non-subordinate-CA-certification (yeesh) is path discovery
given transitive relationships:  You have to know the path before you can
decide whether to trust it.

For example, imagine three independent CAs with one-way
inter-certification:

        CAx --> CAy --> CAz

If user A is certified by CAz and wants to send a message to user B who
only trusts CAx's key, then A has to know to send the above chain to B.
The problem can be highlighted if you place the CAs in their own little
hierarchies (think of the vertical lines as downward-pointing arrows):

        CA1     CA3     CA5
         |       |       |
        CAx --> CAy --> CAz
         |       |       |
        CA2     CA4     CA6

How does a user certified by CA6 know to send the chain
CA1->CAx->CAy->CAz->CA6 to a user who only trusts CA1's key?  CA6's
subjects probably aren't even aware of the CAx->CAy->CAz chain.  Heck, CA6
and even CAz itself probably don't know about it either.

As Bob said when he proposed his new algorithm for validating a certificate
across two hierarchies, "transitive cross-certification seems altogether
too scary."

This is one reason why, I think, people feel the need to differentiate
between certificates for subordinate and non-subordinate CAs.
Unfortunately, there's not much syntactic difference between the two types
of certificates.  Rather, they're distinguished by what they represent.

> Off course there are different trust aspects when dealing with cross
> certification, but they  should be encoded in the certificate
> extensions. Anything outside the certificate is not signed and therefor
> no reliable.

It's difficult to see how encoding trust aspects in the certificates solves
the above problem.  Even if we could somehow encode the relationships the
certificates represent into the certificates themselves, it's hard to see
how the actual processing of the chains would be any different than what is
already defined.

This, I think, is why people feel there should not be any distinction.  The
debate will probably linger until somebody figures out how to handle
transitive trust.

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

Approved-By:  Moshe Litvin <[email-masked]>
Date:         Tue, 10 Feb 1998 17:58:19 +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: Moshe Litvin <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

I disagree.

There is no difference in the validation process between a cross
certificate (whatever that means) and a "normal" CA certificate.
When you have a certificate chain from your trusted CA to some
certificate you don't need to know which certificate along the way is a
cross certificate and which is a "normal" CA certificate.

Off course there are different trust aspects when dealing with cross
certification, but they  should be encoded in the certificate
extensions. Anything outside the certificate is not signed and therefor
no reliable.

Bob Jueneman wrote:
>
> Phil,
>
> I disagree.
>
> In addition to the semantic differences in the two trust domains (the signer and the relying party), there is a substantial syntactic difference in how the certificates are acquired and validated. That's enough difference to warrant two different names, 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]
>

-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

[email-masked]            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 10 Feb 1998 08:29:23 -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 Clarification
Comments: To: [email-masked]
To: [email-masked]
Status:

Phil,

I disagree.

In addition to the semantic differences in the two trust domains (the signer and the relying party), there is a substantial syntactic difference in how the certificates are acquired and validated. That's enough difference to warrant two different names, 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."

>>> Phillip Hallam-Baker <[email-masked]> 02/10 8:03 AM >>>
Michael Bungert wrote:

> IMO, a cross-certificate should clearly be distinguished from a CA
> certificate issued by a parent CA to a subordinated CA. I think that
> this distinction emphasizes the important property of the PKIX
> infrastructure that it does not rely on a global hierarchie of CAs
> but allows a web of independent trust domains which can be linked by
> 'real' cross-certificates.

Funnily enough I think the terms should be defined to be the same for
precisely the same reason.

The question is whether there is an objective, semantic difference
created when a certificate becomes a CA cert rather than a cross
cert. I have a sneaking feeling that some people believe that the
problems of inter-domain certification that are involved with
CA certificates somehow magically disappear if they are called
a 'cross-certificate'. In fact the only justification for introducing
a special class for subordinated CA certificates would be if the
problems of inter-domain certification disappeared in that special
case which they don't.

Unless there is a semantic difference defined between subordinate
name CA certs and non-subordinate name certs why introduce confusion?

The only good reason to call them cross certificates is that people
get cross talking about them.

                Phill

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 10 Feb 1998 08:36:54 -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 Clarification
Comments: To: [email-masked]
To: [email-masked]
Status:

>Hi all,
>
>this is my first message to the PKIX mailing list. I've followed the
>discussions on cross-certification and I'm astonished that the
>discussions are going to lead to the definition of cross-certificates
>as CA certificates.
>IMO, a cross-certificate should clearly be distinguished from a CA
>certificate issued by a parent CA to a subordinated CA. I think that
>this distinction emphasizes the important property of the PKIX
>infrastructure that it does not rely on a global hierarchie of CAs
>but allows a web of independent trust domains which can be linked by
>'real' cross-certificates.
>
>For me, a cross-certificate is a certificate issued by an issuer CA
>to another CA (or even another end entity) that is not subordinated
>to the issuer CA.
>
>Michael

Precisely.

As was probably demonstrated by Warwick's recent message, there appear to be political forces at work here that would like to institutionalize certain existing terminology and practices, whether or not they appear to make sense to the rest of the community.

To me, and apparently to you, the differences are quite distinct, and I am reluctant to blur them in our terminology.  These issues are difficult enough without obfuscation and  imprecision.

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."

Approved-By:  Phillip Hallam-Baker <[email-masked]>
Date:         Tue, 10 Feb 1998 10:03:29 -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] Cross Certification Clarification
To: [email-masked]
Status:

Michael Bungert wrote:

> IMO, a cross-certificate should clearly be distinguished from a CA
> certificate issued by a parent CA to a subordinated CA. I think that
> this distinction emphasizes the important property of the PKIX
> infrastructure that it does not rely on a global hierarchie of CAs
> but allows a web of independent trust domains which can be linked by
> 'real' cross-certificates.

Funnily enough I think the terms should be defined to be the same for
precisely the same reason.

The question is whether there is an objective, semantic difference
created when a certificate becomes a CA cert rather than a cross
cert. I have a sneaking feeling that some people believe that the
problems of inter-domain certification that are involved with
CA certificates somehow magically disappear if they are called
a 'cross-certificate'. In fact the only justification for introducing
a special class for subordinated CA certificates would be if the
problems of inter-domain certification disappeared in that special
case which they don't.

Unless there is a semantic difference defined between subordinate
name CA certs and non-subordinate name certs why introduce confusion?

The only good reason to call them cross certificates is that people
get cross talking about them.

                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 49 (????/----) (0001E82F)

Priority: Normal
Approved-By:  Michael Bungert <[email-masked]>
Date:         Tue, 10 Feb 1998 15:02:45 PST
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Bungert <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Hi all,

this is my first message to the PKIX mailing list. I've followed the
discussions on cross-certification and I'm astonished that the
discussions are going to lead to the definition of cross-certificates
as CA certificates.
IMO, a cross-certificate should clearly be distinguished from a CA
certificate issued by a parent CA to a subordinated CA. I think that
this distinction emphasizes the important property of the PKIX
infrastructure that it does not rely on a global hierarchie of CAs
but allows a web of independent trust domains which can be linked by
'real' cross-certificates.

For me, a cross-certificate is a certificate issued by an issuer CA
to another CA (or even another end entity) that is not subordinated
to the issuer CA.

Michael

In "[IETF-PKIX] Cross Certification Clarification", Warwick Ford wrote:

> Following on from the thread on Cross-Certification Terminology, Carlisle
> Adams, Tim Polk, and I have agreed on the following, which we believe to
> fairly reflect a concensus of the various views expressed.  In order to
> clarify use of the term "cross-certification" in the PKIX standards, we
> propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
> and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
> existing text in both cases.
>
> cross-certification:  A requesting CA requests issuance of a
> cross-certificate by a responding CA.  For the purposes of this standard, a
> cross-certificate (also known as CA-certificate) is considered to be any
> certificate issued by one CA for another CA's signing key pair (that is,
> for another CA's public verification key), regardless of the particular
> surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> organizational relationships between CAs.  Issuance of cross-certificates
> may be, but is not necessarily, mutual, i.e., two CAs may issue
> certificates for each other.
>
> Warwick
>
> ---------------------------------------------------------------------
> Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>    [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
> ---------------------------------------------------------------------
>

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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Tue, 10 Feb 1998 12:39: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 Clarification
To: [email-masked]
Status:

Bob Jueneman wrote:

> My question to both the Australian mates and the Canadians (at least 2 out of 3,
> I assume, not being sure about Tim):

Are non-Autralian and Non-Canadian people allowed to comment ?   :-)

> Do you have a suggested term for repesenting the kind of certificate that is
> created unilaterally by one entity (normally a CA) which includes another
> entity's (normally another CA) public key, NOT necessarily as a result of a
> request by CA which is being certified?

You may call it a "cross-certificate" or an "inter-domain certificate",
whichever you prefer.

If you look carefully at the proposal I made yesterday the term "cross
certification" is no more used. "Cross-certificate request" used
instead. This means that a cross-certificate may be issued as the result
of a request, but may also be issued spontenaously by a CA.

> I don't object to the proposed terminology, but it leaves me without an
> agreed term for what I believe may be the most common occurance
> of what I would have otherwise called a cross-certificate.
>
> Bob
>
> >>> Charles Moore <[email-masked]> 02/08 2:43 PM >>>
>
> -----Original Message-----
> From: Warwick Ford <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Monday, 9 February 1998 7:05
> Subject: [IETF-PKIX] Cross Certification Clarification
>
> :Following on from the thread on Cross-Certification Terminology, Carlisle
> :Adams, Tim Polk, and I have agreed on the following, which we believe to
> :fairly reflect a concensus of the various views expressed.  In order to
> :clarify use of the term "cross-certification" in the PKIX standards, we
> :propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
> :and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
> :existing text in both cases.
> :
> :cross-certification:  A requesting CA requests issuance of a
> :cross-certificate by a responding CA.  For the purposes of this standard, a
> :cross-certificate (also known as CA-certificate) is considered to be any
> :certificate issued by one CA for another CA's signing key pair (that is,
> :for another CA's public verification key), regardless of the particular
> :surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> :organizational relationships between CAs.  Issuance of cross-certificates
> :may be, but is not necessarily, mutual, i.e., two CAs may issue
> :certificates for each other.
>
> My three mates and myself, got together over a few beers and decided the
> following was the concesus of the group:
>
> cross-certification:  A requesting CA requests issuance of a
> cross-certificate by a responding CA.  For the purposes of this standard, a
> cross-certificate is considered to be any
> certificate issued by one CA for another CA's signing key pair (that is,
> for another CA's public verification key), regardless of the particular
> surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> organizational relationships between CAs.  Issuance of cross-certificates
> may be, but is not necessarily, mutual, i.e., two CAs may issue
> certificates for each other.
>
> PS: We also promise that we have not patented CA certificates ( but then who
> knows).

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Phillip Hallam-Baker <[email-masked]>
Date:         Mon, 9 Feb 1998 14:56: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: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Sharon Boeyen wrote:
>
> Warwick -  an unfortunate style choice, especially for a message from a
> WG co-chair. Can we please leave issues such as  what "Entrust" insists
> on, and whether or not "Entrust" needs to deal with "real" issues,  off
> the PKIX list.

I think it is more likely that Warwick intended the message to be
private
and did not notice that the reply-to field of messages is now set to
point to the list.

I hope this does not mean that Lynda Tripp has taken over as mailing
list
manager.

                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 48 (????/----) (0001E825)

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 9 Feb 1998 11:34: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] Cross Certification Clarification
Comments: To: [email-masked]
To: [email-masked]
Status:

My question to both the Australian mates and the Canadians (at least 2 out of 3,
I assume, not being sure about Tim):

Do you have a suggested term for repesenting the kind of certificate that is
created unilaterally by one entity (normally a CA) which includes another
entity's (normally another CA) public key, NOT necessarily as a result of a
request by CA which is being certified?

I don't object to the proposed terminology, but it leaves me without an
agreed term for what I believe may be the most common occurance
of what I would have otherwise called a cross-certificate.

Bob

>>> Charles Moore <[email-masked]> 02/08 2:43 PM >>>

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, 9 February 1998 7:05
Subject: [IETF-PKIX] Cross Certification Clarification

:Following on from the thread on Cross-Certification Terminology, Carlisle
:Adams, Tim Polk, and I have agreed on the following, which we believe to
:fairly reflect a concensus of the various views expressed.  In order to
:clarify use of the term "cross-certification" in the PKIX standards, we
:propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
:and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
:existing text in both cases.
:
:cross-certification:  A requesting CA requests issuance of a
:cross-certificate by a responding CA.  For the purposes of this standard, a
:cross-certificate (also known as CA-certificate) is considered to be any
:certificate issued by one CA for another CA's signing key pair (that is,
:for another CA's public verification key), regardless of the particular
:surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
:organizational relationships between CAs.  Issuance of cross-certificates
:may be, but is not necessarily, mutual, i.e., two CAs may issue
:certificates for each other.

My three mates and myself, got together over a few beers and decided the
following was the concesus of the group:

cross-certification:  A requesting CA requests issuance of a
cross-certificate by a responding CA.  For the purposes of this standard, a
cross-certificate is considered to be any
certificate issued by one CA for another CA's signing key pair (that is,
for another CA's public verification key), regardless of the particular
surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
organizational relationships between CAs.  Issuance of cross-certificates
may be, but is not necessarily, mutual, i.e., two CAs may issue
certificates for each other.

PS: We also promise that we have not patented CA certificates ( but then who
knows).

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Mon, 9 Feb 1998 12:56: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: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Warwick -  an unfortunate style choice, especially for a message from a
WG co-chair. Can we please leave issues such as  what "Entrust" insists
on, and whether or not "Entrust" needs to deal with "real" issues,  off
the PKIX list.

Putting that aside, can you provide some substantive clarification, for
the benefit of the WG participants on:
-  Specifically which aspects of the definition do you consider trivial
and
   why do you "not like" the definition?
-  What do you consider the "real" issues to be.

Thanks,
Sharon

------------------
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:  February 9, 1998 1:11 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross-certification
>
>Michael:
>
>
>I don't like the definition of cross-certification either, but it is
>better than not having a precise definition at all.  Entrust insisted on
>this trivial definition, since they do not face the need to deal with the
>real issues.  I want to continue working on the type of issue you raise
>but propose we do that under the topic "inter-domain certification".
>
>
>Warwick
>

Approved-By:  Santoni Adriano <[email-masked]>
Date:         Mon, 9 Feb 1998 18:01:29 +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] Cross-certification
To: [email-masked]
Status:

I agree with Peter. Either the "cross" it dropped, or it should make
some sense.
IMO, the concept of "crossing" something does not have anything to do
with the mere concept of issuing a certificate to a subject CA. Crossing
implies creating some sort of "bridge" for connecting two "worlds" or,
in practice, two domains (PKI's) X and Y which initially were born with
potentially different rules, for servicing potentially different
communities, in support of potentially different applications. At a
certain point in time, the two communities acknowledge the fact that the
need/want interoperability. Then, two comparable trust points (i.e. the
two (root) CA's of the two domains X and Y) examine the suitability of
establishing a parithetical trust relationship with each other, possibly
a unilateral one. Eventually, if all conditions are met, one of the two
CA's issues a cross-cert for the other CA, and possibly viceversa, with
the result that one or both of the two communities X and Y have the
possibility of automatically validate some (or all) types of
certificates issued by the other community's CA, and possibly viceversa.
That's my understanding of what cross-certification means. It is thus a
different and more complicated thing than issuing certificates for
subject CA's.
The inner organization of the two involved PKI's may not be relevant, in
principle, as regards the feasibility and suitability of
cross-certification.

  Adriano

> -----Messaggio originale-----
> Da:   Peter Sylvester [SMTP:[email-masked]]
> Inviato:      luned“ 9 febbraio 1998 17.14
> A:    [email-masked]
> Oggetto:      Re: [IETF-PKIX] Cross-certification
>
> >
> > I don't like the definition of cross-certification either, but it is
> > better than not having a precise definition at all.  Entrust
> insisted on
> > this trivial definition, since they do not face the need to deal
> with the
> > real issues.  I want to continue working on the type of issue you
> raise
> > but propose we do that under the topic "inter-domain certification".
> >
> Can you tell what do you mean by 'real issues'?
>
> Btw: IMHO the definition is not trivial but might be
> considered rather confusing, it mentions:
>
> "... regardless of the particular surrounding structure of CAs
>    (e.g., hierarchy or web) and regardless of the organizational
>    relationships between CAs."
>
> What is meant by SURROUNDING ? What is the meaning of 'structure
> of CAs'? what means 'regardless'? And what would be the purpose of
> that
> cert in this situation?
>
>
> Thanks in advance
> Peter Sylvester -- EdelWeb France

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Mon, 9 Feb 1998 17:13:44 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

>
> I don't like the definition of cross-certification either, but it is
> better than not having a precise definition at all.  Entrust insisted on
> this trivial definition, since they do not face the need to deal with the
> real issues.  I want to continue working on the type of issue you raise
> but propose we do that under the topic "inter-domain certification".
>
Can you tell what do you mean by 'real issues'?

Btw: IMHO the definition is not trivial but might be
considered rather confusing, it mentions:

"... regardless of the particular surrounding structure of CAs
   (e.g., hierarchy or web) and regardless of the organizational
   relationships between CAs."

What is meant by SURROUNDING ? What is the meaning of 'structure
of CAs'? what means 'regardless'? And what would be the purpose of that
cert in this situation?

Thanks in advance
Peter Sylvester -- EdelWeb France

Approved-By:  "Arsenault, Al W." <[email-masked]>
Date:         Mon, 9 Feb 1998 11:02: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: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Why should we address Michel's issues under the topic of "inter-domain
certification"?  To me, that's exactly what has always been meant by
"cross-certification", and I'd personally rather see those issues
addressed under that topic than introduce yet another term that will
only serve to confuse everybody.

                Al Arsenault

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

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  Monday, February 09, 1998 1:11 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross-certification
>
>Michael:
>
>
>I don't like the definition of cross-certification either, but it is
>better than not having a precise definition at all.  Entrust insisted on
>this trivial definition, since they do not face the need to deal with the
>real issues.  I want to continue working on the type of issue you raise
>but propose we do that under the topic "inter-domain certification".
>
>
>Warwick
>
>
>
>At 10:40 AM 2/9/98 +0100, Michel Beretta wrote:
>
>>>>>
>
><excerpt>Warvick,
>
>
>I found this definition you made in the ietf-pkix mailing list.
>
>
>-----------------------------------------------------------------------
>
>cross-certification:  A requesting CA requests issuance of a
>
>cross-certificate by a responding CA.  For the purposes of this standard,
>a
>
>cross-certificate (also known as CA-certificate) is considered to be any
>
>certificate issued by one CA for another CA's signing key pair (that is,
>
>for another CA's public verification key), regardless of the particular
>
>surrounding structure of CAs (e.g., hierarchy or web) and regardless of
>the
>
>organizational relationships between CAs.  Issuance of cross-certificates
>
>may be, but is not necessarily, mutual, i.e., two CAs may issue
>
>certificates for each other.
>
>--------------------------------------------------------------------
>
>
>This is very clear, and I understand from this definition that a
>cross-certificate is no more than a non-self-signed CA-Certificate.
>
>
>In my previous understanding, cross-certification was dealing with
>sharing trust between two independant security domains.
>
>
>Let's imagine two independant CA hierarchies, one CA from hierarchy (1)
>wants to be trusted by another CA from another hierachy (2). It will
>request a certificated from this other CA (2) and have a new certificate,
>different from the first it was given in his first hierarchy.
>
>- Don't you think this kind of certificate has a special meaning?
>
>- <bold>How would you call such certificates </bold>which allow a CA to
>be trusted in several hierarchy/web?
>
>- Does CMP address the issue of managing multiple certificates for each
>CA?
>
>
>I know this is not a "natural" way of thinking, but I wonder if the big
>issue to manage "cross-security domain managemnt " is to forget the
>hierarchy certification model and allow CAs to have multiple Parent-CA,
>
>and be able to manage that.
>
>Does it make sense?
>
>
>Thank you for your feed back.
>
>Michel.
>
>
>
>
>
>
>--
>
>-------------------------------------------------------------------
>
>Michel BERETTA
>
>HEWLETT PACKARD - Internet Communication Appliances Division
>
>5,avenue Raymond Chanas 38053  GRENOBLE Cedex 9 FRANCE
>
>Phone: +33-(0)4.76.14.40.83 - FAX: +33-(0)4.76.14.12.86
>
><<mailto:[email-masked]>mailto:[email-masked] -
><<http://icad.grenoble.hp.com>http://icad.grenoble.hp.com
>
>-------------------------------------------------------------------
>
>
>
></excerpt>
>
>
>
>
>---------------------------------------------------------------------
>
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>
>---------------------------------------------------------------------
>

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 9 Feb 1998 10:11:23 -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
Comments: To: [email-masked]
To: [email-masked]
Status:

<x-rich>Michael:

I don't like the definition of cross-certification either, but it is
better than not having a precise definition at all.  Entrust insisted on
this trivial definition, since they do not face the need to deal with the
real issues.  I want to continue working on the type of issue you raise
but propose we do that under the topic "inter-domain certification".

Warwick

At 10:40 AM 2/9/98 +0100, Michel Beretta wrote:

>>>>

<excerpt>Warvick,

I found this definition you made in the ietf-pkix mailing list.

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

cross-certification:  A requesting CA requests issuance of a

cross-certificate by a responding CA.  For the purposes of this standard,
a

cross-certificate (also known as CA-certificate) is considered to be any

certificate issued by one CA for another CA's signing key pair (that is,

for another CA's public verification key), regardless of the particular

surrounding structure of CAs (e.g., hierarchy or web) and regardless of
the

organizational relationships between CAs.  Issuance of cross-certificates

may be, but is not necessarily, mutual, i.e., two CAs may issue

certificates for each other.

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

This is very clear, and I understand from this definition that a
cross-certificate is no more than a non-self-signed CA-Certificate.

In my previous understanding, cross-certification was dealing with
sharing trust between two independant security domains.

Let's imagine two independant CA hierarchies, one CA from hierarchy (1)
wants to be trusted by another CA from another hierachy (2). It will
request a certificated from this other CA (2) and have a new certificate,
different from the first it was given in his first hierarchy.

- Don't you think this kind of certificate has a special meaning?

- <bold>How would you call such certificates </bold>which allow a CA to
be trusted in several hierarchy/web?

- Does CMP address the issue of managing multiple certificates for each
CA?

I know this is not a "natural" way of thinking, but I wonder if the big
issue to manage "cross-security domain managemnt " is to forget the
hierarchy certification model and allow CAs to have multiple Parent-CA,

and be able to manage that.

Does it make sense?

Thank you for your feed back.

Michel.

--

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

Michel BERETTA

HEWLETT PACKARD - Internet Communication Appliances Division

5,avenue Raymond Chanas 38053  GRENOBLE Cedex 9 FRANCE

Phone: +33-(0)4.76.14.40.83 - FAX: +33-(0)4.76.14.12.86

<<mailto:[email-masked]>mailto:[email-masked] -
<<http://icad.grenoble.hp.com>http://icad.grenoble.hp.com

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

</excerpt>

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

Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140

   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716

---------------------------------------------------------------------
</x-rich>

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 9 Feb 1998 10:54:00 -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 Clarification
To: [email-masked]
Status:

Warwick Ford wrote:

> Following on from the thread on Cross-Certification Terminology, Carlisle
> Adams, Tim Polk, and I have agreed on the following, which we believe to
> fairly reflect a concensus of the various views expressed.  In order to
> clarify use of the term "cross-certification" in the PKIX standards, we
> propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
> and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
> existing text in both cases.

Thanks for providing this input.

> cross-certification:  A requesting CA requests issuance of a
> cross-certificate by a responding CA.

Do we really need to use (and thus define) that term ? However we surely
need to say what is a "cross-certificate" versus a "CA-certificate". I
would prefer to use "cross-certificate request" instead, keep the same
definition and thus have :

"Cross-certificate request: A requesting CA requests issuance of a
cross-certificate by a responding CA."

> For the purposes of this standard, a cross-certificate (also
> known as CA-certificate) is considered to be any certificate

So, the option that is presented is the case where a cross-certificate
is fully equivalent to a CA-certificate.

It is difficult to say where the consensus was/is, but I had the feeling
that there existed a difference between the two notions, but that we did
not reached an agreement on the exact wording.

In other words, a CA-certificate applies to any kind of relationship
between CAs, whereas a cross-certificate only applies when, at the time
of the issuance of the CA-certificate, there is no particular
surrounding structure for the two CAs (e.g., hierarchy or web) nor
particular organizational relationships between the two CAs.

Whether a "cross-certificate request" is being made or a "CA-certificate
request" is being made, the protocol to be used is the same.

> issued by one CA for another CA's signing key pair (that is,
> for another CA's public verification key), regardless of the particular
> surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> organizational relationships between CAs.  Issuance of cross-certificates
> may be, but is not necessarily, mutual, i.e., two CAs may issue
> certificates for each other.

  cross-certificates for each other.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Charles Moore <[email-masked]>
Date:         Mon, 9 Feb 1998 07:43:30 +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 Clarification
To: [email-masked]
Status:

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, 9 February 1998 7:05
Subject: [IETF-PKIX] Cross Certification Clarification

:Following on from the thread on Cross-Certification Terminology, Carlisle
:Adams, Tim Polk, and I have agreed on the following, which we believe to
:fairly reflect a concensus of the various views expressed.  In order to
:clarify use of the term "cross-certification" in the PKIX standards, we
:propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
:and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
:existing text in both cases.
:
:cross-certification:  A requesting CA requests issuance of a
:cross-certificate by a responding CA.  For the purposes of this standard, a
:cross-certificate (also known as CA-certificate) is considered to be any
:certificate issued by one CA for another CA's signing key pair (that is,
:for another CA's public verification key), regardless of the particular
:surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
:organizational relationships between CAs.  Issuance of cross-certificates
:may be, but is not necessarily, mutual, i.e., two CAs may issue
:certificates for each other.

My three mates and myself, got together over a few beers and decided the
following was the concesus of the group:

cross-certification:  A requesting CA requests issuance of a
cross-certificate by a responding CA.  For the purposes of this standard, a
cross-certificate is considered to be any
certificate issued by one CA for another CA's signing key pair (that is,
for another CA's public verification key), regardless of the particular
surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
organizational relationships between CAs.  Issuance of cross-certificates
may be, but is not necessarily, mutual, i.e., two CAs may issue
certificates for each other.

PS: We also promise that we have not patented CA certificates ( but then who
knows).

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

Attachment converted: Lutefisk:smime.p7s 47 (????/----) (0001E7BF)

Approved-By:  Warwick Ford <[email-masked]>
Date:         Sun, 8 Feb 1998 15:57: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: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Following on from the thread on Cross-Certification Terminology, Carlisle
Adams, Tim Polk, and I have agreed on the following, which we believe to
fairly reflect a concensus of the various views expressed.  In order to
clarify use of the term "cross-certification" in the PKIX standards, we
propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
existing text in both cases.

cross-certification:  A requesting CA requests issuance of a
cross-certificate by a responding CA.  For the purposes of this standard, a
cross-certificate (also known as CA-certificate) is considered to be any
certificate issued by one CA for another CA's signing key pair (that is,
for another CA's public verification key), regardless of the particular
surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
organizational relationships between CAs.  Issuance of cross-certificates
may be, but is not necessarily, mutual, i.e., two CAs may issue
certificates for each other.

Warwick

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

Approved-By:  Robert Moskowitz <[email-masked]>
Date:         Fri, 6 Feb 1998 13:35:50 -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: Robert Moskowitz <[email-masked]>
Subject:      [IETF-PKIX] Joint X.509 / IPsec discussion
Comments: To: [email-masked]
To: [email-masked]
Status:

This has been long overdue, and a long time coming, but I am arranging a
meeting for CA software companies and IPsec technologists to discuss the
issues surrounding use of X.509 certificates by IPsec and the interaction
of IPsec products with CA software products.

We are planning this meeting for Feb 19th at BBN/GTE's facility in the
Boston area.  Plan on a full day meeting.  I suspect that around 12 CA
software companies, averaging 2 people would attend with around 6 - 10
IPsec specialists (space planing for Pat Cain).

The goal of this meeting would be to establish the X.509/CA guidelines so
that CA software vendors can attend the IPsec workshop the week of March
2nd in Raleigh NC to address product interoperabilty.

This meeting will also have as its goal to investigate the realm of CA
software certification, ie is the software delivering the security services
as specified.

An agenda will follow.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Approved-By:  "Phillip H. Griffin" <[email-masked]>
Date:         Wed, 4 Feb 1998 21:26:53 -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] User Notice fields (short line lengths.)
To: [email-masked]
Status:

Bob Jueneman wrote:
>
snip
>
> ---
>
> I've been trying to think about how to implement both CA and user
> notices in a multilingual environment.
>
> And the more I think about it, the more I think the current
> mechanism is pretty badly broken,.
>
> In <draft-ietf-pkix-part1-06.txt>, paragraph 4.2.1.5 Certificate
> Policies, UserNotice is defined as
>
> UserNotice ::= SEQUENCE {
>   noticeRef     NoticeReference OPTIONAL,
>   explicitText   DisplayText OPTIONAL}
>
> As I interpret that, the CA is free to include as many
> noticeRefs or explictText sequences as might be desired
> within the certificate.
>
> However, the noticeRef merely names an organization (in
> IA5String, which obviously limits the kinds of organizations
> that can be named to those with European language names) and
> provides a message number.
>

The IA5String type will only support *some* European names,
not accented characters or characters with umlats. It will
allow all of the ASCII control characters, such as ESC and
DEL, to appear in a value of the type.

> How the application is supposed to know where within an organization
> that message number is defined is a mystery. Presumably it is recorded s
> omewhere on Vogon, and the location communicated by mental telepathy?
> Why wasn't the obvious approach -- a URL to the message -- used for
> this notice field?
>
> The text says that "In a typical implementation, the application software
> will have a notice file for CertsRUs; the application will extract the notice
> file from the file and display it."
>
> I believe that would be very dangerous from a liability standpoint.
>
> If that sentence means that the application statically _contains_ the
> message file, that raises the extremely serious question of what happens
> if the CA changes the message, yet the application is still displaying the
> old one. From a legal standpoint, who is to blame if there is a
> misunderstanding as to the terms and conditions under which the
> certificate was issued?
>
> The text goes on to say that "Messages may be multilingual, allowing
> the software to select the particular language message for its own environment."
>

The text also state that explicitText "is a string with a
maximum size of 200 characters", but there is no size
constraint on type DisplayText (which would be easy to
do if it were a parameterized type like the X.5* type
DirectoryString{}). This would require 400 octets for
a BMPString, but only allow 200 for VisibleString.

> That sounds like a pretty good trick as well.  Normally, for such applications,
> messages need to be multi-cultural, and not just multi-lingual.  In addition to
> minor spelling variations between American English and British (UK) English,
> there are differences in wording, different legal systems, and a whole host of
> other nuance differences to contend with. Consider the differences between
> American English, Indian English, Australian English, and even Canadian
> English (don't ask for a napkin in Nova Scotia when you mean a serviette),
> and that is presumably one language with (in most cases) a common code page.
>
> How is the application supposed to figure out which of the message variants
> to use?  Is it intended that along with the static definition of the message
> content (acquired who knows how), the application would also acquire 128
> variants of a single message and somehow guess which message is supposed
> to be delivered to which user in a particular country? This gets more and
> more interesting.
>
> The definition of noticeNumbers is SEQUENCE OF INTEGER. Are those
> intended to be different notices, each with built-in variants for different
> languages, or are the noticeNumbers themselves supposed to be different
> for each language or cultural variant?

Since the SEQUENCE OF in noticeNumbers is not constrained,
it appears that it might be null, containing zero integers.
This may cause problems. A size constraint here, 1..MAX,
might be helpful.

>
> In the same manner, I conclude that the UserNotice field can contain multiple
> explictText fields, each of which is represented in either VisibleString or BMPString.
> Wonderful.  Now I can encode messages in 120 languages, most of which are
> represented in BMPString, and display them all to the poor user, who watches
> page after page scroll by in languages he can't read.
>
> The text also states that "If both the noticeRef and explicitText options are
> included ion the one qualifier and if the application software can locate the
> notice text indicated by the noticeRef option then that text should be
> displayed; otherwise, the explicitText string should be displayed."
>
> That seems to be broken as well. Since the definition allows a SEQUENCE
> (not CHOICE) of two optional forms, noticeRef and explicitText, any
> assumption that a pair of noticeRef and explictText fields are supposed to
> correspond seems unwarranted.  What is supposed to happen if there is
> one noticeRef and two explicitText fields?
>
> In addition to these problems, the entire concept seems to be rather
> CA-centric, and ignores the possibility of a SUBSCRIBER who wishes
> to include some caveats or limitations of use on his certificate to protect
> himself and his organization, rather than just protecting the CA's interests.
>
> Obviously application software is not going to have a built-in list of
> numbered organizational messages (joke numbers) for all possible users.
> So either a URL or an explicit text is the only possible choice.
>
> Since in many cases all of the user's within a given organization would
> have the same userNotice associated with their certificates, a URL would
> seem to be most appropriate.
>
> Finally, although we had discussed the need for a message digest which
>  would apply to any message which is incorporated by reference into a
> certificate (so that the CA or the user can't change the message content
> after the certificate is issued without the change being detected), the
> noticeRef fields do not include such a provision.
>
> I hesitate to propose new ASN.1 definitions before I have heard others
> express an opinion, but I am thinking about something along the following lines:
>
> 1.  NoticeReference should probably be something like:
>
> NoticeReference ::= SEQUENCE {
>    noticeUriBase  IA5String,
>    SEQUENCE {
>          noticeCountry  NoticeCountryCode
>              -- somebody pick a format, maybe the currency code,
>           noticeFilename  IA5String
>               --  file name to be appended to the noticeUriBase
>               --  to form a complete URI for the matching country code}
>           noticeMessageDigest  MessageDigestFormat }
>
> 2.  DisplayText (referenced by explicitText) should be defined similarly:
>
> DisplayText ::= SEQUENCE {
>    displayStringType  DisplayStringType,
>    displayCountry  NoticeCountryCode }
>
> 3.  Alternatively, we might leave the country code out of the notice and
> display fields and include them in the UserNotice field instead, something like:
>
> UserNotice  ::= SEQUENCE {
>      CHOICE {
>           noticeRef  NoticeReference
>           explicitText  DisplayText }
>      countryCode  CountryCode }
>
> NoticeReference  ::= SEQUENCE {
>       noticeUri                      IA5String, -- a complete URI
>       noticeMessageDigest  MessageDigestFormat }
>

Shouldn't URIs contain only the non-control characters in
VisibleString?

> Thoughts?
>
> 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."

--
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:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Feb 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: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] User Notice fields (short line lengths.)
To: [email-masked]
Status:

My sincere apologies to those who might not have been able to read
my previous message on the same subject.

It appears that the list server operated by Tandem is erroneously
converting MIME message prepared in quotable-string format to
7-bit format, and in the process stripping off the soft carriage returns
which GroupWise inserts.  As a result, anyone without a MIME reader
would see very long lines, and anyone with a M<IME reader which does
not line wrap would also see long lines.  This is very frustrating.

In addition, it appears that either our gateway or the Tandem list server
is converting messages intended to be sent in non-MIME, simple SMTP
format to MIME format, although I'm not quite as certain about that.  This
message is being prepared and address in non-MIME format -- we'll see
how it shows up.

Anyway, here is the original message, with manually inserted carriage returns.
I hope this is readable.

---

I've been trying to think about how to implement both CA and user notices
in a multilingual environment.

And the more I think about it, the more I think the current mechanism is pretty
badly broken,.

In <draft-ietf-pkix-part1-06.txt>, paragraph 4.2.1.5 Certificate Policies,
UserNotice is defined as

UserNotice ::= SEQUENCE {
  noticeRef     NoticeReference OPTIONAL,
  explicitText   DisplayText OPTIONAL}

As I interpret that, the CA is free to include as many noticeRefs or explictText
sequences as might be desired within the certificate.

However, the noticeRef merely names an organization (in IA5String, which
obviously limits the kinds of organizations that can be named to those with
European language names) and provides a message number.

How the application is supposed to know where within an organization
that message number is defined is a mystery. Presumably it is recorded s
omewhere on Vogon, and the location communicated by mental telepathy?
Why wasn't the obvious approach -- a URL to the message -- used for
this notice field?

The text says that "In a typical implementation, the application software
will have a notice file for CertsRUs; the application will extract the notice
file from the file and display it."

I believe that would be very dangerous from a liability standpoint.

If that sentence means that the application statically _contains_ the
message file, that raises the extremely serious question of what happens
if the CA changes the message, yet the application is still displaying the
old one. From a legal standpoint, who is to blame if there is a
misunderstanding as to the terms and conditions under which the
certificate was issued?

The text goes on to say that "Messages may be multilingual, allowing
the software to select the particular language message for its own environment."

That sounds like a pretty good trick as well.  Normally, for such applications,
messages need to be multi-cultural, and not just multi-lingual.  In addition to
minor spelling variations between American English and British (UK) English,
there are differences in wording, different legal systems, and a whole host of
other nuance differences to contend with. Consider the differences between
American English, Indian English, Australian English, and even Canadian
English (don't ask for a napkin in Nova Scotia when you mean a serviette),
and that is presumably one language with (in most cases) a common code page.

How is the application supposed to figure out which of the message variants
to use?  Is it intended that along with the static definition of the message
content (acquired who knows how), the application would also acquire 128
variants of a single message and somehow guess which message is supposed
to be delivered to which user in a particular country? This gets more and
more interesting.

The definition of noticeNumbers is SEQUENCE OF INTEGER. Are those
intended to be different notices, each with built-in variants for different
languages, or are the noticeNumbers themselves supposed to be different
for each language or cultural variant?

In the same manner, I conclude that the UserNotice field can contain multiple
explictText fields, each of which is represented in either VisibleString or BMPString.
Wonderful.  Now I can encode messages in 120 languages, most of which are
represented in BMPString, and display them all to the poor user, who watches
page after page scroll by in languages he can't read.

The text also states that "If both the noticeRef and explicitText options are
included ion the one qualifier and if the application software can locate the
notice text indicated by the noticeRef option then that text should be
displayed; otherwise, the explicitText string should be displayed."

That seems to be broken as well. Since the definition allows a SEQUENCE
(not CHOICE) of two optional forms, noticeRef and explicitText, any
assumption that a pair of noticeRef and explictText fields are supposed to
correspond seems unwarranted.  What is supposed to happen if there is
one noticeRef and two explicitText fields?

In addition to these problems, the entire concept seems to be rather
CA-centric, and ignores the possibility of a SUBSCRIBER who wishes
to include some caveats or limitations of use on his certificate to protect
himself and his organization, rather than just protecting the CA's interests.

Obviously application software is not going to have a built-in list of
numbered organizational messages (joke numbers) for all possible users.
So either a URL or an explicit text is the only possible choice.

Since in many cases all of the user's within a given organization would
have the same userNotice associated with their certificates, a URL would
seem to be most appropriate.

Finally, although we had discussed the need for a message digest which
 would apply to any message which is incorporated by reference into a
certificate (so that the CA or the user can't change the message content
after the certificate is issued without the change being detected), the
noticeRef fields do not include such a provision.

I hesitate to propose new ASN.1 definitions before I have heard others
express an opinion, but I am thinking about something along the following lines:

1.  NoticeReference should probably be something like:

NoticeReference ::= SEQUENCE {
   noticeUriBase  IA5String,
   SEQUENCE {
         noticeCountry  NoticeCountryCode
             -- somebody pick a format, maybe the currency code,
          noticeFilename  IA5String
              --  file name to be appended to the noticeUriBase
              --  to form a complete URI for the matching country code}
          noticeMessageDigest  MessageDigestFormat }

2.  DisplayText (referenced by explicitText) should be defined similarly:

DisplayText ::= SEQUENCE {
   displayStringType  DisplayStringType,
   displayCountry  NoticeCountryCode }

3.  Alternatively, we might leave the country code out of the notice and
display fields and include them in the UserNotice field instead, something like:

UserNotice  ::= SEQUENCE {
     CHOICE {
          noticeRef  NoticeReference
          explicitText  DisplayText }
     countryCode  CountryCode }

NoticeReference  ::= SEQUENCE {
      noticeUri                      IA5String, -- a complete URI
      noticeMessageDigest  MessageDigestFormat }

Thoughts?

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."

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Feb 1998 10:53: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:      [IETF-PKIX] User Notice fields
To: [email-masked]
Status:

I've been trying to think about how to implement both CA and user notices in a multilingual environment.

And the more I think about it, the more I think the current mechanism is pretty badly broken,.

In <draft-ietf-pkix-part1-06.txt>, paragraph 4.2.1.5 Certificate Policies, UserNotice is defined as

UserNotice ::= SEQUENCE {
  noticeRef     NoticeReference OPTIONAL,
  explicitText   DisplayText OPTIONAL}

As I interpret that, the CA is free to include as many noticeRefs or explictText sequences as might be desired within the certificate.

However, the noticeRef merely names an organization (in IA5String, which obviously limits the kinds of organizations that can be named to those with European language names) and provides a message number.

How the application is supposed to know where within an organization that message number is defined is a mystery. Presumably it is recorded somewhere on Vogon, and the location communicated by mental telepathy?  Why wasn't the obvious approach -- a URL to the message -- used for this notice field?

The text says that "In a typical implementation, the application software will have a notice file for CertsRUs; the application will extract the notice file from the file and display it."

I believe that would be very dangerous from a liability standpoint.

If that sentence means that the application statically _contains_ the message file, that raises the extremely serious question of what happens if the CA changes the message, yet the application is still displaying the old one. From a legal standpoint, who is to blame if there is a misunderstanding as to the terms and conditions under which the certificate was issued?

The text goes on to say that "Messages may be multilingual, allowing the software to select the particular language message for its own environment."

That sounds like a pretty good trick as well.  Normally, for such applications, messages need to be multi-cultural, and not just multi-lingual.  In addition to minor spelling variations between American English and British (UK) English, there are differences in wording, different legal systems, and a whole host of other nuance differences to contend with. Consider the differences between American English, Indian English, Australian English, and even Canadian English (don't ask for a napkin in Nova Scotia when you mean a serviette), and that is presumably one language with (in most cases) a common code page.

How is the application supposed to figure out which of the message variants to use?  Is it intended that along with the static definition of the message content (acquired who knows how), the application would also acquire 128 variants of a single message and somehow guess which message is supposed to be delivered to which user in a particular country? This gets more and more interesting.

The definition of noticeNumbers is SEQUENCE OF INTEGER. Are those intended to be different notices, each with built-in variants for different languages, or are the noticeNumbers themselves supposed to be different for each language or cultural variant?

In the same manner, I conclude that the UserNotice field can contain multiple explictText fields, each of which is represented in either VisibleString or BMPString.  Wonderful.  Now I can encode messages in 120 languages, most of which are represented in BMPString, and display them all to the poor user, who watches page after page scroll by in languages he can't read.

The text also states that "If both the noticeRef and explicitText options are included ion the one qualifier and if the application software can locate the notice text indicated by the noticeRef option then that text should be displayed; otherwise, the explicitText string should be displayed."

That seems to be broken as well. Since the definition allows a SEQUENCE (not CHOICE) of two optional forms, noticeRef and explicitText, any assumption that a pair of noticeRef and explictText fields are supposed to correspond seems unwarranted.  What is supposed to happen if there is one noticeRef and two explicitText fields?

In addition to these problems, the entire concept seems to be rather CA-centric, and ignores the possibility of a SUBSCRIBER who wishes to include some caveats or limitations of use on his certificate to protect himself and his organization, rather than just protecting the CA's interests.

Obviously application software is not going to have a built-in list of numbered organizational messages (joke numbers) for all possible users. So either a URL or an explicit text is the only possible choice.

Since in many cases all of the user's within a given organization would have the same userNotice associated with their certificates, a URL would seem to be most appropriate.

Finally, although we had discussed the need for a message digest which would apply to any message which is incorporated by reference into a certificate (so that the CA or the user can't change the message content after the certificate is issued without the change being detected), the noticeRef fields do not include such a provision.

I hesitate to propose new ASN.1 definitions before I have heard others express an opinion, but I am thinking about something along the following lines:

1.  NoticeReference should probably be something like:

NoticeReference ::= SEQUENCE {
   noticeUriBase  IA5String,
   SEQUENCE {
         noticeCountry  NoticeCountryCode
             -- somebody pick a format, maybe the currency code,
          noticeFilename  IA5String
              --  file name to be appended to the noticeUriBase
              --  to form a complete URI for the matching country code}
          noticeMessageDigest  MessageDigestFormat }

2.  DisplayText (referenced by explicitText) should be defined similarly:

DisplayText ::= SEQUENCE {
   displayStringType  DisplayStringType,
   displayCountry  NoticeCountryCode }

3.  Alternatively, we might leave the country code out of the notice and display fields and include them in the UserNotice field instead, something like:

UserNotice  ::= SEQUENCE {
     CHOICE {
          noticeRef  NoticeReference
          explicitText  DisplayText }
     countryCode  CountryCode }

NoticeReference  ::= SEQUENCE {
      noticeUri                      IA5String, -- a complete URI
      noticeMessageDigest  MessageDigestFormat }

Thoughts?

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."

Approved-By:  Judie Mulholland <[email-masked]>
Date:         Wed, 4 Feb 1998 10:09:17 -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: Judie Mulholland <[email-masked]>
Subject:      [IETF-PKIX] announcing E-CARM, a new mailing list
To: [email-masked]
Status:

Our apologies for any cross posting, but we are anxious to get the word
out asap :)

----------------------------------------------------------------------
              Announcing the creation of a new mailing list:

             ***E-COMMERCE AND RIGHTS MANAGEMENT (E-CARM)***

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

This mailing list has been established to foster and support an on-line
discussion forum where we can:

        * debate (non) technical, administrative and managerial issues
          pertaining to: secure transactions, competing rights management
          models (e.g. ECMS, PICS, certificates, FIRM, etc.), evolving
          standards, supporting technologies and other approaches for
          enabling electronic commerce;
        * inform each other about upcoming conferences, workshops, etc.
        * point to online papers, resources/links, new apps, web
          sites, etc.
        * identify the critical factors relevant to design, development
          and implementation of a rights management infrastructure;
        * raise questions, share problems, relate concerns;
        * share success/horror stories;
        * and much, much more ...

If you are interested in subscribing to this list, please send a message
to:

<[email-masked]>

with the following line in body of the message (NOT the subject):

subscribe e-carm "FirstName LastName" (without the quotation marks)

and after you are notified that you have been subbed, we would ask that
you send a short note to the list, briefly introducing yourself and your
interests in e-commerce and rights management so that we can begin to come
together as a community of shared interest(s).

E-CARM is intended to be a member-driven, open, collaborative mailing
list. However, its success in creating a viable on-line forum will
depend on individual contributions. As a step in this direction, we
encourage you to share this announcement with other mailing lists or
anyone who may be interested in getting involved.

Looking forward to seeing all of you on E-CARM,

Judie Mulholland
Rajiv Kaushik

List Moderators

Approved-By:  "Miklos, Sue A." <[email-masked]>
Date:         Tue, 3 Feb 1998 14:00:58 -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: "Miklos, Sue A." <[email-masked]>
Subject:      Re: [IETF-PKIX] Attribute Cert examples?
To: [email-masked]
Status:

Dave... did you find anything?  The ANSI X9F (certco?) may be an
answer...

Sandi

>----------
>From:  David P. Kemp[SMTP:[email-masked]]
>Sent:  Monday, February 02, 1998 1:23 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Attribute Cert examples?
>
>Does anyone have or know of a publicly-available example of an X.509
>Attribute Certificate?  I'm looking for test data to independently
>validate some parsing software, and for an instance to include in the
>PKIX Part 1 examples appendix.
>
>Thanks,
>  Dave Kemp
>

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Tue, 3 Feb 1998 13:27: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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: Attributes clarification in 509
To: [email-masked]
Status:

John,

You're absolutely correct and thanks for catching that. During last
week's meeting Warwick mentioned the directions as well and I said I'd
double check whether I had them correct or not. I'll revise the text
before ballot as follows:

"Clause 8
(Add the following text immediately following the asn.1 for
certificatePair)

The cACertificate attribute, held in a particular CA's directory entry,
may be used to store self-signed certificates.

Note - The cACertificate attribute should not be confused with the
defined term CA-certificate.

The crossCertificatePair attribute, held in a particular CA's directory
entry,  may be used to store certificates issued by this CA to other
CAs, as well as certificates issued for this CA by other CAs. Values
held in the forward element are certificates issued for this CA by other
CAs, while values in the reverse element are certificates issued by this
CA for other CAs. Either certificate, if present,  may be used in
building certificate paths for validation and may be published in the
directory entries of either CA or both. "

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

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

>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 3 Feb 1998 10:02: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Tag type for rfc822name
Comments: To: [email-masked]
To: [email-masked]
Status:

> From: Nilsson Hans <[email-masked]>

> The question is: Should it use IMPLICIT or EXPLICIT tags?
> Below are two extracts from PKIX-1, which uses IMLICIT in one example
> and EXPLICIT in another.
>
> Which way has it been implemented in existing S/MIME products? Can they
> handle both IMPLICIT and EXPLICIT coding of rfc822Name?

There can be only one correct encoding, otherwise DER would not be unique.

> Here are the examples from PKIX-1:
> ------------------------ IMPLICIT TAG:
> ------------------------------------------
> 0606 a3 1d         29: . . [3]
> 0608 30 1b         27: . . . SEQUENCE
> 0610 30 19         25: . . . . SEQUENCE
> 0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
> 0617 04 12         18: . . . . . OCTET STRING
>                      : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
>                      : 6f 76
>
> 0000 30 10         16: SEQUENCE
> 0002 81 0e         14: . [1]
>                      : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
> Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
> note is taken from PKIX-1!)

When I wrote that note in PKIX-1, I intended to call attention to the
fact that there appeared to be an error in the software that generated
that example.  I wasn't confident enough to phrase it as a definite
statement that THIS EXAMPLE IS WRONG, but intended to warn developers
that there might be a problem.

I am confident now that GeneralName must be encoded using EXPLICIT TAGS,
and that the above example is indeed incorrect.

> I have consulted different experts and of course received different
> reponses:
>
> Response A:
>     [must be IMPLICIT]
>
> Response B:
>     [must be EXPLICIT]
>
> Response C:
>     [rfc822Name is IMPLICIT but directoryName is EXPLICIT]

Wow, that response C is really creative!  I like it :-).

But I still hope that ASN.1 experts will step forward to confirm that
Response B is the correct one.

Approved-By:  John Pawling <[email-masked]>
Date:         Tue, 3 Feb 1998 10:35: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: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: Attributes clarification in 509
To: [email-masked]
Status:

Sharon and friends,

The use of "forward" and "reverse" in Sharon's message seems contradictory
to the definitions stated in the X.509 spec, Section 8, Intro, which defines
forward and reverse as follows:

"If user A, trying to obtain the public key of user B, has already obtained
the public key of CA(B), then the process is complete. In order to enable A
to obtain the public key of CA(B), the directory entry of each Certification
Authority, X, contains a number of certificates. These certificates are of
two types. First there are forward certificates of X generated by other
Certification Authorities. Second there are reverse certificates generated
by X itself which are the certified public keys of other certification
authorities. The existence of these certificates enables users to construct
certification paths from one point to another."

Recommend that the X.509 editors should ensure that their use of forward and
reverse is consistent thorughout the document.

================================
John Pawling
[email-masked]
J.G. Van Dyke & Associates, Inc.
================================

At 07:58 AM 2/3/98 -0500, Sharon Boeyen wrote:
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>
>>----------
>>From:  Sharon Boeyen
>>Sent:  February 2, 1998 11:25 AM
>>To:    [email-masked]'
>>Subject:       Attributes clarification in 509
>>
>>As promised,
>>
>>Here is the text that was agreed at last week's X.509 meeting to clarify the
>>use of the cACertificate and crossCertificatePair attributes. This text
>>change to X.509 forms the draft technical corrigendum for defect report 185
>>and will be sent for ballot by ISO.
>>
>>"Clause 8
>>(Add the following text immediately following the asn.1 for certificatePair)
>>
>>The cACertificate attribute, held in a particular CA's directory entry, may
>>be used to store self-signed certificates.
>>
>>Note - The cACertificate attribute should not be confused with the defined
>>term CA-certificate.
>>
>>The crossCertificatePair attribute, held in a particular CA's directory
>>entry,  may be used to store certificates issued by this CA to other CAs, as
>>well as certificates issued for this CA by other CAs. Values held in the
>>forward element are certificates issued by this CA to other CAs, while values
>>in the reverse element are certificates issued for this CA by other CAs.
>>Either certificate, if present,  may be used in building certificate paths
>>for validation and may be published in the directory entries of either CA or
>>both. "
>>
>>------------------
>>
>>Hoyt will be sending another liaison statement to the IETF giving an update
>>of the other work being done in the 509 group and when I've completed the
>>editing task for the 509 enhancements wd and its made available on the Bull
>>server, we'll send another message to the list.
>>
>>
>>------------------
>>Sharon Boeyen
>>Entrust Technologies
>>
>>mailto:[email-masked]       Tel: (613) 247-3181
>>http://www.entrust.com          Fax: (613) 247-3690
>>         Orchestrating Enterprise Security
>>
>>
>

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Tue, 3 Feb 1998 07:58:56 -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] FW: Attributes clarification in 509
To: [email-masked]
Status:

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

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

>----------
>From:  Sharon Boeyen
>Sent:  February 2, 1998 11:25 AM
>To:    [email-masked]'
>Subject:       Attributes clarification in 509
>
>As promised,
>
>Here is the text that was agreed at last week's X.509 meeting to clarify the
>use of the cACertificate and crossCertificatePair attributes. This text
>change to X.509 forms the draft technical corrigendum for defect report 185
>and will be sent for ballot by ISO.
>
>"Clause 8
>(Add the following text immediately following the asn.1 for certificatePair)
>
>The cACertificate attribute, held in a particular CA's directory entry, may
>be used to store self-signed certificates.
>
>Note - The cACertificate attribute should not be confused with the defined
>term CA-certificate.
>
>The crossCertificatePair attribute, held in a particular CA's directory
>entry,  may be used to store certificates issued by this CA to other CAs, as
>well as certificates issued for this CA by other CAs. Values held in the
>forward element are certificates issued by this CA to other CAs, while values
>in the reverse element are certificates issued for this CA by other CAs.
>Either certificate, if present,  may be used in building certificate paths
>for validation and may be published in the directory entries of either CA or
>both. "
>
>------------------
>
>Hoyt will be sending another liaison statement to the IETF giving an update
>of the other work being done in the 509 group and when I've completed the
>editing task for the 509 enhancements wd and its made available on the Bull
>server, we'll send another message to the list.
>
>
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>

Approved-By:  Nilsson Hans <[email-masked]>
Date:         Tue, 3 Feb 1998 11:49: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: Nilsson Hans <[email-masked]>
Subject:      [IETF-PKIX] Tag type for rfc822name
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

I am editing the revision a certificate specification for the national
Swedish Electronic Identity Card (see www.seis.se), to harmonize it with
the certificate specifications of PKIX-1 and S/MIME. I am also going to
include examples of DER-coded certificates. In that context I have come
across different ways of encoding the subjectAltName rfc822Name
extension. The question is: Should it use IMPLICIT or EXPLICIT tags?
Below are two extracts from PKIX-1, which uses IMLICIT in one example
and EXPLICIT in another.

Which way has it been implemented in existing S/MIME products? Can they
handle both IMPLICIT and EXPLICIT coding of rfc822Name?

Here are the examples from PKIX-1:
------------------------ IMPLICIT TAG:
------------------------------------------
0606 a3 1d         29: . . [3]
0608 30 1b         27: . . . SEQUENCE
0610 30 19         25: . . . . SEQUENCE
0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
0617 04 12         18: . . . . . OCTET STRING
                     : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
                     : 6f 76

0000 30 10         16: SEQUENCE
0002 81 0e         14: . [1]
                     : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
note is taken from PKIX-1!)
-----------------------EXPLICIT TAG:
----------------------------------------------------
               30 3d
                  id-ce-subjectAltName = { 2 5 29 17 }
                  06 03 55 1d 11
                  by default, critical = FALSE
                  octet string
                  04 36
                     30 34
                        rfc822name
                        a1 1a
                           IA5String "[email-masked]"
                           16 18 65 73 63 65 72 74 2d 75 70 63 40 65 73
63
                           65 72 74 2e 75 70 63 2e 65 73
 ---------------------------------------------------------------
I have consulted different experts and of course received different
reponses:

Response A:
The Certificate Extensions module uses specifies IMPLICIT tags
('DEFINITIONS IMPLICIT TAGS ::= BEGIN ...).  Hence, IMPLICIT tags must
be used for selecting the 'rfc822Name' (e-mail) choice in the
'subjectAltName' extension.

Response B:

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.

Response C:
In the definition of GeneralName we have
rfc822Name              [1]     IA5String,
directoryName           [4]     Name,

And from X.680:
>     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.
With rfc822name, the Type is IAString, which means that IMPLICIT should
be used
BUT for directoryName the Type is Name, which is a CHOICE, which means
that EXPLICIT should be used.
------------------------------------------------------------------------
------------------------------------
Looking forward to your help!

Hans Nilsson
AU-System
Stockholm, Sweden

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 2 Feb 1998 14:28:02 -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] Attribute Cert examples?
Comments: To: [email-masked]
To: [email-masked]
Status:

Has such an animal even been completely defined yet?  I though X9 was still working on the spec.

I'll be interested to se what kind of a reply you receive.

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."

>>> "David P. Kemp" <[email-masked]> 02/02 11:23 AM >>>
Does anyone have or know of a publicly-available example of an X.509
Attribute Certificate?  I'm looking for test data to independently
validate some parsing software, and for an instance to include in the
PKIX Part 1 examples appendix.

Thanks,
  Dave Kemp

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 2 Feb 1998 13:23: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: "David P. Kemp" <[email-masked]>
Subject:      [IETF-PKIX] Attribute Cert examples?
To: [email-masked]
Status:

Does anyone have or know of a publicly-available example of an X.509
Attribute Certificate?  I'm looking for test data to independently
validate some parsing software, and for an instance to include in the
PKIX Part 1 examples appendix.

Thanks,
  Dave Kemp

Approved-By:  Olivier Onimus <[email-masked]>
Date:         Mon, 2 Feb 1998 12:04:03 +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: Olivier Onimus <[email-masked]>
Subject:      [IETF-PKIX] Time Stamp and Hash Alg
Comments: cc: Rob Zuccherato <[email-masked]>
To: [email-masked]
Status:

Hi,

I have one question and one suggestion about time-stamp:

In PKIX Part V Time Stamp Protocols, the
data to be time-stamped must have the form:

MessageImprint ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentifier,
     hashedMessage OCTET STRING}

And  AlgorithmIdentifier  is definesd as:
  AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

For most of the implementations realised with standard
ASN.1-Tools-and-compilers,
this means that SW must "know" in advance all the
accepted Alg.-OIDs to link the expected parameter to them.

Now my question:

   Is there a profile of the supported hash-algorithms with the
   corresponding parameter-syntaxes ?

Now a remark:
   A time-Stamp-Server does NOT need the crypto-algorithm like an application
   which must decrypt data or check a signature !
   It just has to notice "OK, the client did hash the data with this alg.,
and that's
   all (anyway, the server has no chance to control that the received data
   are the correct result of the specified algorithm !).
   So, why should a Time-Stamp-Implementation be limited by the
   hash-algorithms it can decode ?
   IMO, a construct like:
   AlgorithmIdentifierTS  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              OCTET STRING OPTIONAL
                                -- contains DER-coding of parameters of OID
                                -- identified by algorihtm
                               }

   would still allow the TimeStamp-Server to control the used OID, but had
the benefit,
   that ASN.1-SW does not have to be modified for every new hash-algorithm !

Any opinion ?

Bye.

Olivier

 _______________________________________________________________________
 Olivier Onimus
 Danet GmbH, Business Unit Telecommunications Technology
 Gutenbergstrasse 10, D-64331 Weiterstadt, Germany
 Tel: +49-6151-868-127   Fax: +49-6151-868-264   E-mail: [email-masked]
 _______________________________________________________________________

Approved-By:  Simonetti David <[email-masked]>
Date:         Sun, 1 Feb 1998 10:53: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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Usage
Comments: To: Rodney Thayer <[email-masked]>
To: [email-masked]
Status:

Rodney,

I had forwarded the following shortly after the Washington meeting.  The minimal
response I received was favorable, but I never received an absolute response from
the PKIX-1 authors...

Tim (et al),

As you stated at the meeting last week with respect to the key usage profile, I
agree that PKIX should not restrict the bit combinations.  However, I think the
previous discussions on this topic proved obvious that there are multiple
interpretations of these bits.

In an attempt to clarify the meaning of several of the bits, I suggest
the following editorial changes to PKIX-1:

Section 4.2.1.3, paragraph beginning with "The digitalSignature bit is
asserted...", add the following, "The digitalSignature bit should be set
when the key is for use in ephemeral applications, e.g., for a single
session authentication application."

Paragraph beginning with "The nonRepudiation bit is asserted...", add
the following, "The nonRepudiation bit should be set when when the key
is used to sign an object which may require the validation of the
signature at a future time."

I also suggest adding, "If the key may be used for both digitalSignature
and nonRepudiation applications, both bits may be set."

Finally, after the descriptions of encipherOnly and decipherOnly I
suggest adding the following:

"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 own certificate
with bits 4 and 8 along with the message."

Dave S.
(I will be out of e-mail contact 2-9 Feb.)

Rodney Thayer wrote:

> >X-Mailer: Mozilla 4.03 [en] (Win95; U)
> >Approved-By:  Simonetti David <[email-masked]>
> >Date:         Fri, 30 Jan 1998 12:55:39 -0500
> Gentlemen, with all due respect some of us don't care what X.509 says we
> want to make the PKIX IETF documents clear.
>
> So what do you want the PKIX document to say?  And, in IEFT style, can you
> specify which document and where you would like the text changed?
>
> -- Rodney Thayer <[email-masked]>

Approved-By:  Warwick Ford <[email-masked]>
Date:         Fri, 27 Feb 1998 11:49:11 -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] CMP Progression
To: [email-masked]
Status:

The CMP editors have completed the editorial changes resulting from Last
Call and IESG member comments, and implemented the document-split as agreed
at the Washington IETF PKIX meeting.  The result is a pair of documents
just posted in the I-D directories as:
     "draft-ietf-pkix-ipki3cmp-07.txt"  and
     "draft-ietf-pkix-crmf-00.txt"

These documents will now be submitted back to the IESG with a
recommendation for publication as RFCs specifying Proposed Standards.

Congratulations to the editors for their relentless efforts to resolve the
issues surrounding these documents!

Warwick

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

Approved-By: [email-masked]
Date:         Thu, 26 Feb 1998 16:52:15 -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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]
Status:

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjYvMTk5OCAxOjIyOjQzUE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBNZXNzYWdlIFVuZGVsaXZl
cmFibGUgdG8gY2M6TWFpbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLQ0K

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogUG9zdG1hc3RlciBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjYvMTk5OCAxMjozOTo0NlBNDQpU
bzogSUVURi1QS0lYQExJU1RTLlRBTkRFTS5DT01fYXRfSU5URVJORVQgYXQgWDQwMFBPDQpi
Y2M6IEtFVklOIFNIQVZFUg0KU3ViamVjdDogUmU6IFtJRVRGLVBLSVhdIE9DU1AgQ3VycmVu
dCBTdGF0dXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0NCg==

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authoriz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authoriz"

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogcGF1bGhAaW1jLm9yZ19hdF9JTlRFUk5F
VCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov

>>I vote for striking it and saying all responses SHOULD be signed. Further,
>you
>>should add something saying that a client SHOULD check if the response is
>>signed and if it's not, to check a policy for whether or not it should
>trust
>>unsigned responses
>
>But aren't these statements inconsistent?  Noting reliance on a local
>security policy configuration to enforce non-use of unsigned responses
>strongly suggests that OCSP clients implement the capability to do so.  I
>agree that noting the security risks of unsigned responses can make our
>intent more clear.

I don't think they're inconsistent. The first sentence says, in a backward
way,
some valid responses might not be signed. Thus, the second sentence says, in
essence, "because there are two kinds of responses (signed and unsigned), a
client should have a policy for each". Obviously, the policy for signed
responses is to accept them, but the second sentence stresses that there
should
be a policy for unsigned responses. Different wording to the same end would
be
fine with me.

>>>Regarding the notion of an element in the query to specify signed vs.
>>>unsigned responses, I would put it the other way around: the client
SHOULD
>>>be capable of handling either.
>>
>>Nope, I disagree. I think it is fine to create a client that always
rejects
>>unsigned responses.
>
>I would distinguish between a client which is technically incapable of
>handling unsigned responses from one that has a configurable capability to
>not to do so.

Yup.

>  I agree the former is compliant to an interpretation of
>SHOULD.  However, my model here is to compare this capability to an SMIME
UA
>that can only handle signed mail.

We had this argument last year in the S/MIME WG, and it wasn't resolved. My
take on this level of argument is "a client that refuses to do XYZ has a
policy
that says 'don't do XYZ'." If the protocol says "clients {SHOULD|MAY} do
XYZ",
clients that refuse to do XYZ still conform because they have a policy that
says "XYZ is always wrong in this environment".

>>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
>problem
>>with getting two independant interoperable implementations, then you have
>to
>>move to ASN.1. There's already been questions about the extensibility of
>the
>>ABNF.
>
>
>I must disagree.  I have seem more interoperability problems with ASN.1
than
>things such as ABNF, particularly if the problem wasn't an ASN.1-class
>problem in the first place.

Please note that your response ignored mine. This working group has the
option
of deciding whether or not a specification has any chance of getting two
independant interoperable implementations. If it decides that the way you've
specified your protocol will make that hard, the working group can demand
that
your protocol be changed, even if the bits on the wire don't change. Further,

if this working group decides that your ABNF works for OCSP 1 but is
non-extensible, the working group can reject it for that reason alone. I'm
not
advocating this, since I happen to like ABNF more than ASN.1, but it is up
to
the working group, not the draft editor.

>I agree that the list is our most productive tool for closure. That said,
>small focussed groups can and do help improve the pace of the standards
>process. The S/MIME group's efforts are good example.

Good example. The proprietary S/MIME v2 standard moved forward based on
small,
closed group meetings. It took forever to stabalize. The last closed
meeting of
that group (where you and I shared pizza) ended up muddying the waters with
respect to S/MIME v2's certificate handling.

Since S/MIME v3 has come into the IETF, essentially all of the movement has
been made based on the mailing list. Very little new came from the
Washington
DC meeting, and the small ad hoc meeting that happened in San Francisco in
January did help move a few things, but in fact those things have been
mostly
changed since being discussed openly on the mailing list.

I still urge you not to delay OCSP by waiting for the LA meeting. You have
lots
of input for the current draft. A new draft will help get even more input
and
move towards closure (modulo the Entrust submarine patent, of course).

--Paul Hoffman, Director
--Internet Mail Consortium

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_897.34f5e438.im71218v.hqrtmta1.doe.gov--

Approved-By: [email-masked]
Date:         Thu, 26 Feb 1998 13:22: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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]
Status:

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjYvMTk5OCAxMjozOTo0NlBNDQpU
bzogSUVURi1QS0lYQExJU1RTLlRBTkRFTS5DT01fYXRfSU5URVJORVQgYXQgWDQwMFBPDQpi
Y2M6IEtFVklOIFNIQVZFUg0KU3ViamVjdDogUmU6IFtJRVRGLVBLSVhdIE9DU1AgQ3VycmVu
dCBTdGF0dXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0NCg==

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogcGF1bGhAaW1jLm9yZ19hdF9JTlRFUk5F
VCBhdCBYNDAwUE8NCg0K

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov

>>I vote for striking it and saying all responses SHOULD be signed. Further,
>you
>>should add something saying that a client SHOULD check if the response is
>>signed and if it's not, to check a policy for whether or not it should
>trust
>>unsigned responses
>
>But aren't these statements inconsistent?  Noting reliance on a local
>security policy configuration to enforce non-use of unsigned responses
>strongly suggests that OCSP clients implement the capability to do so.  I
>agree that noting the security risks of unsigned responses can make our
>intent more clear.

I don't think they're inconsistent. The first sentence says, in a backward
way,
some valid responses might not be signed. Thus, the second sentence says, in
essence, "because there are two kinds of responses (signed and unsigned), a
client should have a policy for each". Obviously, the policy for signed
responses is to accept them, but the second sentence stresses that there
should
be a policy for unsigned responses. Different wording to the same end would
be
fine with me.

>>>Regarding the notion of an element in the query to specify signed vs.
>>>unsigned responses, I would put it the other way around: the client
SHOULD
>>>be capable of handling either.
>>
>>Nope, I disagree. I think it is fine to create a client that always
rejects
>>unsigned responses.
>
>I would distinguish between a client which is technically incapable of
>handling unsigned responses from one that has a configurable capability to
>not to do so.

Yup.

>  I agree the former is compliant to an interpretation of
>SHOULD.  However, my model here is to compare this capability to an SMIME
UA
>that can only handle signed mail.

We had this argument last year in the S/MIME WG, and it wasn't resolved. My
take on this level of argument is "a client that refuses to do XYZ has a
policy
that says 'don't do XYZ'." If the protocol says "clients {SHOULD|MAY} do
XYZ",
clients that refuse to do XYZ still conform because they have a policy that
says "XYZ is always wrong in this environment".

>>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
>problem
>>with getting two independant interoperable implementations, then you have
>to
>>move to ASN.1. There's already been questions about the extensibility of
>the
>>ABNF.
>
>
>I must disagree.  I have seem more interoperability problems with ASN.1
than
>things such as ABNF, particularly if the problem wasn't an ASN.1-class
>problem in the first place.

Please note that your response ignored mine. This working group has the
option
of deciding whether or not a specification has any chance of getting two
independant interoperable implementations. If it decides that the way you've
specified your protocol will make that hard, the working group can demand
that
your protocol be changed, even if the bits on the wire don't change. Further,

if this working group decides that your ABNF works for OCSP 1 but is
non-extensible, the working group can reject it for that reason alone. I'm
not
advocating this, since I happen to like ABNF more than ASN.1, but it is up
to
the working group, not the draft editor.

>I agree that the list is our most productive tool for closure. That said,
>small focussed groups can and do help improve the pace of the standards
>process. The S/MIME group's efforts are good example.

Good example. The proprietary S/MIME v2 standard moved forward based on
small,
closed group meetings. It took forever to stabalize. The last closed
meeting of
that group (where you and I shared pizza) ended up muddying the waters with
respect to S/MIME v2's certificate handling.

Since S/MIME v3 has come into the IETF, essentially all of the movement has
been made based on the mailing list. Very little new came from the
Washington
DC meeting, and the small ad hoc meeting that happened in San Francisco in
January did help move a few things, but in fact those things have been
mostly
changed since being discussed openly on the mailing list.

I still urge you not to delay OCSP by waiting for the LA meeting. You have
lots
of input for the current draft. A new draft will help get even more input
and
move towards closure (modulo the Entrust submarine patent, of course).

--Paul Hoffman, Director
--Internet Mail Consortium

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_897.34f5b347.im70987d.hqrtmta1.doe.gov--

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Thu, 26 Feb 1998 09:35:27 -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] OCSP Current Status
To: [email-masked]
Status:

>>I vote for striking it and saying all responses SHOULD be signed. Further,
>you
>>should add something saying that a client SHOULD check if the response is
>>signed and if it's not, to check a policy for whether or not it should
>trust
>>unsigned responses
>
>But aren't these statements inconsistent?  Noting reliance on a local
>security policy configuration to enforce non-use of unsigned responses
>strongly suggests that OCSP clients implement the capability to do so.  I
>agree that noting the security risks of unsigned responses can make our
>intent more clear.

I don't think they're inconsistent. The first sentence says, in a backward
way,
some valid responses might not be signed. Thus, the second sentence says, in
essence, "because there are two kinds of responses (signed and unsigned), a
client should have a policy for each". Obviously, the policy for signed
responses is to accept them, but the second sentence stresses that there
should
be a policy for unsigned responses. Different wording to the same end would be
fine with me.

>>>Regarding the notion of an element in the query to specify signed vs.
>>>unsigned responses, I would put it the other way around: the client SHOULD
>>>be capable of handling either.
>>
>>Nope, I disagree. I think it is fine to create a client that always rejects
>>unsigned responses.
>
>I would distinguish between a client which is technically incapable of
>handling unsigned responses from one that has a configurable capability to
>not to do so.

Yup.

>  I agree the former is compliant to an interpretation of
>SHOULD.  However, my model here is to compare this capability to an SMIME UA
>that can only handle signed mail.

We had this argument last year in the S/MIME WG, and it wasn't resolved. My
take on this level of argument is "a client that refuses to do XYZ has a
policy
that says 'don't do XYZ'." If the protocol says "clients {SHOULD|MAY} do XYZ",
clients that refuse to do XYZ still conform because they have a policy that
says "XYZ is always wrong in this environment".

>>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
>problem
>>with getting two independant interoperable implementations, then you have
>to
>>move to ASN.1. There's already been questions about the extensibility of
>the
>>ABNF.
>
>
>I must disagree.  I have seem more interoperability problems with ASN.1 than
>things such as ABNF, particularly if the problem wasn't an ASN.1-class
>problem in the first place.

Please note that your response ignored mine. This working group has the option
of deciding whether or not a specification has any chance of getting two
independant interoperable implementations. If it decides that the way you've
specified your protocol will make that hard, the working group can demand that
your protocol be changed, even if the bits on the wire don't change. Further,
if this working group decides that your ABNF works for OCSP 1 but is
non-extensible, the working group can reject it for that reason alone. I'm not
advocating this, since I happen to like ABNF more than ASN.1, but it is up to
the working group, not the draft editor.

>I agree that the list is our most productive tool for closure. That said,
>small focussed groups can and do help improve the pace of the standards
>process. The S/MIME group's efforts are good example.

Good example. The proprietary S/MIME v2 standard moved forward based on small,
closed group meetings. It took forever to stabalize. The last closed
meeting of
that group (where you and I shared pizza) ended up muddying the waters with
respect to S/MIME v2's certificate handling.

Since S/MIME v3 has come into the IETF, essentially all of the movement has
been made based on the mailing list. Very little new came from the Washington
DC meeting, and the small ad hoc meeting that happened in San Francisco in
January did help move a few things, but in fact those things have been mostly
changed since being discussed openly on the mailing list.

I still urge you not to delay OCSP by waiting for the LA meeting. You have
lots
of input for the current draft. A new draft will help get even more input and
move towards closure (modulo the Entrust submarine patent, of course).

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By: [email-masked]
Date:         Thu, 26 Feb 1998 09:26: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-crmf-00.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           : Certificate Request Message Format
        Author(s)       : D. Solo, C. Adams, D. Kemp, M. Myers
        Filename        : draft-ietf-pkix-crmf-00.txt
        Pages           : 18
        Date            : 25-Feb-98

This document describes the Certificate Request Message Format (CRMF).
This syntax is used to convey a request for a certificate to a
Certification Authority (CA) (possibly via a Registration Authority
(RA)) for the purposes of X.509 certificate production.  The request
will typically include a public key and associated registration
information.

The key words ''MUST'', ''REQUIRED'', ''SHOULD'', ''RECOMMENDED'',
and ''MAY'' in this document (in uppercase, as shown)
are to be interpreted as described in RFC 2119.

Please send comments on this document to the [email-masked]
mail list.

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-crmf-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-crmf-00.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-crmf-00.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 2 (EuSn/CSOm) (0001EC20)
Content-Type: Message/External-body;
        name="draft-ietf-pkix-crmf-00.txt";
        site="ftp.ietf.org";
        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-crmf-00.txt (AURL/Arch) (0001EC21)
Content-Type: text/plain
Content-ID:     <[email-masked]>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 26 Feb 1998 09:50: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

>From: Michael Myers <[email-masked]>
>
> >From: Paul Hoffman / IMC <[email-masked]>
> >
> > True, but I think that this argument argues even more strongly for the
> > removal
> > of marketing words like "efficiently and rapidly" and "timely" from the
> > spec.
>
> We probably have a wordsmithing problem if that's the case since we need to
> state the existence of the timeliness requirement.  OCSP owes its existence
> to this requirement.  My point being that this draft is not a design spec
> intending to constrain implementors so as to ensure they develop products
> that will deliver timely service.

There certainly is a timeliness requirement.  OCSP has been proposed
and advertised as a solution that can satisfy that requirement,
whereas others have expressed skepticism backed up by preliminary
analysis indicating that OCSP alone is not a scalable solution, and
that CRLs fetched in online queries would present far less computational
and communication burden on a large CA than would OCSP.

The wordsmithed text must either describe where in a system
architecture OCSP is suited for use and where it is less well suited,
or it must confine itself to technical interoperability
specifications only and make no advertising claims about timeliness.

Entrust has proposed a timely revocation solution based on CRLs using
the patented crlDistributionPoint method.  I believe that an equally
efficient and more dynamically adjustable solution can be
constructed using online queries for non-patented delta-CRLs over a
monolithic subscriber base.  Both of these methods may use OCSP
for the final end-user to local-status-server link, but OCSP is
useless without a method for efficiently distributing timely
status information away from the CA.

Approved-By:  Michael Myers <[email-masked]>
Date:         Wed, 25 Feb 1998 18:24: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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Paul,

-----Original Message-----
From: Paul Hoffman / IMC <[email-masked]>

>At 08:59 PM 2/23/98 -0700, Michael Myers wrote:
>>OCSP is an interface specification; it exists to ensure interoperability
>>between two endpoints.  The quality of service delivered by those
endpoints
>>is more a matter of system engineering.
>
>True, but I think that this argument argues even more strongly for the
removal
>of marketing words like "efficiently and rapidly" and "timely" from the
spec.

We probably have a wordsmithing problem if that's the case since we need to
state the existence of the timeliness requirement.  OCSP owes its existence
to this requirement.  My point being that this draft is not a design spec
intending to constrain implementors so as to ensure they develop products
that will deliver timely service.

>
>>Provision for unsigned responses was in response to an observation that
>>within an enterprise, one may already be operating with a secure enclave
and
>>so have little need of the overhead of signature production.  If you and
>>others agree that this provision is unwise, I have no problem striking it
>>from the draft.
>
>I vote for striking it and saying all responses SHOULD be signed. Further,
you
>should add something saying that a client SHOULD check if the response is
>signed and if it's not, to check a policy for whether or not it should
trust
>unsigned responses

But aren't these statements inconsistent?  Noting reliance on a local
security policy configuration to enforce non-use of unsigned responses
strongly suggests that OCSP clients implement the capability to do so.  I
agree that noting the security risks of unsigned responses can make our
intent more clear.

>
>>Regarding the notion of an element in the query to specify signed vs.
>>unsigned responses, I would put it the other way around: the client SHOULD
>>be capable of handling either.
>
>Nope, I disagree. I think it is fine to create a client that always rejects
>unsigned responses.

I would distinguish between a client which is technically incapable of
handling unsigned responses from one that has a configurable capability to
not to do so.  I agree the former is compliant to an interpretation of
SHOULD.  However, my model here is to compare this capability to an SMIME UA
that can only handle signed mail.

>
>>>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>>>would seem more appropriate, and general purpose.
>>
>>In short, yes. This topic was discussed and closed at D.C.  It enables
ease
>>of implementation.
>
>If this group thinks that chosing ABNF instead of ASN.1 will lead to a
problem
>with getting two independant interoperable implementations, then you have
to
>move to ASN.1. There's already been questions about the extensibility of
the
>ABNF.

I must disagree.  I have seem more interoperability problems with ASN.1 than
things such as ABNF, particularly if the problem wasn't an ASN.1-class
problem in the first place.

>
>On a separate note, I do not think this discussion should wait until the LA
>meeting. That's more than a month away. Put out another draft and keep
>discussing it here. The IETF is designed to do most of its work on mailing
>lists (even ones with no working archives, as this one is), and use the
>face-to-face meetings for finalizing work and correcting misguided drafts.
>Unless you are lablelling this draft as misguided already, there is no need
to
>postpone the discussion on this list.

I agree that the list is our most productive tool for closure. That said,
small focussed groups can and do help improve the pace of the standards
process. The S/MIME group's efforts are good example.

>
>
>--Paul Hoffman, Director
>--Internet Mail Consortium
>

Approved-By:  Robert Zuccherato <[email-masked]>
Date:         Wed, 25 Feb 1998 16:48: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

We are in the process of producing the next version of this draft.  It
should be available by the end of this week, and certainly before the
submission deadline in a couple of weeks.

        Robert.

>----------
>From:  Rich Ankney[SMTP:[email-masked]]
>Sent:  Wednesday, February 25, 1998 10:18 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
>
>So what's the status of the notary protocol?  I'm inclined to use
>that, rather than OCSP, for any important (high-value) apps.
>
>Regards,
>Rich
>
>----------
>> From: Robert Zuccherato <[email-masked]>
>> To: [email-masked]
>> Subject: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
>> Date: Wednesday, February 25, 1998 9:09 AM
>>
>> I submitted this message to the list yesterday, but I haven't seen it
>> show up yet.  My apologies to anyone who receives it twice.
>>
>[snip]
>

Approved-By:  Rich Ankney <[email-masked]>
Date:         Wed, 25 Feb 1998 10:18: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: Rich Ankney <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

So what's the status of the notary protocol?  I'm inclined to use
that, rather than OCSP, for any important (high-value) apps.

Regards,
Rich

----------
> From: Robert Zuccherato <[email-masked]>
> To: [email-masked]
> Subject: [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
> Date: Wednesday, February 25, 1998 9:09 AM
>
> I submitted this message to the list yesterday, but I haven't seen it
> show up yet.  My apologies to anyone who receives it twice.
>
[snip]

Approved-By: [email-masked]
Date:         Wed, 25 Feb 1998 09:09: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: Robert Zuccherato <[email-masked]>
Subject:      [IETF-PKIX] FW: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

I submitted this message to the list yesterday, but I haven't seen it
show up yet.  My apologies to anyone who receives it twice.

>----------
>From:  Robert Zuccherato
>Sent:  Tuesday, February 24, 1998 11:46 AM
>To:    'IETF X.509-based public key infrastructure mailing list'
>Cc:    [email-masked]'
>Subject:       RE: [IETF-PKIX] OCSP Current Status
>
>Mike;
>
>----------
>From:  Michael Myers[SMTP:[email-masked]]
>Sent:  Monday, February 23, 1998 10:59 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] OCSP Current Status
>
>You raise a number of very good points which I hope to resolve at the LA
>IETF.   These are my views.  In the interests of expediency, I suggest  we
>convene an ad-hoc subgroup at LA to deal with these issues and deliver to
>PKIX our joint resolution.
>
>I think that there are more than just a few people who are interested in this
>draft.  Meeting in the back room of a smokey bar doesn't allow for full,
>public discussion of these ideas.  Why don't we try and resolve these issues
>on the list.
>
>-----Original Message-----
>From: Robert Zuccherato <[email-masked]>
>To: 'IETF X.509-based public key infrastructure mailing list'
>
>>1) You continue to maintain that OCSP gives "timely" status information
>>and does so "efficiently and rapidly".  I guess this statement depends
>>on what your definition of "timely" is.  It seems to me however, that
>>there is a tradeoff.  In order to get current status information, the
>>responder must produce only fresh responses and sign each one.  This
>>does not seem to be efficient and rapid, and certainly isn't scalable.
>>In order to be scalable, the responder must use pre-produced responses
>>and chaching.  This doesn't provide timely status information (at least
>>no more than using a CRL).  I think the document should make this choice
>>clear.  Many people still believe that OCSP can give them both current
>>status information and scalability.
>
>OCSP is an interface specification; it exists to ensure interoperability
>between two endpoints.  The quality of service delivered by those endpoints
>is more a matter of system engineering.   By analogy, consider that some
>Internet throughput needs are met by a 28K modem while other environments
>need, say, an OC3-size pipe.  In either case, TCP/IP flows across the wire
>to accomplish the interface.
>
>Presently, the draft talks about "timely" status information, being able to
>"efficiently and rapidly determine status information", using caching and
>response pre-production, using a nonce, etc.  It doesn't mention that using a
>nonce to produce timely status information does not allow efficient and rapid
>status information to be provided to a large number of people.  It doesn't
>mention that using caching and response pre-production doesn't allow timely
>status information.  These are not only system engineering problems, they are
>security issues.  This service has been advertised as providing up-to-date
>revocation status, but it cannot do so under all circumstances.  This should
>be made clear to all those using the service.
>
>>2) The draft still has no explanation of how one is to get the
>>verification key for the OCSP responder.  The document should clearly
>>explain that there are (at least) two options.  You can have the key
>>installed, but then you cannot revoke it.  If you run into trouble with
>>the responder's key, it is the same as losing the CA's key, you have to
>>start over.  Or, you can issue the OCSP responder a certificate and
>>revocation is possible by placing the certificate on an ARL.
>
>Here again I would assign this scope to a systems-level key management
>document. The diversity of options at this layer of the architecture
>strongly suggests there can be no one standard way of managing an OCSP
>responder's key(s).   Further, there's no reason that OCSP should operate in
>isolation of CRLs.  Again, I would leave this up to the PKI systems
>engineers to choose the configuration that best meets their local security
>policy needs.  Bearing in mind that the primary intent of revocation in this
>case would be to inhibit further use of a private key, one very effective
>way of revoking a responder's key is to take away its PCMCIA token, assuming
>that particulary key management decision was made by the system architect.
>
>I agree that there doesn't have to be one standard way to manage an OCSP
>responder's key(s).  Implementer's must be made aware, however, that if you
>choose one option, revocation is not possible, and if you choose another
>option, revocation is possible, but you must place the responder's key on an
>ARL.  This is a basic security requirement for an OCSP responder and should
>be discussed in the document, regardless of some future systems-level key
>management document.
>
>>3) The server still responds with VALID and INVALID, but certificates
>>are only valid with respect to a specific certification path and
>>explicitly stated policy.  There is a policy extension, but there is no
>>way to pass in a certification path for which validity is to be
>>determined.  Also, it appears to me that the responder doesn't have to
>>pay attention to the policy extension.  The service as presently
>>designed, really indicates whether or not a certificate is revoked, and
>>the responses should reflect this.
>
>May I ask that you provide a link-by-link example of how such chains would
>work in practice, starting with the public key needed to validate the
>signature on the subject certificate?  By "link" I mean "x-signs-y".
>
>Surely I don't have to explain how to do certificate path validation.  In
>order to validate a certificate, both a certificate path and a policy OID are
>required.  Policy mappings will not allow this to be done one certificate at
>a time.  If you do not want to allow both a certificate chain and policy OID
>in the request, then the best you can do is to determine the revocation
>status of the certificate.  If you want to determine certificate validity,
>then you must give the responder both the certificate chain and policy.
>
>>4) Unsigned error messages are still allowed.  This, of course, allows
>>anyone to produce responses to an OCSP request.  The statement is made
>>"It is reasonable to ask for error messages to be signed to address this
>>vulnerability."  I do not see how to ask for only signed responses in
>>the request however.
>
>Provision for unsigned responses was in response to an observation that
>within an enterprise, one may already be operating with a secure enclave and
>so have little need of the overhead of signature production.  If you and
>others agree that this provision is unwise, I have no problem striking it
>from the draft.  I do fear however that such a practice would evolve anyway,
>so we should also keep in mind  the utility of maintaining the provision as
>a means of achieving some level of interoperability.
>
>Again, since this is a security issue, the fact that unsigned messages should
>only be used within a secure enclave should be explicitly mentioned in the
>draft.  Otherwise, signed error messages must be used.
>
>Regarding the notion of an element in the query to specify signed vs.
>unsigned responses, I would put it the other way around: the client SHOULD
>be capable of handling either.  I doubt that an organization operating a
>responder that produces signed responses (ostensibly for the purposes of
>non-repudiation) would be willing upon request to produce any other type.
>Similarly, an organization that choses for reasons of expediency to not
>sign responses would most likely not be well positioned to selectively
>produce signed responses.
>
>Presently, the draft allows a server to produce all signed, all unsigned, or
>any combination of signed/unsigned error responses.  Your comment in the
>third paragraph of Section 5 seems to indicate that signed messages can be
>requested by the client.  Unless we specify exactly when signed/unsigned
>responses can be used (for example in a secure enclave, as discussed above),
>we should provide the mechanism that you allude to.  We should allow clients
>to request a signed error message in situations where it is not clear what
>they will get back, and they want to be sure someone isn't just sending back
>the unsigned response.
>
>>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>>would seem more appropriate, and general purpose.
>
>In short, yes. This topic was discussed and closed at D.C.  It enables ease
>of implementation.
>
>See other messages on the list, posted by others, on this topic.
>
>       Robert.
>
>
>

Approved-By: [email-masked]
Date:         Tue, 24 Feb 1998 14:39:15 -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: "/S=cc:Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/" </S=cc#c#Mail-Gateway/O=HQ/P=USDOE/A=ATTMAIL/C=US/@HQ.DOE.GOV>
Subject:      [IETF-PKIX] Message Undeliverable to cc:Mail
To: [email-masked]
Status:

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="non_del"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="non_del"

KioqIGNjOk1haWwgcmVwb3J0ZWQgdGhlIGZvbGxvd2luZyBlcnJvcnMgKioqDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBSZXR1cm5lZCANCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNP
TV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCkRhdGU6IDIvMjQvMTk5OCAxOjUwOjQ4UE0NClRv
OiBJRVRGLVBLSVhATElTVFMuVEFOREVNLkNPTV9hdF9JTlRFUk5FVCBhdCBYNDAwUE8NCmJj
YzogS0VWSU4gU0hBVkVSDQpTdWJqZWN0OiBbSUVURi1QS0lYXSBBQkEgSVNDIE1lZXRpbmcs
IEFwcmlsDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tDQo=

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="Authorized by..."
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Authorized by..."

TWVzc2FnZSBhdXRob3JpemVkIGJ5Og0KICAgIDogd2ZvcmRAdmVyaXNpZ24uY29tX2F0X0lO
VEVSTkVUIGF0IFg0MDBQTw0KDQo=

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov

For information...

>INFORMATION SECURITY COMMITTEE MEETING NOTICE
>
>5-7 April, 1998 - Patent & Trademark Office (PTO), Crystal City
>  (Wash., D.C. metro area)
>
>                                       Please correspond with:
>                                               Michael S. Baum, Esq.
>                                               One Alewife Center, Suite
350
>                                               Cambridge, MA 02140 USA
>                                               V: +1 617.661.1234
>                                               F: +1 617.661.0716
>                                               N: [email-masked]
>
>
>Dear Committee Member and Prospective Members:
>
>You are cordially invited to participate in a meeting of the Information
>Security Committee, Section of Science & Technology, American Bar
>Association, on Sunday-Tuesday, April 5-7, 1998, at the PTO in Crystal
>City (a quick cab ride from National Airport). The Committee will
>continue its advancement of public key infrastructure legal and control
>issues, and will include further work on CA accreditation, commercial
>key recovery guidelines, PKI evidentiary issues, certificate policy,
>and user liability, among other matters.
>
>Consistent with Section policy, ISC meeting participants must be members
>of both the ABA and the ABA Section of Science and Technology. Please
>contact Ann Kowalsky, Manager Section of Science & Technology, at ABA
>headquarters in Chicago by phone: +1 (312) 988.5599, fax: +1 (312)
>988.5628, or email: [email-masked] for membership information.
>You can become a paid member of the ABA and the ISC at the April 5-7
>meeting -- and associate ABA membership is available for non-lawyers.
>
>Meeting details appear below. I look forward to seeing you at the PTO.
>
>Sincerely,
>
>Michael S. Baum
>Chair, Information Security Committee
>Section of Science & Technology, ABA
>
>
>
>------------------------------------------------------------------------
>
>INFORMATION SECURITY COMMITTEE
>Section of Science & Technology, ABA
>5-7 April 1998
>
>Proposed Agenda (in extended sessions, breaks will be taken as needed.)
>
>
>5 April 1998 - Sunday (casual attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters (note: all times
>are "local")
>0900 - 0930 Introductions, meeting logistics, general announcements
>0930 - 1030 Working Group updates
>1030 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Dave W. Fillingham, NSA, Office of Network
>Security Infrastructure
>
>1300 - 1700 WG breakouts
>1700 - ????  Watering hole discussions; possible continuation of WG
meetings
>
>6 April 1998 - Monday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Commissioner of the PTO (tentative)
>1300 - 1700 WG breakouts
>1700 -  ???? Watering hole discussions; possible continuation of WG
meetings
>
>7 April 1998 - Wednesday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Representative from the OMB (tentative)
>1300 - 1500 WG wrap-ups
>1500 - 1600 WG presentations
>1600 - 1630 Path Forward, close
>
>Additional proposed agenda items and speakers should be emailed to
>Michael Baum ([email-masked]).
>
>
>------------------------------------------------------------------------
>
>
>Information Security Committee - PTO/Crystal City
>Electronic Commerce Division, Section of Science and Technology
>
>MEETING DETAILS - Work Groups
>5-7 April 1998
>
>
>Members are urged to participate in at least one of the Working Groups
>that will be presenting/meeting during the ISC's meeting. Please contact
>Ruven Schwartz, committee vice chair, or a working group co-chair
>directly, for further information.
>
>**Accreditation Working Group
>Contacts: Bill Burr ([email-masked])
>Charlie Merrill, Esq. ([email-masked])
>Lynn McNulty ([email-masked])
>
>The Accreditation Work Group (About 50 technologists and attorneys in
>three sections: Process, Technical Standards, and Legal and Business
>Standards) will continue work on its draft document, "Guidelines for
>Certificate Policies and Accreditation Criteria", with a view toward
>distributing a draft on the Internet for industry comments shortly
thereafter.
>
>
>**Certificate Services Agreements Working Group
>Contacts: Kevin O'Neill ([email-masked])
>Stephen Wu ([email-masked])
>
>The Certification Services Agreements Work Group is charged with writing
>"Certification Services Agreements," which is an outgrowth of the ISC's
>accreditation and cert. policies activity. The purpose of "Certification
>Services Agreements" is to assist the authors of a certificate policy
>definition, certification practice statement, subscriber agreement,
>relying party agreement, or other agreement relating to certification
>services by providing model forms and a menu of alternative legal
>wording for use in particular clauses of such documents. The document
>will include comments and annotations to the Guidelines for Certificate
>Policies and Accreditation Criteria. The group will review the current
>draft of the document and discuss plans for further development.
>
>
>**Comparative Law Working Group
>Contacts: Serge Parisien, Esq. ([email-masked])
>Suzanne Thibodeau ([email-masked])
>
>The Comparative Law work group will continue its exploration of the
>requirements for PKI in civil law and other legal jurisdictions. It will
>also continue efforts to harmonize legal infrastructure with the common
>law.
>
>
>**Digital Signatures Laws & Regulations Working Group
>Contacts: Kenneth Allen, Esq. ([email-masked])
>David Danner, Esq. ([email-masked])
>Dan Greenwood, Esq. ([email-masked])
>
>The Legislative and Regulatory Working Group will hold its periodic
>conference call, to discuss updates to legislation and regulation
>regarding electronic authentication. The Leg./Reg. Working Group
>will continue/finalize its study of a need for model regulations to
>support the electronic and digital signature legislative laws enacted in
>several states to date.
>
>
>**Evidentiary Working Group
>Contacts: Gary Fresen, Esq. ([email-masked])
>Serge Parisien, Esq. ([email-masked])
>
>The Evidentiary Work Group will continue its drafting of the judicial
>tutorial (a tutorial for judges to admit technology into evidence) and
>report on its coordination activities with record management standards
>authorities. The working group members will also assist the other
>working groups on their evidentiary issues.
>
>
>**Global Trade Working Group
>Contacts: Joseph Alhadeff, Esq. ([email-masked])
>Lisa Kinard ([email-masked])
>Linda Macintosh ([email-masked])
>
>The Global Trade Work Group identifies and collaborates with trade
>groups whose work influences secure global trade and reports critical
>issues back to the ISC. The WG is developing an overall framework to
>structure and analyze secure trade issues; and is preparing an issues
>statement concerning cooperation between legal, business and
>technological professionals to reduce secure electronic international
>trade barriers.
>
>
>**Key Recovery Working Group (KRWG)
>Contacts: Emily Frye, Esq. ([email-masked])
>Dwight Olson, Esq. ([email-masked])
>Randy Sabett, Esq. ([email-masked])
>
>The KRWG monitors proposed legislation and regulations, both here
>and abroad, that address key recovery, and offers comments where
>appropriate. The KRWG's major initiative documents the
>framework and operation of a key recovery center. Work is in the
>advanced outline stage and will focus on fleshing out draft text.
>
>
>**Liability Working Group
>Contacts: Maureen Adamache, Esq. ([email-masked])
>Elise Reed, Esq. ([email-masked])
>
>The Liability Work Group will continue its work with the Accreditation
>Group on the liability issues, including preparing liability policy
>statements and also suitable clauses for inclusion in PKI/CA-user and
>PKI/CA cross-certification agreements. It will also continue its
>analyses of the liability of application software providers, and for
>other (non-digital signature, non-confidentiality encryption)
>applications of public key cryptography. Finally, it will consider
>technical methods of solving the legal problem of binding relying
>parties.
>
>
>
>------------------------------------------------------------------------
>
>LOGISTICS
>
>Recommended attire: Sunday - casual; Monday/Tuesday - business attire.
>
>First-time participants planning to attend the April 5-7 meeting: Please
>contact Ruven Schwartz, ISC ViceChair, at 612-687-8095 or
>[email-masked] to coordinate meeting work-product
contributions.
>
>Meeting Location:  Patent & Trademark Office, Crystal Park Building 1,
>Suite 601
>(2011 Crystal Drive, Crystal City, Virginia).  Note: this is NOT where we
>last met at the PTO.
>
>Meals: TBD
>
>Lodging: tbd
>
>RSVP: Please confirm your intention to participate to Ann Kowalsky,
>Section Manager, Section of Science and Technology
>([email-masked]) as soon as possible.
>
>See you at the PTO.
>
>
>                                           ***
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov
Content-Type: application/octet-stream; name="err_msg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="err_msg"

PFVua25vd24gYm9keSBwYXJ0IGZyb20gY2M6TWFpbCBkaXNjYXJkZWQ+DQo=

------ =_0_MIME_Boundary_28283.34f322d3.im92956j.hqrtmta1.doe.gov--

Approved-By:  Warwick Ford <[email-masked]>
Date:         Tue, 24 Feb 1998 14:04:24 -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] ABA ISC Meeting, April
To: [email-masked]
Status:

For information...

>INFORMATION SECURITY COMMITTEE MEETING NOTICE
>
>5-7 April, 1998 - Patent & Trademark Office (PTO), Crystal City
>  (Wash., D.C. metro area)
>
>                                       Please correspond with:
>                                               Michael S. Baum, Esq.
>                                               One Alewife Center, Suite 350
>                                               Cambridge, MA 02140 USA
>                                               V: +1 617.661.1234
>                                               F: +1 617.661.0716
>                                               N: [email-masked]
>
>
>Dear Committee Member and Prospective Members:
>
>You are cordially invited to participate in a meeting of the Information
>Security Committee, Section of Science & Technology, American Bar
>Association, on Sunday-Tuesday, April 5-7, 1998, at the PTO in Crystal
>City (a quick cab ride from National Airport). The Committee will
>continue its advancement of public key infrastructure legal and control
>issues, and will include further work on CA accreditation, commercial
>key recovery guidelines, PKI evidentiary issues, certificate policy,
>and user liability, among other matters.
>
>Consistent with Section policy, ISC meeting participants must be members
>of both the ABA and the ABA Section of Science and Technology. Please
>contact Ann Kowalsky, Manager Section of Science & Technology, at ABA
>headquarters in Chicago by phone: +1 (312) 988.5599, fax: +1 (312)
>988.5628, or email: [email-masked] for membership information.
>You can become a paid member of the ABA and the ISC at the April 5-7
>meeting -- and associate ABA membership is available for non-lawyers.
>
>Meeting details appear below. I look forward to seeing you at the PTO.
>
>Sincerely,
>
>Michael S. Baum
>Chair, Information Security Committee
>Section of Science & Technology, ABA
>
>
>
>------------------------------------------------------------------------
>
>INFORMATION SECURITY COMMITTEE
>Section of Science & Technology, ABA
>5-7 April 1998
>
>Proposed Agenda (in extended sessions, breaks will be taken as needed.)
>
>
>5 April 1998 - Sunday (casual attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters (note: all times
>are "local")
>0900 - 0930 Introductions, meeting logistics, general announcements
>0930 - 1030 Working Group updates
>1030 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Dave W. Fillingham, NSA, Office of Network
>Security Infrastructure
>
>1300 - 1700 WG breakouts
>1700 - ????  Watering hole discussions; possible continuation of WG meetings
>
>6 April 1998 - Monday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Commissioner of the PTO (tentative)
>1300 - 1700 WG breakouts
>1700 -  ???? Watering hole discussions; possible continuation of WG meetings
>
>7 April 1998 - Wednesday (business attire recommended)
>0830 - 0900 Greetings, coffee, administrative matters
>0900 - 0930 Updates -- logistics, administrative, WG related, etc.
>0930 - 1200 WG breakouts
>1200 - 1300 Lunch speaker: Representative from the OMB (tentative)
>1300 - 1500 WG wrap-ups
>1500 - 1600 WG presentations
>1600 - 1630 Path Forward, close
>
>Additional proposed agenda items and speakers should be emailed to
>Michael Baum ([email-masked]).
>
>
>------------------------------------------------------------------------
>
>
>Information Security Committee - PTO/Crystal City
>Electronic Commerce Division, Section of Science and Technology
>
>MEETING DETAILS - Work Groups
>5-7 April 1998
>
>
>Members are urged to participate in at least one of the Working Groups
>that will be presenting/meeting during the ISC's meeting. Please contact
>Ruven Schwartz, committee vice chair, or a working group co-chair
>directly, for further information.
>
>**Accreditation Working Group
>Contacts: Bill Burr ([email-masked])
>Charlie Merrill, Esq. ([email-masked])
>Lynn McNulty ([email-masked])
>
>The Accreditation Work Group (About 50 technologists and attorneys in
>three sections: Process, Technical Standards, and Legal and Business
>Standards) will continue work on its draft document, "Guidelines for
>Certificate Policies and Accreditation Criteria", with a view toward
>distributing a draft on the Internet for industry comments shortly
thereafter.
>
>
>**Certificate Services Agreements Working Group
>Contacts: Kevin O'Neill ([email-masked])
>Stephen Wu ([email-masked])
>
>The Certification Services Agreements Work Group is charged with writing
>"Certification Services Agreements," which is an outgrowth of the ISC's
>accreditation and cert. policies activity. The purpose of "Certification
>Services Agreements" is to assist the authors of a certificate policy
>definition, certification practice statement, subscriber agreement,
>relying party agreement, or other agreement relating to certification
>services by providing model forms and a menu of alternative legal
>wording for use in particular clauses of such documents. The document
>will include comments and annotations to the Guidelines for Certificate
>Policies and Accreditation Criteria. The group will review the current
>draft of the document and discuss plans for further development.
>
>
>**Comparative Law Working Group
>Contacts: Serge Parisien, Esq. ([email-masked])
>Suzanne Thibodeau ([email-masked])
>
>The Comparative Law work group will continue its exploration of the
>requirements for PKI in civil law and other legal jurisdictions. It will
>also continue efforts to harmonize legal infrastructure with the common
>law.
>
>
>**Digital Signatures Laws & Regulations Working Group
>Contacts: Kenneth Allen, Esq. ([email-masked])
>David Danner, Esq. ([email-masked])
>Dan Greenwood, Esq. ([email-masked])
>
>The Legislative and Regulatory Working Group will hold its periodic
>conference call, to discuss updates to legislation and regulation
>regarding electronic authentication. The Leg./Reg. Working Group
>will continue/finalize its study of a need for model regulations to
>support the electronic and digital signature legislative laws enacted in
>several states to date.
>
>
>**Evidentiary Working Group
>Contacts: Gary Fresen, Esq. ([email-masked])
>Serge Parisien, Esq. ([email-masked])
>
>The Evidentiary Work Group will continue its drafting of the judicial
>tutorial (a tutorial for judges to admit technology into evidence) and
>report on its coordination activities with record management standards
>authorities. The working group members will also assist the other
>working groups on their evidentiary issues.
>
>
>**Global Trade Working Group
>Contacts: Joseph Alhadeff, Esq. ([email-masked])
>Lisa Kinard ([email-masked])
>Linda Macintosh ([email-masked])
>
>The Global Trade Work Group identifies and collaborates with trade
>groups whose work influences secure global trade and reports critical
>issues back to the ISC. The WG is developing an overall framework to
>structure and analyze secure trade issues; and is preparing an issues
>statement concerning cooperation between legal, business and
>technological professionals to reduce secure electronic international
>trade barriers.
>
>
>**Key Recovery Working Group (KRWG)
>Contacts: Emily Frye, Esq. ([email-masked])
>Dwight Olson, Esq. ([email-masked])
>Randy Sabett, Esq. ([email-masked])
>
>The KRWG monitors proposed legislation and regulations, both here
>and abroad, that address key recovery, and offers comments where
>appropriate. The KRWG's major initiative documents the
>framework and operation of a key recovery center. Work is in the
>advanced outline stage and will focus on fleshing out draft text.
>
>
>**Liability Working Group
>Contacts: Maureen Adamache, Esq. ([email-masked])
>Elise Reed, Esq. ([email-masked])
>
>The Liability Work Group will continue its work with the Accreditation
>Group on the liability issues, including preparing liability policy
>statements and also suitable clauses for inclusion in PKI/CA-user and
>PKI/CA cross-certification agreements. It will also continue its
>analyses of the liability of application software providers, and for
>other (non-digital signature, non-confidentiality encryption)
>applications of public key cryptography. Finally, it will consider
>technical methods of solving the legal problem of binding relying
>parties.
>
>
>
>------------------------------------------------------------------------
>
>LOGISTICS
>
>Recommended attire: Sunday - casual; Monday/Tuesday - business attire.
>
>First-time participants planning to attend the April 5-7 meeting: Please
>contact Ruven Schwartz, ISC ViceChair, at 612-687-8095 or
>[email-masked] to coordinate meeting work-product
contributions.
>
>Meeting Location:  Patent & Trademark Office, Crystal Park Building 1,
>Suite 601
>(2011 Crystal Drive, Crystal City, Virginia).  Note: this is NOT where we
>last met at the PTO.
>
>Meals: TBD
>
>Lodging: tbd
>
>RSVP: Please confirm your intention to participate to Ann Kowalsky,
>Section Manager, Section of Science and Technology
>([email-masked]) as soon as possible.
>
>See you at the PTO.
>
>
>                                           ***
>
>
---------------------------------------------------------------------
Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
---------------------------------------------------------------------

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 24 Feb 1998 09:34: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: Marc Branchaud <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Attachment converted: Lutefisk:Re- [IETF-PKIX] OCSP Current St (TEXT/MPGP) (0001EBF5)

Approved-By:  Paul Hoffman / IMC <[email-masked]>
Date:         Tue, 24 Feb 1998 09:33: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: Paul Hoffman / IMC <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

At 08:59 PM 2/23/98 -0700, Michael Myers wrote:
>OCSP is an interface specification; it exists to ensure interoperability
>between two endpoints.  The quality of service delivered by those endpoints
>is more a matter of system engineering.

True, but I think that this argument argues even more strongly for the removal
of marketing words like "efficiently and rapidly" and "timely" from the spec.

>Provision for unsigned responses was in response to an observation that
>within an enterprise, one may already be operating with a secure enclave and
>so have little need of the overhead of signature production.  If you and
>others agree that this provision is unwise, I have no problem striking it
>from the draft.

I vote for striking it and saying all responses SHOULD be signed. Further, you
should add something saying that a client SHOULD check if the response is
signed and if it's not, to check a policy for whether or not it should trust
unsigned responses.

>Regarding the notion of an element in the query to specify signed vs.
>unsigned responses, I would put it the other way around: the client SHOULD
>be capable of handling either.

Nope, I disagree. I think it is fine to create a client that always rejects
unsigned responses.

>>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>>would seem more appropriate, and general purpose.
>
>In short, yes. This topic was discussed and closed at D.C.  It enables ease
>of implementation.

If this group thinks that chosing ABNF instead of ASN.1 will lead to a problem
with getting two independant interoperable implementations, then you have to
move to ASN.1. There's already been questions about the extensibility of the
ABNF.

On a separate note, I do not think this discussion should wait until the LA
meeting. That's more than a month away. Put out another draft and keep
discussing it here. The IETF is designed to do most of its work on mailing
lists (even ones with no working archives, as this one is), and use the
face-to-face meetings for finalizing work and correcting misguided drafts.
Unless you are lablelling this draft as misguided already, there is no need to
postpone the discussion on this list.

--Paul Hoffman, Director
--Internet Mail Consortium

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 24 Feb 1998 09:43:00 -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] OCSP comments
Comments: To: [email-masked]
To: [email-masked]
Status:

Mike,

I heartily endorse Ambarish's arguments, and would vote for ASN.1. I have
already talked about the need for one extension (to handle
confirmation of the certificate status for a particular digital signature,
and to allow for an insurance mechanisms as well), and I strongly
suspect that there will be others. ASN.1 has clearly demonstrated the ability
to handle extensions in the form of new attributes, to handle support for
multi-byte alphabets for supporting internationalization, etc. Although other
competing metalanguages might offer the same things (but always "more or less"),
I don't want to have to go through the intellectual effort of walking
through the entire spec to convince myself that that is true.

>From my perspective as an architect, I would strongly prefer one uniform
way of handling all of the functionality involved in PKI, and that clearly should
be ASN.1 driven.  I'll be happy to leave the "light-weight" protocols to the SPKI folks,
and/or to the LDAP proponents, for I believe that experience has shown that
when they get through, the protocol is no longer light weight, but it isn't
easily extensible either.

We have a considerable investment in ASN.1 tools, compiler, etc.,
as I assume almost anyone who is serious in this business does. The last
thing I want to do is have to do is either write or buy yet another toolkit,
probably with incompatible interfaces, another entire library of functions
necessary to support it, etc.. It just causes enormous code bloat, adds that
much more to the pile that has to be documented, maintained, etc. And converting
certificate elements back and forth from ASN.1 to any other format just
means more code that has to be written, more latency, and lots more chances for
errors and ambiguities to creep in. For high performance applications such as firewalls
and virtual private networks, where all of the code has to be resident in RAM
in order to be instantly available, this additional functionality on top of the ASN.1
that is already required translates into real dollars and cents hardware costs.

I don't want to draw a line in the sand and say that if OCSP isn't written in ASN.1
we won't support it, but it would be a considerable factor in our decision -- that
and some of the other things it doesn't yet do.

I also support Peter Sylvester's argument that OCSP should be divorced from http.
It shouldn't matter what the underlying protocol is -- I can imagine DAM, LDAP,
RPCs, and other potential transport layer mechanisms being used, for example.
On the other hand, if http is used, an ASN.1 request/response is no more difficult
to handle than say a MPEG-2 image.  It's just a bucket of bits.

Bob

>
>
>>>> Ambarish Malpani <[email-masked]> 02/23 7:54 PM >>>
>Hi Mike,
>    I am definintely not religious about ASN.1 and I know we have talked
>in the past about leaving ASN.1 out of OCSP, to allow it to stay a
>lightweight protocol. However, after reading the latest version of the
>OCSP spec and spending some time thinking about it, I really think we
>should use ASN.1 in OCSP. Here are the reasons:
>
>1. The syntax of both queries and responses in OCSP is getting quite
>complicated. Inventing a new way of describing this syntax is both more
>error prone (might introduce bugs/ambiguities in trying to describe the
>protocol - for examples, see below) and more difficult to implement (you
>need to write a new parser that now treats another set of characters (&,
>/, # etc) as separators.
>
>2. Adding extensions to this new description is going to be much more
>difficult - it is very likely that new extensions will break parsers
>written for older versions - a problem that has already been addressed
>for ASN.1 because people have done it many times before.
>
>3. There are multiple encoding steps, where things are first DER
>encoded, then base64 encoded, then URL encode. If the request needs to
>be signed, the signature is computed on this encoded data and *then*
>needs to be base64 and URL encoded -- a much more bug prone process.
>
>Here are some bugs/issues from an initial read of the spec:
>
>1. In the query, there is an extra '/'
>    i.e. a query will look like: http://<servername>//ocsp/ver/1...
>
>2. In responses, there is a bug in the specification of a cert id, where
>you send back the base64 encoding of the cert id in the response, even
>though the base64 encoding can contain a '/'. You would need to escape
>the forward slashes in the encoding to prevent parsers from mistaking it
>for a separator. (see Page 6 and 7)
>
>3. There are a bunch of %x22 kind of statements (is that a standard
>format that I don't know of)?
>
>4. In signed requests, where the whole cert is provided, is the cert
>included in the data to be signed?
>
>5. I am  assuming all signatures are computed *after* URL encoding of
>the previous part of the request and then base64 encoded and then URL
>encoded. Is this correct? Is the signature then DER/base64/URL encoded?
>
>
>Regards,
>Ambarish
>
>--
>---------------------------------------------------------------------
>Ambarish Malpani
>Architect                                              (650) 849-9880
>ValiCert, Inc.                                  [email-masked]
>3160 W. Bayshore Road                         http://www.valicert.com
>Palo Alto, CA 94303

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Products Group
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."

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Tue, 24 Feb 1998 11:50:42 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

A little nit-picking:

- There is a need for an 'pretty online' service to find out the
  status of certificates. One might consider to define this service
  without referencing to http, and then selecting http
  as 'use of lower layers'.
  In the actual text these things seems to be tied together.

- The mentioned keyword/value pairs might be given as such
  (using whatever textual means to describe it) but not in
  the rather implicit way through its encoding in an http request.

- The text should be written in ASCII or ISO-latin-1 (not with
  quotes coming from some well known word-processing-$ware.)

- In the description of a request, there is a definition of
  'time' which is not used anywhere?

Peter Sylvester -- EdelWeb France

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Feb 1998 20:59: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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
Comments: To: Robert Zuccherato <[email-masked]>
To: [email-masked]
Status:

Rob,

You raise a number of very good points which I hope to resolve at the LA
IETF.   These are my views.  In the interests of expediency, I suggest  we
convene an ad-hoc subgroup at LA to deal with these issues and deliver to
PKIX our joint resolution.

Mike

-----Original Message-----
From: Robert Zuccherato <[email-masked]>
To: 'IETF X.509-based public key infrastructure mailing list'

>Mike;
>
>I have read through your latest OCSP draft and unfortunately I still
>have some problems with it.
>
>1) You continue to maintain that OCSP gives "timely" status information
>and does so "efficiently and rapidly".  I guess this statement depends
>on what your definition of "timely" is.  It seems to me however, that
>there is a tradeoff.  In order to get current status information, the
>responder must produce only fresh responses and sign each one.  This
>does not seem to be efficient and rapid, and certainly isn't scalable.
>In order to be scalable, the responder must use pre-produced responses
>and chaching.  This doesn't provide timely status information (at least
>no more than using a CRL).  I think the document should make this choice
>clear.  Many people still believe that OCSP can give them both current
>status information and scalability.

OCSP is an interface specification; it exists to ensure interoperability
between two endpoints.  The quality of service delivered by those endpoints
is more a matter of system engineering.   By analogy, consider that some
Internet throughput needs are met by a 28K modem while other environments
need, say, an OC3-size pipe.  In either case, TCP/IP flows across the wire
to accomplish the interface.

>
>2) The draft still has no explanation of how one is to get the
>verification key for the OCSP responder.  The document should clearly
>explain that there are (at least) two options.  You can have the key
>installed, but then you cannot revoke it.  If you run into trouble with
>the responder's key, it is the same as losing the CA's key, you have to
>start over.  Or, you can issue the OCSP responder a certificate and
>revocation is possible by placing the certificate on an ARL.

Here again I would assign this scope to a systems-level key management
document. The diversity of options at this layer of the architecture
strongly suggests there can be no one standard way of managing an OCSP
responder's key(s).   Further, there's no reason that OCSP should operate in
isolation of CRLs.  Again, I would leave this up to the PKI systems
engineers to choose the configuration that best meets their local security
policy needs.  Bearing in mind that the primary intent of revocation in this
case would be to inhibit further use of a private key, one very effective
way of revoking a responder's key is to take away its PCMCIA token, assuming
that particulary key management decision was made by the system architect.

>
>3) The server still responds with VALID and INVALID, but certificates
>are only valid with respect to a specific certification path and
>explicitly stated policy.  There is a policy extension, but there is no
>way to pass in a certification path for which validity is to be
>determined.  Also, it appears to me that the responder doesn't have to
>pay attention to the policy extension.  The service as presently
>designed, really indicates whether or not a certificate is revoked, and
>the responses should reflect this.

May I ask that you provide a link-by-link example of how such chains would
work in practice, starting with the public key needed to validate the
signature on the subject certificate?  By "link" I mean "x-signs-y".

>4) Unsigned error messages are still allowed.  This, of course, allows
>anyone to produce responses to an OCSP request.  The statement is made
>"It is reasonable to ask for error messages to be signed to address this
>vulnerability."  I do not see how to ask for only signed responses in
>the request however.

Provision for unsigned responses was in response to an observation that
within an enterprise, one may already be operating with a secure enclave and
so have little need of the overhead of signature production.  If you and
others agree that this provision is unwise, I have no problem striking it
from the draft.  I do fear however that such a practice would evolve anyway,
so we should also keep in mind  the utility of maintaining the provision as
a means of achieving some level of interoperability.

Regarding the notion of an element in the query to specify signed vs.
unsigned responses, I would put it the other way around: the client SHOULD
be capable of handling either.  I doubt that an organization operating a
responder that produces signed responses (ostensibly for the purposes of
non-repudiation) would be willing upon request to produce any other type.
Similarly, an organization that choses for reasons of expediency to not
sign responses would most likely not be well positioned to selectively
produce signed responses.

>
>5) In the request the cert-id is a SHA-1 hash of the Issuer DN and cert
>serial number, in the response it is an MD5 hash.  Could we be
>consistent?

Yes, the MD5 in the response should have been a SHA-1 specification.

>
>6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
>would seem more appropriate, and general purpose.

In short, yes. This topic was discussed and closed at D.C.  It enables ease
of implementation.

>
>Regards,
>
> Robert Zuccherato.
>

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 23 Feb 1998 20:31:02 -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: Michael Myers <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Dave,

It it very likely the case that an OCSP query would not be translated into
ASN.1 at the server.  Rather, I would expect a more direct translation to,
say, SQL or some other database interface.

Mike

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, February 23, 1998 1:54 PM
Subject: Re: [IETF-PKIX] OCSP Current Status

> . . . .
>Admittedly, OCSP itself isn't so complex as to absolutely require
>ASN.1.  But applications are already capable of using ASN.1 to break
>out the contents of a certificate, otherwise they wouldn't need OCSP at
>all.  Translating certificate fields from ASN.1 to EBNF in OCSP
>clients, and then translating again at the server to compare against
>ASN.1 CRLs sounds error prone and inflexible.  A more consistent
>approach would avoid the translation problem.  Isn't "unnecessary"
>internal consistency better than internal inconsistency?
>

Approved-By:  Ambarish Malpani <[email-masked]>
Date:         Mon, 23 Feb 1998 18:54: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: Ambarish Malpani <[email-masked]>
Organization: ValiCert, Inc.
Subject:      [IETF-PKIX] OCSP comments
To: [email-masked]
Status:

Hi Mike,
    I am definintely not religious about ASN.1 and I know we have talked
in the past about leaving ASN.1 out of OCSP, to allow it to stay a
lightweight protocol. However, after reading the latest version of the
OCSP spec and spending some time thinking about it, I really think we
should use ASN.1 in OCSP. Here are the reasons:

1. The syntax of both queries and responses in OCSP is getting quite
complicated. Inventing a new way of describing this syntax is both more
error prone (might introduce bugs/ambiguities in trying to describe the
protocol - for examples, see below) and more difficult to implement (you
need to write a new parser that now treats another set of characters (&,
/, # etc) as separators.

2. Adding extensions to this new description is going to be much more
difficult - it is very likely that new extensions will break parsers
written for older versions - a problem that has already been addressed
for ASN.1 because people have done it many times before.

3. There are multiple encoding steps, where things are first DER
encoded, then base64 encoded, then URL encode. If the request needs to
be signed, the signature is computed on this encoded data and *then*
needs to be base64 and URL encoded -- a much more bug prone process.

Here are some bugs/issues from an initial read of the spec:

1. In the query, there is an extra '/'
    i.e. a query will look like: http://<servername>//ocsp/ver/1...

2. In responses, there is a bug in the specification of a cert id, where
you send back the base64 encoding of the cert id in the response, even
though the base64 encoding can contain a '/'. You would need to escape
the forward slashes in the encoding to prevent parsers from mistaking it
for a separator. (see Page 6 and 7)

3. There are a bunch of %x22 kind of statements (is that a standard
format that I don't know of)?

4. In signed requests, where the whole cert is provided, is the cert
included in the data to be signed?

5. I am  assuming all signatures are computed *after* URL encoding of
the previous part of the request and then base64 encoded and then URL
encoded. Is this correct? Is the signature then DER/base64/URL encoded?

Regards,
Ambarish

--
---------------------------------------------------------------------
Ambarish Malpani
Architect                                              (650) 849-9880
ValiCert, Inc.                                  [email-masked]
3160 W. Bayshore Road                         http://www.valicert.com
Palo Alto, CA 94303

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 23 Feb 1998 17:59:30 -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] Defining Terms w.r.t. Cross Cert...
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Hi Denis,

>----------
>From:  Denis Pinkas[SMTP:[email-masked]]
>Sent:  Monday, February 23, 1998 7:50 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>> Allowing for WG members in different time zones, I propose to wait until
>> Wednesday for responses to the above definition.
>
>My time zone was quite different since I was in a different week zone
>(in the Alps, for a very good skying last week).  :-)

Unfortunately, your time zone was so different that you missed the
opportunity for responses (I ended up waiting until Friday instead of
Wednesday to submit the document in order to give as many people as
possible a chance to post their input).  However, thank you for your
comments; I have a couple of comments in return.

>> "cross-certification request":  One CA requests issuance of a
>> cross-certificate from another CA.
>
>    I think that "CA-Certificate request" and "Cross-certificate
>    request" should be defined instead. This is what we describe
>    in terms of the protocols.

I tend to think of "cross-certification" as the process of issuing a
cross-certificate (just as "certification" is the process of issuing a
certificate).  Therefore, I can't say that I see much/any difference
between "cross-certification request" and "cross-certificate request"
(with respect to this protocol).  If there is a distinction, it seems to
me that it argues in favour of "cross-certification request", since the
purpose of this message in CMP is to ask the other side to *issue* a
cross-certificate (whereas the semantics of the term "cross-certificate
request" can conceivably mean "please give me any cross-certificate that
you happen to have lying around").  In other words, the name
"cross-certificate request" does not necessarily imply issuance, which
seems like a shortcoming to me.

>> When it is necessary to distinguish more finely, the following terms
>> may be used: a cross-certificate is called an "inter-domain
>> cross-certificate" if the subject and issuer CAs belong to different
>> administrative domains; it is called an "intra-domain
>> cross-certificate" otherwise.
>
>    The term "cross-certificate" means that some boundary is
>    being crossed. Using the more general term, it is a domain
>    crossing. If you are in the same domain there is no crossing.

The difficulty is that not everyone views the term "cross" in the sense
of crossing a boundary.  It is legitimate to think of a
"cross-certificate" as an object existing "across" two CAs (irrespective
of administrative domains).

>    I would thus only see a cross-certificate being equivalent to
>    an "inter-domain certificate".

Note 2 in the definition was put there specifically to accommodate this
view and to ensure that it is an acceptable view within the scope of
PKIX while not ruling out the possibility that other views may exist.
This seems to me to be the fairest way to come to agreement on a term
that means quite different things to different people (and sometimes to
the same people at different points in time :-).

The problem is that this definition (a fairly minor part of the CMP
spec.) has been holding up the document for some time.  PKIX needs to
get some RFCs issued (last time I looked we still didn't have any!).  I
tried to find a compromise that I felt would satisfy the largest number
of people on this list (in order to reach "rough consensus"),
recognizing that it is impossible to satisfy everyone.  I think that
Warwick's modification to the text I posted meets this criterion.
[Don't forget, by the way, that the WG is only trying to achieve a
Proposed Standard here; there's lots of time to re-visit this definition
if we ever want to progress to Draft Standard or Internet Standard.  I
don't see much benefit in continuing to hold up the PKIX documents (CMP
and the Profiles spec.) over this issue...]

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

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Mon, 23 Feb 1998 16:12:19 -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] OCSP Current Status
To: [email-masked]
Status:

Just a small plea:

Could we PLEASE avoid an ASN.1 flame war?

        Phill

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Feb 1998 16:20: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Todd,
  I agree with everything you say, but can't you please say it
in normal ASCII text?

I believe the consensus is that IETF mail lists should be text-only;
not everyone uses MIME.

Regards,
  dpk

Approved-By: [email-masked]
Date:         Mon, 23 Feb 1998 12:18: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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Rich Salz wrote:

> >I also support this ASN.1 Notation. ASN.1 is virtually the standard everywhere,
> >lets stick with it to keep the interoperability of our various standards an
> >easier thing to accomplish.
>
> Those who want OCSP recast as an ASN.1/DER protocol are missing one of
> its key points.  OCSP is an "http application" and designed to provide
> a low-cost way for the http-speaking world to find out the status of
> a certificate.

No Rich, I understand this very clearly - Its always been an issue with me that we
don't need to manage the overhead or possible liability of the interoperability of
three bazillion different certificate access/management methods and especially the
standards for certificate validation and revocation.

> OCSP is basically "hitching a ride" on top of the
> ubiquity and reachability of port 80; defining some new binary protocol
> and getting a new reserved port assigned would raise all sorts of practical
> deployment barriers for the sake of unnecessary internal consistency.
>         /r$

While I agree that the intent behind the OCSP effort is valuable I wonder if it
introduces yet another worm to the bigger issue of Certificate and CRL management.
Personally I disagree with your opinion that this is "unnecessary internal
consistency". I think that the consistancey is the key for building an
interoperability framework and that is the only way Business is going to adopt our
technologies for their use models. Futher that we are fighting an uphill political
battle with respect to the three bazillion different standards,  until we come to
grips with this concept.

--
Todd's Latest Rant --
---------------------
"UCC, Commercial Law and numerous international Treaties are the
basis of the 'transaction requirements'. Technologies must adapt
to support them without making them conform to the technologies..."

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 2 (TEXT/R*ch) (0001EBE2)
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 2 (????/----) (0001EBE3)

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 23 Feb 1998 15:32:44 -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] OCSP Current Status
To: [email-masked]
Status:

> From: Rich Salz <[email-masked]>
>
> Those who want OCSP recast as an ASN.1/DER protocol are missing one of
> its key points.  OCSP is an "http application" and designed to provide
> a low-cost way for the http-speaking world to find out the status of
> a certificate.   OCSP is basically "hitching a ride" on top of the
> ubiquity and reachability of port 80; defining some new binary protocol
> and getting a new reserved port assigned would raise all sorts of practical
> deployment barriers for the sake of unnecessary internal consistency.
>         /r$

Defining OCSP using ASN.1 may raise the practical deployment barrier
of not fitting the "http mindset"; some people are not familiar with
it, are not fluent in reading it, or do not have the libraries in place
to process it.

But claiming that it is "some new binary protocol" requiring a port
other than 80 to be assigned is not a credible objection. Why do
you believe ASN.1/DER data is any less http-compatible than .jpg data?

The real deployment barrier is getting C, java, perl, tcl, and python
modules that can parse ASN.1 structures as easily as comma-separated
lists of name=value pairs. Those modules only have to be written once
by toolkit suppliers; the majority of application programmers just
use what's provided in their favorite libraries or scripting engines.

ASN.1 is desirable not just for the sake of internal consistency, but
as a foundation suitable for building more capable applications
more easily.  Programming is easier in a compiled language than
in machine language, even though it is reasonably difficult to write
a compiler.  Cryptography is easier with a bignum library than without.
Similarly, ASN.1 tools will ultimately enable the development of
more capable http applications than is practical with current
techniques.

Admittedly, OCSP itself isn't so complex as to absolutely require
ASN.1.  But applications are already capable of using ASN.1 to break
out the contents of a certificate, otherwise they wouldn't need OCSP at
all.  Translating certificate fields from ASN.1 to EBNF in OCSP
clients, and then translating again at the server to compare against
ASN.1 CRLs sounds error prone and inflexible.  A more consistent
approach would avoid the translation problem.  Isn't "unnecessary"
internal consistency better than internal inconsistency?

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Mon, 23 Feb 1998 11:04:01 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
Comments: To: [email-masked]
To: [email-masked]
Status:

At 04:50 PM 2/23/98 -0800, Denis Pinkas wrote, in part:

>    The term "cross-certificate" means that some boundary is
>    being crossed. Using the more general term, it is a domain
>    crossing. If you are in the same domain there is no crossing.
>    I would thus only see a cross-certificate being equivalent to
>    an "inter-domain certificate".
>
>I would then attempt to explain the difference between a
>"Cross-certificate request" and a "CA-Certificate request".
>
>A "Cross-Certificate request" is done by an already established CA
>wishing to be certified by an already established CA from a different
>(administrative) domain.
>
>A "CA-Certificate request" is done either by a new CA wishing to be
>established by CA from the same (administrative) domain or by an already
>established CA, wishing, to be certified by an already established CA
>from a different (administrative) domain.

I can see why the term "cross-certificate" is problematic;)

With due respect, you say that "cross" implies a domain crossing, and yet
your second example allows "CA-Certificate request" to cross domains.  Is
this a "cut-and-paste" error?

Two additional questions/points:

By what (universal) means are the parties, especially in different
"administrative domains," to detemine that one or the other is an
"already established CA?"  This is the first time, I believe, that
this has been offered as a distinguishing characteristic.

I note that in both examples given, the requesting party is asking to
be certified in a subordinating role.  That is, (speaking naively) they
ask that the keys they certify be accepted (validate) further up the
chain, making them acceptable to users (relying parties) in the requestee's
domain.  Earlier, there was talk in the other direction, wherein I want
the users in my domain to accept certificates rooted in another domain,
and I effect this by unilaterally countersigning the root key of this
foreign domain.

The central point of all of this, I thought, was to allow the elements
of any such chain to be gathered automatically, in any case.

Thanks.  ___TONY___

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Rich Salz <[email-masked]>
Date:         Mon, 23 Feb 1998 13:57:17 -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: Rich Salz <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

>I also support this ASN.1 Notation. ASN.1 is virtually the standard everywhere,
>lets stick with it to keep the interoperability of our various standards an
>easier thing to accomplish.

Those who want OCSP recast as an ASN.1/DER protocol are missing one of
its key points.  OCSP is an "http application" and designed to provide
a low-cost way for the http-speaking world to find out the status of
a certificate.   OCSP is basically "hitching a ride" on top of the
ubiquity and reachability of port 80; defining some new binary protocol
and getting a new reserved port assigned would raise all sorts of practical
deployment barriers for the sake of unnecessary internal consistency.
        /r$

Approved-By: [email-masked]
Date:         Mon, 23 Feb 1998 09:57: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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

<html><HTML>
&nbsp;Robert Zuccherato wrote:
<BLOCKQUOTE TYPE=CITE>Mike;

<P>I have read through your latest OCSP draft and unfortunately I still
<BR>have some problems with it.

<P>1) You continue to maintain that OCSP gives "timely" status information
<BR>and does so "efficiently and rapidly".&nbsp; I guess this statement
depends
<BR>on what your definition of "timely" is.&nbsp; It seems to me however,
that
<BR>there is a tradeoff.&nbsp; In order to get current status information,
the
<BR>responder must produce only fresh responses and sign each one.&nbsp;
This
<BR>does not seem to be efficient and rapid, and certainly isn't scalable.
<BR>In order to be scalable, the responder must use pre-produced responses
<BR>and chaching.&nbsp; This doesn't provide timely status information
(at least
<BR>no more than using a CRL).&nbsp; I think the document should make this
choice
<BR>clear.&nbsp; Many people still believe that OCSP can give them both
current
<BR>status information and scalability.</BLOCKQUOTE>
Robert's right as far as I can tell. OCSP suffers from the time distortion
issue and as such needs to have some framework for formalizing the revocation
window or period...
<BLOCKQUOTE TYPE=CITE>&nbsp;

<P>2) The draft still has no explanation of how one is to get the
<BR>verification key for the OCSP responder.&nbsp; The document should
clearly
<BR>explain that there are (at least) two options.</BLOCKQUOTE>

<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>
You can have the key installed, but then you cannot revoke it.&nbsp; If
you run into trouble with the responder's key, it is the same as losing
the CA's key, you have to start over.</LI>
</UL>
</BLOCKQUOTE>
In this case you might want to create a "pending state" as well so that
certificate transactions can be escrow based until such time as they are
actually validated. This might unburden some of the cycle-based pain of
restarting the whole transaction from scratch.
<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>
Or, you can issue the OCSP responder a certificate and revocation is possible
by placing the certificate on an ARL.</LI>
</UL>
3) The server still responds with VALID and INVALID, but certificates
<BR>are only valid with respect to a specific certification path and
<BR>explicitly stated policy.&nbsp; There is a policy extension, but there
is no
<BR>way to pass in a certification path for which validity is to be
<BR>determined.&nbsp; Also, it appears to me that the responder doesn't
have to
<BR>pay attention to the policy extension.&nbsp; The service as presently
<BR>designed, really indicates whether or not a certificate is revoked,
and
<BR>the responses should reflect this.

<P>4) Unsigned error messages are still allowed.&nbsp; This, of course,
allows
<BR>anyone to produce responses to an OCSP request.&nbsp; The statement
is made
<BR>"It is reasonable to ask for error messages to be signed to address
this
<BR>vulnerability."&nbsp; I do not see how to ask for only signed responses
in
<BR>the request however.

<P>5) In the request the cert-id is a SHA-1 hash of the Issuer DN and cert
<BR>serial number, in the response it is an MD5 hash.&nbsp; Could we be
<BR>consistent?

<P>6) Do we really have to do this using ABNF grammar and HTTP?&nbsp; ASN.1
<BR>would seem more appropriate, and general purpose.</BLOCKQUOTE>
I also support this ASN.1 Notation. ASN.1 is virtually the standard everywhere,
lets stick with it to keep the interoperability of our various standards
an easier thing to accomplish.&nbsp;

<P>Todd
<BR>&nbsp;</HTML>

</html>Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 1 (TEXT/R*ch) (0001EBD5)
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 1 (????/----) (0001EBD6)

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 23 Feb 1998 16:50:20 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

> Allowing for WG members in different time zones, I propose to wait until
> Wednesday for responses to the above definition.

My time zone was quite different since I was in a different week zone
(in the Alps, for a very good skying last week).  :-)

As many, I appreciate the efforts to converge but I would like that we
focuss on the text changes that we need. Some of the proposals and
wordings are going beyond what is necessary.

I would appreciate that we discuss text changes in their context. There
are very few places where the term cross-certificate or
cross-certification are used. Could we see the old text and a revised
text, before making a new full BIG draft available ?

Re-using the text from Warwick, I will now make a few technical
comments, that go in a different direction:

> "cross-certification request":  One CA requests issuance of a
> cross-certificate from another CA.

    I think that "CA-Certificate request" and "Cross-certificate
    request" should be defined instead. This is what we describe
    in terms of the protocols.

> For the purposes of this standard, the following terms are defined.
> A "cross-certificate" is a certificate in which the subject CA and
> the issuer CA are distinct and SubjectPublicKeyInfo contains a
> verification key (i.e., the certificate has been issued for the
> subject CA's signing key pair).

    The above definition should apply to a CA-Certificate instead.

> When it is necessary to distinguish more finely, the following terms
> may be used: a cross-certificate is called an "inter-domain
> cross-certificate" if the subject and issuer CAs belong to different
> administrative domains; it is called an "intra-domain
> cross-certificate" otherwise.

    The term "cross-certificate" means that some boundary is
    being crossed. Using the more general term, it is a domain
    crossing. If you are in the same domain there is no crossing.
    I would thus only see a cross-certificate being equivalent to
    an "inter-domain certificate".

I would then attempt to explain the difference between a
"Cross-certificate request" and a "CA-Certificate request".

A "Cross-Certificate request" is done by an already established CA
wishing to be certified by an already established CA from a different
(administrative) domain.

A "CA-Certificate request" is done either by a new CA wishing to be
established by CA from the same (administrative) domain or by an already
established CA, wishing, to be certified by an already established CA
from a different (administrative) domain.

The protocol is the same. I hope this may help and not add more
confusion. :-)

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Jakob Bjerre Jensen <[email-masked]>
Date:         Mon, 23 Feb 1998 14:20:39 +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] protocolEncKey
To: [email-masked]
Status:

In relation to the draft 'Certificate Management Protocols'.

I have a question about the component 'protocolEncKey' present various
places, e.g. in InitReqContent

InitReqContent ::= SEQUENCE {
      protocolEncKey      [0] SubjectPublicKeyInfo  OPTIONAL,
      fullCertTemplates       FullCertTemplates
  }

Can someone tell me, where (i.e. in which applications) and why this
component is present?

The actual draft 'Certificate Mangement Protocols' explains in details
the various intended use of
 structures in a PKIX (e.g. a PKI message consists of header, body,
optional protection etc.,
 the body is intended for message-specific inofmation, the header is
intended for ..., very good!).
But when reading the document, it happens that one cannot see the use of
a specific component
(e.g. the component 'protocolEncKey' above).

Is there any further readings available?

- Jakob

Approved-By: [email-masked]
Date:         Fri, 20 Feb 1998 15:10: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: Robert Zuccherato <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
Comments: cc: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Mike;

I have read through your latest OCSP draft and unfortunately I still
have some problems with it.

1) You continue to maintain that OCSP gives "timely" status information
and does so "efficiently and rapidly".  I guess this statement depends
on what your definition of "timely" is.  It seems to me however, that
there is a tradeoff.  In order to get current status information, the
responder must produce only fresh responses and sign each one.  This
does not seem to be efficient and rapid, and certainly isn't scalable.
In order to be scalable, the responder must use pre-produced responses
and chaching.  This doesn't provide timely status information (at least
no more than using a CRL).  I think the document should make this choice
clear.  Many people still believe that OCSP can give them both current
status information and scalability.

2) The draft still has no explanation of how one is to get the
verification key for the OCSP responder.  The document should clearly
explain that there are (at least) two options.  You can have the key
installed, but then you cannot revoke it.  If you run into trouble with
the responder's key, it is the same as losing the CA's key, you have to
start over.  Or, you can issue the OCSP responder a certificate and
revocation is possible by placing the certificate on an ARL.

3) The server still responds with VALID and INVALID, but certificates
are only valid with respect to a specific certification path and
explicitly stated policy.  There is a policy extension, but there is no
way to pass in a certification path for which validity is to be
determined.  Also, it appears to me that the responder doesn't have to
pay attention to the policy extension.  The service as presently
designed, really indicates whether or not a certificate is revoked, and
the responses should reflect this.

4) Unsigned error messages are still allowed.  This, of course, allows
anyone to produce responses to an OCSP request.  The statement is made
"It is reasonable to ask for error messages to be signed to address this
vulnerability."  I do not see how to ask for only signed responses in
the request however.

5) In the request the cert-id is a SHA-1 hash of the Issuer DN and cert
serial number, in the response it is an MD5 hash.  Could we be
consistent?

6) Do we really have to do this using ABNF grammar and HTTP?  ASN.1
would seem more appropriate, and general purpose.

Regards,

        Robert Zuccherato.

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Thu, 19 Feb 1998 09:52: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Comment on ESS and Privacy Marks
To: [email-masked]
Status:

For those who haven't been following the following discussion on the
S/MIME list, the "[0] IMPLICIT UTF8String" syntax would have similar
advantages wherever UTF8String is used in the next versions of
the Cert Profile and CMP.

> To: [email-masked]
> From: [email-masked] (John Pawling)
>
> All,
>
> I agree with Bancroft Scott that ESSPrivacyMark should be re-defined as follows:
>
> > ESSPrivacyMark ::= CHOICE {
> >    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
> >    utf8String   [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
> > }
>
>
> Note Bancroft's point as follows:
>
> >Another
> >benefit is that if someone is using a tool that does not support
> >UTF8String they can simply change it to "[0] OCTET STRING" and get the
> >same encoding.

Approved-By:  "Phillip M. Hallam-Baker" <[email-masked]>
Date:         Wed, 18 Feb 1998 13:31: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: "Phillip M. Hallam-Baker" <[email-masked]>
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

> A status protocol should
>thus support "hash of the certificate DER encoding" to allow the access
>to revocation information only to entities that are having the
>certificate in question available. Neither issuer and serial (anyone can
>construct such a hash) nor sending the complete certificate (breaching
>privacy laws) are acceptable.
>
>Any ideas on this? While the hash could be included in the extensions, I
>feel that it is not a proper place to do so. I would rather like to see
>this as yet another method for certificate identification.

I would prefer to take the approach of defining a generic URI to
refer to _any_ concrete data structure by the hash of its content.

A concrete data structure in this case would be an actual stream
of bits. Variant documents such as HTML documents generated on
the fly to support multiple clients would not count.

The digest would need armouring in some fashion, despite the
additional characters I believe that Base16 is preferable to Base64
singe the former can be read over a telephone line. It would be
prudent to allow use of more than one digest method and so the
protocol tag needs to be followed by an algorithm tag.

How about

digest:algorithm/value
digest:SHA1/81A72C368E126DD38EE61FF27F8A6

There is currently a URI working group but I can't recomend it
as a venue at the moment. Better to propose a label that is
usefull and sensible and if it proves to be valuable propose it
as a general standard.

Those who actually do understand URIs such as Dave Raggett
and Tim B-L have proposed similar schemes in the past.

    Phill

Approved-By: [email-masked]
Date:         Wed, 18 Feb 1998 11:46: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: Andreas Berger <[email-masked]>
Organization: GMD Darmstadt TKT.SIT
Subject:      Re: [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

Michael Myers wrote:
>
> All,
>
> You should be hearing from IETF soon of an update to the OCSP draft.  It
> takes into account comments in D.C. regarding extensibility, both in the
> request and in the response.  Several other tweaks have been made, such as a
> more formal BNF specification of request and response syntax.  Many thanks
> to Rich Ankey of Certco for his contributions to this draft.
>
> Interested parties should review the draft for responsiveness to
> requirements and technical completeness in anticipation of a formal Last
> Call going in to L.A.
>
> Mike
The German Digital Signature Law needs an OCSP-like service (provided by
a trusted directory service) that allows clients to ask for the validity
status of certificates. This status can be inquired at any point in time
about any previous point in time, like "what was the status of the
certificate at 10:13 on 1/13/97". The additional information -- the time
-- can easily added in the OCSP extension field.

What is missing to support this feature is an additonal method of
identifying a certificate. OCSP uses either a hash over the DN an serial
number or the complete certificate. Since certificates contain privacy
relevant data, persons can choose not to publish the certificate at all
(only providing it with any message they send). A status protocol should
thus support "hash of the certificate DER encoding" to allow the access
to revocation information only to entities that are having the
certificate in question available. Neither issuer and serial (anyone can
construct such a hash) nor sending the complete certificate (breaching
privacy laws) are acceptable.

Any ideas on this? While the hash could be included in the extensions, I
feel that it is not a proper place to do so. I would rather like to see
this as yet another method for certificate identification.

Andreas
--
Wissen haelt nicht laenger als Fisch.
  -- Alfred North Whitehead, Logiker und Philosoph 1861-1947
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 (????/----) (0001EB7F)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 17 Feb 1998 18:32:22 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Bill,

>----------
>From:  Bill Burr[SMTP:[email-masked]]
>Sent:  Tuesday, February 17, 1998 3:28 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>The problem I have is that what you claim "people think of as a
>cross-certificate" is not at all, not even a little bit, what I think of as
>a cross-certificate.  I think a cross-certificate is a cross-certificate
>pair.   No more and no less.  And X.509 (June 1997 version) never uses
>"cross-certificate" except as a part of cross-certificate pair (unless
>there is some mysterious new amendment I've never seen that changes
>everything, and at this point I don't care about further amendments to
>X.509),

I suppose it depends on how you read the spec.  To me, X.509 defines
cross-certificate by implication, in that a "cross-certificate pair" is
a pair of cross-certificates (so that what goes in the "forward"
parameter is a cross-certificate and what goes in the "reverse"
parameter is another cross-certificate).  Read your way,
"cross-certificate pair" is a single item, not a pair of items (in this
case, what goes in the "forward" and "reverse" parameters are presumably
CA-certificates).

It is exactly this kind of ambiguity in X.509 that has led to all the
confusion over terminology in this area.  My preference is for PKIX to
define the terms clearly and unambiguously (at least for its own
purposes; i.e., within its own documents).  I don't see why trying to
align with the X.509 terminology is necessarily the optimum choice,
given that the ambiguous X.509 terminology is the problem we're trying
to solve...

Carlisle.

Approved-By:  Russ Housley <[email-masked]>
Date:         Tue, 17 Feb 1998 18:26: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: Russ Housley <[email-masked]>
Subject:      [IETF-PKIX] Nortel Patent and Authority Information Access
To: [email-masked]
Status:

All:

I just read the Nortel patent, and I am very concerned.  I am not a lawyer
(thank goodness), but my reading of the patent leads me to believe that it
covers more than CRL Distribution points.  Claim 1 is very broad.  In
particular, it seems to cover the use of the Authority Information Access
extension to point to a OCSP server.

I think that we need some lawyers to look at PKIX Part 1 and the Nortel
patent.  I would hope that companies with the appropriate legal resources
could have them take a look and post the findings.

Russ

Approved-By: [email-masked]
Date:         Tue, 17 Feb 1998 15:28:34 -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: Bill Burr <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

At 12:12 PM 2/16/98 -0500, you wrote:
>Hi All,
>
>I appreciate all the recent feedback on this topic; this is what a
>mailing list is all about!  Since, however, this seems to be the last
>remaining issue for PKIX-CMP, it would be great if we could wrap up this
>definition and get the draft submitted (CMP has been on hold for weeks
>now while we debated the definition of cross-certification, which is
>unfortunate, given that this is such a small part of the whole
>draft...).
>
>As far as I can tell, the following proposal is sensitive to all the
>e-mails (both public and private) that I've seen.
>
>"cross-certification:  Any process that results in the creation of a
>cross-certificate.  For the purposes of this standard, the following
>terms are defined.  A "CA-certificate" is any certificate in which both
>the subject and issuer are CAs.  A "cross-certificate" is a
>CA-certificate in which the subject CA and the issuer CA are distinct
>and  SubjectPublicKeyInfo contains a verification key (i.e., the
>certificate has been issued for the subject CA's signing key pair).
>When it is necessary to distinguish more finely, the following terms may
>be used:  a cross-certificate is called an "inter-domain
>cross-certificate" if the subject and issuer CAs belong to different
>administrative domains; it is called an "intra-domain cross-certificate"
>otherwise.  (Note:  in many environments the term "cross-certificate",
>unless further qualified, will be understood to be synonymous with
>"inter-domain cross-certificate" as defined above.).  Issuance of
>cross-certificates may be, but is not necessarily, mutual; that is, two
>CAs may issue cross-certificates for each other."
>
>
>Some comments.
>
>1) The first sentence addresses those who were concerned that the
>previous definition of cross-certification mandated a request from the
>subject CA and a response from the issuer CA.  This now makes it clear
>that the so-called "spontaneous" decision by the issuer still
>constitutes "cross-certification".
>
>2) The definition of "CA-certificate" aligns with that given in X.509.
>The definition of "cross-certificate" is slightly more restrictive in
>that a self-signed certificate is explicitly *not* a cross-certificate,
>but I believe this would correspond with everyone's understanding and
>use of the term today.
>
>3) The note at the end addresses those who feel that cross-certification
>applies only to CAs in different administrative domains.  This note
>makes it clear that such will be the common interpretation without
>completely closing the door to other possible interpretations.
>
>4) I recognize that some wanted to drop the term cross-certificate (or
>cross-certification) completely and move to something else (such as
>CA-certificate or one of the other candidates).  However, the following
>two reasons might be offered for keeping "cross-certificate" in these
>documents.
>
>- For better or worse, rightly or wrongly, the industry (including the
>media) has adopted the term "cross-certificate".  It is true that
>different people often mean different things when they use it.  However,
>it seems much more sensible to define the term than to, at this late
>stage, try to introduce a new term that no one is familiar with.  It's a
>bit like "certificate", or "signature", or a number of other terms; I'm
>not sure we have the luxury of choosing names for these concepts any
>more, but we *can* define what PKIX means when they are used in PKIX
>documents.
>
>- Again, for better or worse, rightly or wrongly, the X.500 Directory
>standard defines attributes called "ca-certificate" and
>"cross-certificate".  If PKIX takes what we all intuitively think of as
>a cross-certificate and calls it a CA-certificate, where would such a
>thing likely be put in the Directory (despite any warnings we might put
>in that the two terms are unrelated)?  If PKIX calls it some new name,
>where would it be put?  All this would really accomplish would be to
>complicate path-finding procedures unnecessarily.  I fail to see much
>value in taking what people think of as a cross-certificate, calling it
>a CA-certificate, and then encouraging Directory users to put it in the
>cross-certificate attribute rather than the ca-certificate attribute...

The problem I have is that what you claim "people think of as a
cross-certificate" is not at all, not even a little bit, what I think of as
a cross-certificate.  I think a cross-certificate is a cross-certificate
pair.   No more and no less.  And X.509 (June 1997 version) never uses
"cross-certificate" except as a part of cross-certificate pair (unless
there is some mysterious new amendment I've never seen that changes
everything, and at this point I don't care about further amendments to X.509),

Moreover, it seems to me that the meaning of the term "CA-certificate" is
pretty obvious, and the term defined in X.509 as: "A certificate for one CA
issued by another CA" and is used 19 times in X.509.  And to my reading,
where X.509 says "CA-certificate" or "CA certificate"  you would have PKIX
say "cross-certificate."  I have a really hard time with that.  I think
that it's confusing as hell.

I favor using cross-certificate as equivalent to cross-certificate pair,
and CA -certificate, as it us used in X.509, for any certificate, as
anything that is not an end-entity certificate.

This may cause problems with drafts of X.500 I've never seen.  It seems to
me that the thing to do is to make X.500 attributes align with X.509
terminology.

But to have PKIX use the term "cross-certificate" where X.509 apparently
always uses "CA-certificate" would be a spectacularly confusing choice.
Regards,

Bill Burr

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Tue, 17 Feb 1998 10:48: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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Charles,
We all agree that the information in the certificates drives the certificate
validation process.
What does not play any part in the process is any metadata that the
cross-certificate may or may not belong to a pair of entities within  an
administrative domain. I could have a set of CA within my domain that has
the same constraints as a CA external to my domain. If the policy within the
certificates is the same, they get treated  the same. I do not change what I
do because of where they are found, only by what I find in the certificates.

I would go further to say that by using separate directory attributes of
CAcertificate and cross-certificate, and user-certificate we are confusing
the picture. There is no information within the issuer or subject DN. that
would guarantee to tell you whether the subject and issuer belonged to the
same or different administrative domains. Placing a CA certificate in the
user-certificates attribute does not change the certificate type or what I
trust about the certificate. Should we not just have one attribute on a
directory object called simply "certificates".
Trevor
> -----Original Message-----
> From: Charles Moore [SMTP:[email-masked]]
> Sent: Monday, February 16, 1998 5:43 PM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>
> -----Original Message-----
> From: Trevor Freeman <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Tuesday, 17 February 1998 10:51
> Subject: Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>
> >Hi Carlisle,
> >When I am walking the chain, I do not know the nature of the superior CA
> >therefore if you logic is followed, I must be prepared to search the
> >Cross-certificates attribute, then the CA-certificate attribute resulting
> in
> >two directory hits in some instances as well as additional complexity of
> >code. Is it not simpler to  just search one attribute of an object with
> the
> >certainty of all certificate will be in that attribute, so it would make
> >sense to select the name of attribute would contains all CA certificates
> in
> >which case this would imply using the CA-certificate attribute.
>
> Certpath processing depends on the certificate policy, i.e the rules that
> must be followed.
>
> So if I start at the user certificate, I know it will be signed by a
> CAcertificate, I get this from the Ca Certificate attribute
> Now I look at the cert policy and know the rules to apply to the path
> processing. A policy may decied that only hiearchical ( i.e subordination
> rules will apply, in which case I would look in the CA attribute to find
> the
> path ( Xcerts would not apply even if they exist as this is against the
> policy ) .
>
> Now in other cases my policy may allow for Xcerts in which case I look for
> the cross certificate pair as my policy may require a bialateral
> arrangement
> i.e that there exists a forward and reverse certificates or just one way
>  it very difficult to do this with
> just a CAcertificate) as cross implies direction ( I will agree not
> impossible, but not something I would not willingly do when their are
> simpler ways).
>
> So I use the symantics and the syntax associated with cross certificate
> pairs to good use ( that why they exist).
> I may use CA CACertificate attribute to do certpath navigation, but not to
> find cross certs or cross cert pairs.
>
> What rules I follow are determined by the certificate policy, which is
> contained within each certificate.
>
> So in summary, I dont make arbitary decisions, I follow the certificate
> policy rules, and I use the available mechanims to help simplify the path
> processing.
>
> I have sent a couple of simple cross certificate defintions to the list
> with
> no one disagreeing, but still see this CACertificate line. My last thought
> was to just to not bother, as a) I realy dont need a on-line cross
> certificate request mechanism ( numerious peole have outlined why, but
> then
> if this is useful I dont disagree with the mechanism being available), b)
> the market will determine what policies will be acceptable and what
> solutions meet those policies. We will make use of available mechanisms to
> meet the different types of policy requirements.
>
> The one thing we have learned and it is also evident in this list is that
> there is no single right way, but some are easier than others.
>
> PKIX had an opportunity to assist with clarification of the above issues
>  value add ), but I just see a value subtract and increased confusion.
>
> The over loading of the terms CAcertificate ( and all the minor variations
> cACertificate etc)  and now cross certificate are not helpful to anyone,
> who
> wants to build and deploy  PKIs.
>
> We also need to be careful, 12mths ago people thought that self signed
> root
> certificates were the basis of any PKI; experience has shown this not to
> be
> so. Due to a number of issues cross certificates are seen to be the
> answer,
> experience will show that these mechamisms all have their place, but none
> alone are the universal answer to PKI deployment, scaleability or Trust
> issues.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >We only have two types of entity, CA and End entity. Can we not reflect
> this
> >in the directory by CA's using CA-Certificate attribute and end entities
> use
> >the user-certificates attribute?
> >Trevor

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 17 Feb 1998 09:48:19 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Carlisle,

  Your proposed text looks great!

Dave

P.S. I just found out that I will be in London during the LA IETF
meeting; I hope there are no open issues left to resolve by then
anyway :-).

Approved-By:  Phillip Hallam-Baker <[email-masked]>
Date:         Tue, 17 Feb 1998 10:10:46 -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] Defining Terms w.r.t. Cross Cert...
Comments: To: "Michael J. Aikins" <[email-masked]>
To: [email-masked]
Status:

Michael J. Aikins wrote:
>
> why is it Charlie that every time you send me an email message.........I get
> a note that the digital signature on the message is invalid. I do have a
> certificate for you in my address book but maybe you have changed or it has
> expired ???

The list manager software performs some message transformation that
modified
the content of the message. Regardless of whether a certificate is
trusted or
not any message sent in the 'readable' signature mode is unlikely to
verify.

                Phill

Approved-By:  "Michael J. Aikins" <[email-masked]>
Date:         Tue, 17 Feb 1998 14:53:41 +1100
Reply-To: "Michael J. Aikins" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: "Michael J. Aikins" <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

why is it Charlie that every time you send me an email message.........I get
a note that the digital signature on the message is invalid. I do have a
certificate for you in my address book but maybe you have changed or it has
expired ???

Boy Vienna is really cold.....

MikeA.

-----Original Message-----
From: Charles Moore <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 17 February 1998 13:27
Subject: Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...

>snip
>>
>>However, the point I was trying to make (in the discussion, if not the
>>text) is that PKIX should use the term "cross-certificate" rather than
>>"CA-certificate" in its documents precisely to try and diminish/remove
>>possible confusion (i.e., so that people would be more inclined to put
>>the result in the cross-certificate attribute than in the cACertificate
>>attribute).  The argument I was making (which I believe we're in violent
>>agreement on) is that it would not make sense for PKIX to call it a
>>"CA-certificate" and then encourage people *not* to put it in the
>>cACertificate attribute.  Life seems less error-prone if we simply call
>>it a cross-certificate and then encourage people to put it in the
>>cross-certificate attribute...
>
>You are right, I do agree with you.
>
>

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

Attachment converted: Lutefisk:smime.p7s 76 (????/----) (0001EAD8)

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 11:42:45 +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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

-----Original Message-----
From: Trevor Freeman <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 17 February 1998 10:51
Subject: Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...

>Hi Carlisle,
>When I am walking the chain, I do not know the nature of the superior CA
>therefore if you logic is followed, I must be prepared to search the
>Cross-certificates attribute, then the CA-certificate attribute resulting
in
>two directory hits in some instances as well as additional complexity of
>code. Is it not simpler to  just search one attribute of an object with the
>certainty of all certificate will be in that attribute, so it would make
>sense to select the name of attribute would contains all CA certificates in
>which case this would imply using the CA-certificate attribute.

Certpath processing depends on the certificate policy, i.e the rules that
must be followed.

So if I start at the user certificate, I know it will be signed by a
CAcertificate, I get this from the Ca Certificate attribute
Now I look at the cert policy and know the rules to apply to the path
processing. A policy may decied that only hiearchical ( i.e subordination
rules will apply, in which case I would look in the CA attribute to find the
path ( Xcerts would not apply even if they exist as this is against the
policy ) .

Now in other cases my policy may allow for Xcerts in which case I look for
the cross certificate pair as my policy may require a bialateral arrangement
i.e that there exists a forward and reverse certificates or just one way
 it very difficult to do this with
just a CAcertificate) as cross implies direction ( I will agree not
impossible, but not something I would not willingly do when their are
simpler ways).

So I use the symantics and the syntax associated with cross certificate
pairs to good use ( that why they exist).
I may use CA CACertificate attribute to do certpath navigation, but not to
find cross certs or cross cert pairs.

What rules I follow are determined by the certificate policy, which is
contained within each certificate.

So in summary, I dont make arbitary decisions, I follow the certificate
policy rules, and I use the available mechanims to help simplify the path
processing.

I have sent a couple of simple cross certificate defintions to the list with
no one disagreeing, but still see this CACertificate line. My last thought
was to just to not bother, as a) I realy dont need a on-line cross
certificate request mechanism ( numerious peole have outlined why, but then
if this is useful I dont disagree with the mechanism being available), b)
the market will determine what policies will be acceptable and what
solutions meet those policies. We will make use of available mechanisms to
meet the different types of policy requirements.

The one thing we have learned and it is also evident in this list is that
there is no single right way, but some are easier than others.

PKIX had an opportunity to assist with clarification of the above issues
 value add ), but I just see a value subtract and increased confusion.

The over loading of the terms CAcertificate ( and all the minor variations
cACertificate etc)  and now cross certificate are not helpful to anyone, who
wants to build and deploy  PKIs.

We also need to be careful, 12mths ago people thought that self signed root
certificates were the basis of any PKI; experience has shown this not to be
so. Due to a number of issues cross certificates are seen to be the answer,
experience will show that these mechamisms all have their place, but none
alone are the universal answer to PKI deployment, scaleability or Trust
issues.

>We only have two types of entity, CA and End entity. Can we not reflect
this
>in the directory by CA's using CA-Certificate attribute and end entities
use
>the user-certificates attribute?
>Trevor

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

Attachment converted: Lutefisk:smime.p7s 67 (????/----) (0001EACE)

Approved-By:  Michael Myers <[email-masked]>
Date:         Mon, 16 Feb 1998 17:09: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: Michael Myers <[email-masked]>
Subject:      [IETF-PKIX] OCSP Current Status
To: [email-masked]
Status:

All,

You should be hearing from IETF soon of an update to the OCSP draft.  It
takes into account comments in D.C. regarding extensibility, both in the
request and in the response.  Several other tweaks have been made, such as a
more formal BNF specification of request and response syntax.  Many thanks
to Rich Ankey of Certco for his contributions to this draft.

Interested parties should review the draft for responsiveness to
requirements and technical completeness in anticipation of a formal Last
Call going in to L.A.

Mike

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 10:52:23 +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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

snip
>
>However, the point I was trying to make (in the discussion, if not the
>text) is that PKIX should use the term "cross-certificate" rather than
>"CA-certificate" in its documents precisely to try and diminish/remove
>possible confusion (i.e., so that people would be more inclined to put
>the result in the cross-certificate attribute than in the cACertificate
>attribute).  The argument I was making (which I believe we're in violent
>agreement on) is that it would not make sense for PKIX to call it a
>"CA-certificate" and then encourage people *not* to put it in the
>cACertificate attribute.  Life seems less error-prone if we simply call
>it a cross-certificate and then encourage people to put it in the
>cross-certificate attribute...

You are right, I do agree with you.

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

Attachment converted: Lutefisk:smime.p7s 63 (????/----) (0001EACA)

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Mon, 16 Feb 1998 16:24:41 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Carlisle,
When I am walking the chain, I do not know the nature of the superior CA
therefore if you logic is followed, I must be prepared to search the
Cross-certificates attribute, then the CA-certificate attribute resulting in
two directory hits in some instances as well as additional complexity of
code. Is it not simpler to  just search one attribute of an object with the
certainty of all certificate will be in that attribute, so it would make
sense to select the name of attribute would contains all CA certificates in
which case this would imply using the CA-certificate attribute.
We only have two types of entity, CA and End entity. Can we not reflect this
in the directory by CA's using CA-Certificate attribute and end entities use
the user-certificates attribute?
Trevor

Approved-By: [email-masked]
Date:         Mon, 16 Feb 1998 15:30: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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Carlisle Adams wrote:

> Hi Trevor,
>
> >----------
> >From:  Trevor Freeman[SMTP:[email-masked]]
> >Sent:  Monday, February 16, 1998 5:08 PM
> >To:    [email-masked]
> >Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
> >
> >I would disagree that cross-certificate attribute should be used at all. I
> >see this as falling into the same camp as Authority Revocation List, another
> >obsolete inheritance.
>
> Many CAs seem to find it useful to publish self-signed certificates in
> whatever public repository they use.  While this may have value, it
> typically does not have value during the certificate path-finding and
> path-validation process.  An easy thing to do that can simplify and
> speed up such processing, therefore, is to put self-signed certs and
> cross-certs in different places (so that path-finding / path-validation
> software gets only the certificates that it actually needs to look at).
> In the Directory, it seems to make sense to put cross-certificates in
> the cross-certificate attribute; this implies that self-signed certs go
> in the cACertificate attribute.
>
> >You do not intrinsically process an intra-domain
> >cross-certificate any different from an inter-domain cross-certificate. You
> >still obey the information contained in the certificate.
>
> I agree.
>
> >I would hope that
> >an organization when creating an inter-domain certificate would constrain is
> >use by setting the appropriate extensions, but that is a policy issue for
> >the organization.
>
> I agree.
>
> >I would not alter any of the processing because I found a
> >certificate in a different directory attribute so what is the point.
>
> The point is to try and simplify things so that you can easily get the
> certificates you need (and only the certificates you need).

and to not drown in the process under the weight of the veritable plethora of
certs that are bound to crop up at the CA's as we all deploy these services to
our users...

>
>
> >All certificates for a CA should be stored in the same attribute.
>
> It seems to me that there is benefit in separating self-signed certs
> from cross-certs.

I would agree, self-signed certs may or may not have commercial import so
burdening systems checking for commercial stuff when you have to plow through a
bunch of SS certs that were bundled into a secondary reference system is s
tremendous amount of potential overhead.

>
>
> Carlisle.

Todd
--
Todd's Latest Rant --
---------------------
"UCC, Commercial Law and numerous international Treaties are the
basis of the 'transaction requirements'. Technologies must adapt
to support them without making them conform to the technologies..."

Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 16 (TEXT/R*ch) (0001EAC7)
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 62 (????/----) (0001EAC8)

Approved-By: [email-masked]
Date:         Mon, 16 Feb 1998 11:03:31 -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: Todd Glassey <[email-masked]>
Organization: Coastek Infosys, Inc.
Subject:      [IETF-PKIX] PKIX WG Charter Amendment Text
Comments: To: Michael McNeil <[email-masked]>, Stuart Haber <[email-masked]>, Robert Zuccherato <[email-masked]>, Pat Cain <[email-masked]>, Denis Pinkas <[email-masked]>, Carlisle Adams <[email-masked]>
Comments: cc: Warwick Ford <[email-masked]>, Stephen Kent <[email-masked]>, Jeffery Schiller <[email-masked]>
To: [email-masked]
Status:

<html><HTML>
Hi all,
<BR>in the December meeting that took place in DC we took a straw pole
that resulted in an action item to add timestamping and non-repudiation
technologies into the breadth of the PKIX WG charter.

<P>To that end Robert Zuccherato and I have come up with this charter that
we would like to submit for your approval and commentary - We would like
to get some discussion and potentially approval of the additions so that
further work on time and timestamping standards can be done within the
WG.

<P>Here then for your review in the charter text update:

<P>----- BEGINING OF CHARTER TEXT ----

<P>Public-Key Infrastructure (X.509) (PKIX)
<BR>--------------------------------------------------
<BR>&nbsp;
<BR>&nbsp;Charter
<BR>&nbsp;Last Modified: February 13, 1998
<BR>&nbsp;
<BR>&nbsp;Current Status: Active Working Group
<BR>&nbsp;
<BR>&nbsp;Chair(s):
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Stephen Kent &lt;[email-masked]>
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Warwick Ford &lt;[email-masked]>
<BR>&nbsp;
<BR>&nbsp;Security Area Director(s):
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Jeffrey Schiller&nbsp; &lt;[email-masked]>
<BR>&nbsp;
<BR>&nbsp;Security Area Advisor:
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Jeffrey Schiller&nbsp; &lt;[email-masked]>
<BR>&nbsp;
<BR>&nbsp;Mailing Lists:
<BR>&nbsp;&nbsp;&nbsp;&nbsp; General Discussion Email:&nbsp; [email-masked]
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Archive:&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;
<A HREF="ftp://ftp.tandem.com/pub/ietf-pkix.current">ftp://ftp.tandem.com/pub/ietf-pkix.current</A>
<BR>&nbsp;&nbsp;&nbsp;&nbsp; To Subscribe:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
[email-masked]
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In Body of email&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
subscribe &lt;email address> ietf-pkix

<P>&nbsp;
<BR>Description of Working Group:
<BR>Many Internet protocols and applications which use the Internet employ
public-key technology for security purposes and require a public-key infrastructure
(PKI) to securely manage public keys for widely-distributed users or systems.&nbsp;
The X.509 standard constitutes a widely-accepted basis for such an infrastructure,
defining data formats and procedures related to distribution of public
keys via certificates digitally signed by certification authorities (CAs).

<P>For example, RFC 1422 specified the basis of an X.509-based PKI, targeted
primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).&nbsp;
Since RFC 1422 was issued, application requirements for an Internet PKI
have broadened tremendously, and the capabilities of X.509 have advanced
with the development of standards defining the X.509 version 3 certificate
and version 2 certificate revocation list (CRL).

<P>Charter of the Working Group:
<BR>The charter of the working group will be to develop Internet standards
needed to support the use of an X.509-based PKI.&nbsp; The goal of this
Working Group (WG) will be to further facilitate the use of X.509 certificates
in applications that make use of the Internet and to promote interoperability
between different implementations choosing to make use of X.509 certificates.

<P>The resulting PKI is intended to provide a framework, which will support
a range of trust/hierarchy environments and a range of usage environments
(RFC1422 is an example of one such model).

<P>Candidate applications to be served by this PKI include, but are not
limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols,
Internet payment protocols, timestamping, and www protocols.

<P>This project will not preclude use of non-infrastructural public-key
distribution techniques nor of non-X.509 PKIs by such applications.&nbsp;
Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++)
project.

<P>The group will focus on tailoring and profiling the features available
in the v3 X.509 certificate to best match the requirements and characteristics
of the Internet environment.

<P>Other topics to be addressed potentially include:
<UL>* Alternatives for CA-to-CA certification links and structures, including
guidelines for constraints

<P>* Revocation alternatives, including profiling of X.509 v2 CRL extensions

<P>* Certificate and CRL distribution options (X.500-based,&nbsp; non-X.500-based)

<P>* Guidelines for policy definition and registration

<P>* Administrative protocols and procedures, including certificate generation,
revocation notification, cross-certification, and&nbsp; key-pair updating

<P>* Naming and name forms (how entities are identified, e.g., email address,
URN, DN, misc.)

<P>* Generation of client key pairs by the PKI

<P>* Services that support non-repudiation.&nbsp; This can include sources
of credible time data and/or certificate path validation services.</UL>
----- END OF CHARTER TEXT ----

<P>Thanks for your consideration -

<P>Todd Glassey (Coastek) and Robert Zuccherato (Entrust)
<BR>&nbsp;
<BR>&nbsp;</HTML>

</html>Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Todd S. Glassey
Content-Disposition: attachment; filename="vcard.vcf"

Attachment converted: Lutefisk:vcard.vcf 15 (TEXT/R*ch) (0001EAC5)
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 61 (????/----) (0001EAC6)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 18:00: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Trevor,

>----------
>From:  Trevor Freeman[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 5:08 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>I would disagree that cross-certificate attribute should be used at all. I
>see this as falling into the same camp as Authority Revocation List, another
>obsolete inheritance.

Many CAs seem to find it useful to publish self-signed certificates in
whatever public repository they use.  While this may have value, it
typically does not have value during the certificate path-finding and
path-validation process.  An easy thing to do that can simplify and
speed up such processing, therefore, is to put self-signed certs and
cross-certs in different places (so that path-finding / path-validation
software gets only the certificates that it actually needs to look at).
In the Directory, it seems to make sense to put cross-certificates in
the cross-certificate attribute; this implies that self-signed certs go
in the cACertificate attribute.

>You do not intrinsically process an intra-domain
>cross-certificate any different from an inter-domain cross-certificate. You
>still obey the information contained in the certificate.

I agree.

>I would hope that
>an organization when creating an inter-domain certificate would constrain is
>use by setting the appropriate extensions, but that is a policy issue for
>the organization.

I agree.

>I would not alter any of the processing because I found a
>certificate in a different directory attribute so what is the point.

The point is to try and simplify things so that you can easily get the
certificates you need (and only the certificates you need).

>All certificates for a CA should be stored in the same attribute.

It seems to me that there is benefit in separating self-signed certs
from cross-certs.

Carlisle.

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 17:36:45 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Charles,

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 5:16 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>>Given that we are both saying exactly the same thing, are you still in
>>violent disagreement?
>
>Can you please provide the text ( not the discussion)  that I am now
>violently agreeing with.

There is no text, only discussion (because it is not the job of CMP to
mandate where things go in an X.500 Directory; that is the job of a
Directory Schema document (which the WG has agreed to take on as a work
item)).

However, the point I was trying to make (in the discussion, if not the
text) is that PKIX should use the term "cross-certificate" rather than
"CA-certificate" in its documents precisely to try and diminish/remove
possible confusion (i.e., so that people would be more inclined to put
the result in the cross-certificate attribute than in the cACertificate
attribute).  The argument I was making (which I believe we're in violent
agreement on) is that it would not make sense for PKIX to call it a
"CA-certificate" and then encourage people *not* to put it in the
cACertificate attribute.  Life seems less error-prone if we simply call
it a cross-certificate and then encourage people to put it in the
cross-certificate attribute...

Carlisle.

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 17:12:46 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Warwick,

I'm quite happy with the proposed modifications.

Do others on the list have other modifications to suggest?

Carlisle.

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 8:09 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>"cross-certification request":  One CA requests issuance of a
>cross-certificate from another CA.  For the purposes of this standard, the
>following terms are defined.  A "cross-certificate" is a certificate in
>which the subject CA and the issuer CA are distinct and
>SubjectPublicKeyInfo contains a verification key (i.e., the certificate has
>been issued for the subject CA's signing key pair).  When it is necessary
>to distinguish more finely, the following terms may be used:  a
>cross-certificate is called an "inter-domain cross-certificate" if the
>subject and issuer CAs belong to different administrative domains; it is
>called an "intra-domain cross-certificate" otherwise.
>
>Notes:
>1. The above definition of "cross-certificate" aligns with the defined term
>"CA-certificate" in X.509.  Note that this term is not to be confused with
>the X.500 "cACertificate" attribute type, which is unrelated.
>2. In many environments the term "cross-certificate", unless further
>qualified, will be understood to be synonymous with "inter-domain
>cross-certificate" as defined above.
>3. Issuance of cross-certificates may be, but is not necessarily, mutual;
>that is, two CAs may issue cross-certificates for each other."

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 08:16: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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

snip
>Given that we are both saying exactly the same thing, are you still in
>violent disagreement?

Can you please provide the text ( not the discussion)  that I am now
violently agreeing with.

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

Attachment converted: Lutefisk:smime.p7s 59 (????/----) (0001EAC1)

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Mon, 16 Feb 1998 14:08:01 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

I would disagree that cross-certificate attribute should be used at all. I
see this as falling into the same camp as Authority Revocation List, another
obsolete inheritance. You do not intrinsically process an intra-domain
cross-certificate any different from an inter-domain cross-certificate. You
still obey the information contained in the certificate. I would hope that
an organization when creating an inter-domain certificate would constrain is
use by setting the appropriate extensions, but that is a policy issue for
the organization. I would not alter any of the processing because I found a
certificate in a different directory attribute so what is the point. All
certificates for a CA should be stored in the same attribute.
Trevor

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 16 Feb 1998 17:09:32 -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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Carlisle:

Thank you for your admirable efforts to reach a compromise definition!  I
generally agree with your proposal.  However, I think the text needs small
changes in a couple of places.

What is probably not generally known is that X.509 has an inherent problem
in that the defined term "CA-certificate" bears absolutely no relationship
to the cACertificate attribute.  This was an unfortunate terminology snafu
in X.509, and is undoubtedly a big part of the confusion we have faced in
PKIX.

The main point is that the intended use of the defined term
"CA-certificate" is precisely the same as your definition of
"cross-certificate".  The term was coined in X.509 for the purposes of
specifying the chain-validation algorithm, i.e., to be able to easily
distinguish between an end-entity certificate (the last one in the chain)
and the CA-certificates, i.e., all the other certificates in the chain.  I
don't believe self-signed certificates come into it, since X.509 (including
the chain validation algotithm) never recognizes the existence of such
things.

The cACertificate attribute is a different beast ... its intended usage has
never been clear.  The latest resolution of the X.509 group has been to
suggest that it might be used for storing a self-signed certificate, but it
might be used for other things too (to accommodate implementors who may
have used that attribute for other purposes).

Regardless of PKIX, X.509 has had to resolve this issue.  The resolution
reached at the Jan X.509 meeting was to include a note that said explicitly
that the defined term and the attribute were not related and should not be
confused.

Given that background, I believe your "definition" of CA-certificate could
be misleading, and not in line with the X.509 intent.  Let's fix that, and
let's also include the note saying not to confuse the CA-certificate
defined term with the X.500 attribute.

As a separate point, I don't believe it is useful to define
"cross-certification" as "Any process that...".  If we wanted to move into
that territory we would need to identify the various stages of request,
approval, issuance, acceptance, etc.  I think Denis Pinkas was on the ball
in saying that what we really need to define in PKIX is
"Cross-certification request", which is what CMP does, rather than the
abstract concept of cross-certification overall.

Accordingly, I propose some slight modifications to your text:

"cross-certification request":  One CA requests issuance of a
cross-certificate from another CA.  For the purposes of this standard, the
following terms are defined.  A "cross-certificate" is a certificate in
which the subject CA and the issuer CA are distinct and
SubjectPublicKeyInfo contains a verification key (i.e., the certificate has
been issued for the subject CA's signing key pair).  When it is necessary
to distinguish more finely, the following terms may be used:  a
cross-certificate is called an "inter-domain cross-certificate" if the
subject and issuer CAs belong to different administrative domains; it is
called an "intra-domain cross-certificate"
otherwise.

Notes:
1. The above definition of "cross-certificate" aligns with the defined term
"CA-certificate" in X.509.  Note that this term is not to be confused with
the X.500 "cACertificate" attribute type, which is unrelated.
2. In many environments the term "cross-certificate", unless further
qualified, will be understood to be synonymous with "inter-domain
cross-certificate" as defined above.
3. Issuance of cross-certificates may be, but is not necessarily, mutual;
that is, two CAs may issue cross-certificates for each other."

Warwick

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

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 16:19: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi Charles,

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  Monday, February 16, 1998 4:07 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
>
>> where would such a
>>thing likely be put in the Directory (despite any warnings we might put
>>in that the two terms are unrelated)?
>> If PKIX calls it some new name,
>>where would it be put?  All this would really accomplish would be to
>>complicate path-finding procedures unnecessarily.  I fail to see much
>>value in taking what people think of as a cross-certificate, calling it
>>a CA-certificate, and then encouraging Directory users to put it in the
>>cross-certificate attribute rather than the ca-certificate attribute...
>
>Because a cross certificate should go in a cross certificate pair attribute.
>
>Lets look at this for a while, we go to the directory looking for cross
>certificates, we find a cross certificate pair attribute but NO we dont use
>this to find a cross certificate we go looking for a CA Attribute. Is this
>realy what is seriously being proposed!!!

No, this is *not* what is seriously being proposed.  In fact, I am
proposing exactly the opposite:  that we try to ensure that we *don't*
look in the CA-certificate attribute for cross-certificates, but instead
look only in the cross-certificate attribute (in the forward, or
reverse, or both, parameter of the cross-certificate pair).

>>Allowing for WG members in different time zones, I propose to wait until
>>Wednesday for responses to the above definition.  Unless there is
>>violent disagreement with the wording, I will include this definition in
>>CMP and submit it at that time.
>
>Ok, you have the violent disagreement, you were waiting for.

Given that we are both saying exactly the same thing, are you still in
violent disagreement?

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

Approved-By:  Charles Moore <[email-masked]>
Date:         Tue, 17 Feb 1998 07:07:35 +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] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

-----Original Message-----
From: Carlisle Adams <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Tuesday, 17 February 1998 3:55
Subject: [IETF-PKIX] Defining Terms w.r.t. Cross Cert...

snip: disagreed stuff.

>- Again, for better or worse, rightly or wrongly, the X.500 Directory
>standard defines attributes called "ca-certificate" and
>"cross-certificate".  If PKIX takes what we all intuitively think of as
>a cross-certificate and calls it a CA-certificate,

This is not what we ALLintuitively think. And given the lack of cross
certificate deployments
within a hetrogenious envionment I dont believe that this statement has
basis.

> where would such a
>thing likely be put in the Directory (despite any warnings we might put
>in that the two terms are unrelated)?
> If PKIX calls it some new name,
>where would it be put?  All this would really accomplish would be to
>complicate path-finding procedures unnecessarily.  I fail to see much
>value in taking what people think of as a cross-certificate, calling it
>a CA-certificate, and then encouraging Directory users to put it in the
>cross-certificate attribute rather than the ca-certificate attribute...

Because a cross certificate should go in a cross certificate pair attribute.

Lets look at this for a while, we go to the directory looking for cross
certificates, we find a cross certificate pair attribute but NO we dont use
this to find a cross certificate we go looking for a CA Attribute. Is this
realy what is seriously being proposed!!!

>
>
>Allowing for WG members in different time zones, I propose to wait until
>Wednesday for responses to the above definition.  Unless there is
>violent disagreement with the wording, I will include this definition in
>CMP and submit it at that time.

Ok, you have the violent disagreement, you were waiting for.

>  Thanks again to everyone for all the
>input!
>
>
>--------------------------------------------
>Carlisle Adams
>Entrust Technologies
>[email-masked]
>--------------------------------------------

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

Attachment converted: Lutefisk:smime.p7s 58 (????/----) (0001EAC0)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Mon, 16 Feb 1998 12:12: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: Carlisle Adams <[email-masked]>
Subject:      [IETF-PKIX] Defining Terms w.r.t. Cross Cert...
To: [email-masked]
Status:

Hi All,

I appreciate all the recent feedback on this topic; this is what a
mailing list is all about!  Since, however, this seems to be the last
remaining issue for PKIX-CMP, it would be great if we could wrap up this
definition and get the draft submitted (CMP has been on hold for weeks
now while we debated the definition of cross-certification, which is
unfortunate, given that this is such a small part of the whole
draft...).

As far as I can tell, the following proposal is sensitive to all the
e-mails (both public and private) that I've seen.

"cross-certification:  Any process that results in the creation of a
cross-certificate.  For the purposes of this standard, the following
terms are defined.  A "CA-certificate" is any certificate in which both
the subject and issuer are CAs.  A "cross-certificate" is a
CA-certificate in which the subject CA and the issuer CA are distinct
and  SubjectPublicKeyInfo contains a verification key (i.e., the
certificate has been issued for the subject CA's signing key pair).
When it is necessary to distinguish more finely, the following terms may
be used:  a cross-certificate is called an "inter-domain
cross-certificate" if the subject and issuer CAs belong to different
administrative domains; it is called an "intra-domain cross-certificate"
otherwise.  (Note:  in many environments the term "cross-certificate",
unless further qualified, will be understood to be synonymous with
"inter-domain cross-certificate" as defined above.).  Issuance of
cross-certificates may be, but is not necessarily, mutual; that is, two
CAs may issue cross-certificates for each other."

Some comments.

1) The first sentence addresses those who were concerned that the
previous definition of cross-certification mandated a request from the
subject CA and a response from the issuer CA.  This now makes it clear
that the so-called "spontaneous" decision by the issuer still
constitutes "cross-certification".

2) The definition of "CA-certificate" aligns with that given in X.509.
The definition of "cross-certificate" is slightly more restrictive in
that a self-signed certificate is explicitly *not* a cross-certificate,
but I believe this would correspond with everyone's understanding and
use of the term today.

3) The note at the end addresses those who feel that cross-certification
applies only to CAs in different administrative domains.  This note
makes it clear that such will be the common interpretation without
completely closing the door to other possible interpretations.

4) I recognize that some wanted to drop the term cross-certificate (or
cross-certification) completely and move to something else (such as
CA-certificate or one of the other candidates).  However, the following
two reasons might be offered for keeping "cross-certificate" in these
documents.

- For better or worse, rightly or wrongly, the industry (including the
media) has adopted the term "cross-certificate".  It is true that
different people often mean different things when they use it.  However,
it seems much more sensible to define the term than to, at this late
stage, try to introduce a new term that no one is familiar with.  It's a
bit like "certificate", or "signature", or a number of other terms; I'm
not sure we have the luxury of choosing names for these concepts any
more, but we *can* define what PKIX means when they are used in PKIX
documents.

- Again, for better or worse, rightly or wrongly, the X.500 Directory
standard defines attributes called "ca-certificate" and
"cross-certificate".  If PKIX takes what we all intuitively think of as
a cross-certificate and calls it a CA-certificate, where would such a
thing likely be put in the Directory (despite any warnings we might put
in that the two terms are unrelated)?  If PKIX calls it some new name,
where would it be put?  All this would really accomplish would be to
complicate path-finding procedures unnecessarily.  I fail to see much
value in taking what people think of as a cross-certificate, calling it
a CA-certificate, and then encouraging Directory users to put it in the
cross-certificate attribute rather than the ca-certificate attribute...

Allowing for WG members in different time zones, I propose to wait until
Wednesday for responses to the above definition.  Unless there is
violent disagreement with the wording, I will include this definition in
CMP and submit it at that time.  Thanks again to everyone for all the
input!

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

Approved-By:  Trevor Freeman <[email-masked]>
Date:         Fri, 13 Feb 1998 13:38:31 -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: Trevor Freeman <[email-masked]>
Subject:      Re: [IETF-PKIX] Key usage. No, wait, *extended* key usage
Comments: To: "Ietf-Smime (E-mail)" <[email-masked]>
To: [email-masked]
Status:

I am inclined to agree with both Jim and John.
I agree with Jim that the contents of the extended key usage extension may
have implication on the cert chain. The difficulty with extended key usage
is that the set of possible values will never be constrained, so we don't
know what all the possible outcome would be of a check. I also agree with
john that the right place to clarify this point as what the right thing to
do is in the pkix workgroup.
Trevor
> -----Original Message-----
> From: [email-masked] [SMTP:[email-masked]]
> Sent: Friday, February 13, 1998 12:50 PM
> To:   Ietf-Smime (E-mail)
> Subject:      RE: Key usage. No, wait, *extended* key usage
>
> Jim,
>
> For some extensions, the X.509 and PKIX I specs specify when there are
> relationships that must be checked between the values in each of the
> extensions present in the certs that compose a cert path (ex:
> nameConstraints extension).  I can't find any text in X.509 or PKIX I that
> states any requirements for checking any relationship between the values
> in
> the extendedKeyUsage extension present in each cert in the cert path.
>
> Therefore, I don't agree with your implication that the S/MIME v3 Cert
> Handling spec should state any requirements about checking the
> extendedKeyUsage extension values in CA certs.  Furthermore, I agree with
> Pat Cain's "less-is-more" philosophy (see attached message) regarding
> minimizing the mandatory requirements included in the S/MIME v3 Cert
> Handling spec (CERT3).  I agree with Pat that CERT3 should not require any
> checks of the extendedKeyUsage extension.
>
> - John Pawling
>
>
> At 12:00 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
> >John,
> >
> >>
> >> I agree with your suggestion to add wording like:  "Prior to using the
> >> public key included in a certificate to support S/MIME
> >> security services, if
> >> the extendedKeyUsage extension is present in the certificate and is
> >> indicated as being critical, then the S/MIME software MUST
> >> ensure that the
> >> id-kp-emailProtection OID is present.  This check is only
> >> required for the
> >> end-entity certificates."
> >
> >The above is not the way that I had read the docs and how
> >extendedKeyUsage would/should be evaluated,  I am curious why you think
> >that only the end-entity certificate should be checked?  I had thought
> >that the entire chain should be checked even though I did not really
> >expect to see any extendedKeyUsage extensions once I got off the
> >end-entity certificate.
> >
> >I can see the case occuring where a super-CA might say that this CA can
> >only be used for issuing certifiate with the e-mail purpose and I am not
> >sure this should be so explicity disabled.
> >
> >jim
> >
>
>
> >Return-Path: <[email-masked]>
> >X-Sender: [email-masked]
> >Date: Fri, 06 Feb 1998 16:05:41 -0600
> >To: [email-masked]
> >From: Pat Cain <[email-masked]>
> >Subject: Re: un-*extended* key usage
> >Sender: [email-masked]
> >Precedence: bulk
> >
> >Friends,
> >
> >I worry that we may end up putting too many constraints on the SMIME
> >certificate(s)
> >that are not related to interoperability of the protocol. We originally
> >specified the
> >key-usage and name extensions because they really (REALLY) did impact
> >interoperability.
> >Almost all of the other useful X.509 extensions effect how the signature
> or
> >encrypted/random data is interpreted and/or used. For example, if I, as a
> >CA, issue certificates that are good for any number of protocols, it is
> >hard for me to beleive
> >that SMIME (the protocol) really cares. Think of this in the 'Do I
> support
> >delta-CRLs' vain. I hope (pray) that we don't specify the CRL-ing
> technique
> >-- it's a CA policy decision. Much like what uses a particular
> certificate
> >is good for.
> >
> >I vote to leave specific recommendations for extended key usage, beyond
> >what X.509 discusses for criticality and other stuff, out of the spec. If
> a
> >particular CA wants
> >to require extended OIDs in their certiifcates, so be it. But that's one
> of
> >those
> >CA 'policy kind of' things.
> >
> >Pat
> >
> >

Approved-By:  Tolga Acar <[email-masked]>
Date:         Thu, 12 Feb 1998 10:49:47 -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:      [IETF-PKIX] Authority Key Identifier Cert. Extension
To: [email-masked]
Status:

In the PKIX Draft, X.509, sec. 4.2.1.1 Authority Key Identifier extension, the first sentence should be corrected as follows:

old:
"The authority key identifier extension provides a means of identifying the particular public key used to sign a certificate."

new:
"The authority key identifier extension provides a means of identifying the particular private key used to sign a certificate."

change: public --> private

-- Tolga

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Thu, 12 Feb 1998 08:21: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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Warwick,

Glad to hear that we are in agreement that the biggest challenge is NOT
technology.

Also I agree that the complexity of the business, legal etc issues are
particularly
key to public CAs. When a pair of organizations operating internal CAs
decide to cross-certify they may have an existing business relationship,
which can be
extended to address the cross-certification support for that business
relationship. This is clearly a different "business" model than a public
CA cross-certifying with another public CA or with an enterprise CA.

Since the PKIX specifications which are on the standards track are not
dealing with the business relationship issues, but the supporting
technology, lets remove the business relationship issues from the table
and focus on the technology to support them.

------------------
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:  February 12, 1998 1:17 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
>
>Apologies, all.  That message was not intended for distribution to the
>list.  For clarification as requested, I was reflecting my belief that
>inter-domain certification (cross-certification to some) is a complex
>subject still requiring a lot of work - however, the biggest challenges lie
>not in technology but in the business, legal, and information management
>issues faced, in particular, by commercial CAs and their corresponding-CA
>communities.  My apologies for taking another vendor's name in vain.  Shall
>be more careful in future.
>
>Warwick
>
>
>At 12:56 PM 2/9/98 -0500, Sharon Boeyen wrote:
>>Warwick -  an unfortunate style choice ...
>
>---------------------------------------------------------------------
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>---------------------------------------------------------------------
>

Approved-By:  Warwick Ford <[email-masked]>
Date:         Wed, 11 Feb 1998 22:17: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] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Apologies, all.  That message was not intended for distribution to the
list.  For clarification as requested, I was reflecting my belief that
inter-domain certification (cross-certification to some) is a complex
subject still requiring a lot of work - however, the biggest challenges lie
not in technology but in the business, legal, and information management
issues faced, in particular, by commercial CAs and their corresponding-CA
communities.  My apologies for taking another vendor's name in vain.  Shall
be more careful in future.

Warwick

At 12:56 PM 2/9/98 -0500, Sharon Boeyen wrote:
>Warwick -  an unfortunate style choice ...

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

Approved-By:  Charles Moore <[email-masked]>
Date:         Thu, 12 Feb 1998 06:40:07 +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 Clarification
To: [email-masked]
Status:

-----Original Message-----
From: David P. Kemp <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, 12 February 1998 1:36
Subject: Re: [IETF-PKIX] Cross Certification Clarification

:> From: Charles Moore <[email-masked]>
:>
:> A CA-Certificate is a certificate, a cross certificate may optionly  be
both
:> an forward and reverse certificate.
:
:
:Ah haaaaah.  So that's the (at least one) source of confusion.
:Fortunately, this one is easily cleared up.
:
:One group of folks is using "cross-certificate" to refer to a single
:X.509 Certificate which is issued across domain boundaries (as opposed
:to within a heirarchy).
:
:Another group of folks is using "cross-certificate" to refer to the
:X.509 attribute type "crossCertificatePair", which has syntax
:"CertificatePair".
:

:Well, the mates have been quaffing too much Foster's :-).  They should be
:using the term CertificatePair to refer to the structure which optionally
:contains forward and reverse certificates.

I can agree with your suggestion, if I was directly referring to the syntax.

The discussion to date, has forced me to have to agree with Warwick that we
need a definition.

The cross certificate pair supports both requirements, including aribitary
direction.

I dont believe we need to define a specific subset. There is also the issue
of how to use what you have specified.

We use cross certificate pairs to find cross certificates, my problem with
the proposal to make it a CACertificate is that it just complicates the cert
path processing without any gain ( that I understand).

So with a couple of XXXX ( much better than Fosters), perhaps a better
question is, to the cross-certificate = certificate camp. Is there anything
that you want to do that can not be done with a cross certificate pair ?

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

Attachment converted: Lutefisk:smime.p7s 52 (????/----) (0001E8A8)

Approved-By:  [email-masked]
Date:         Wed, 11 Feb 1998 13:21:09 EST
Reply-To: "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] Cross Certification Clarification
To: [email-masked]
Status:

Another point I'd like to make is that even though CA-certificate and
cross-certificate have the same syntax, that is not sufficient reason to not
use one of them. For instance, surname and generationQualifier have the same
syntax but not the same meaning. Even though CA-certificate and
cross-certificate have the same syntax, their meanings are different. I believe
that a cross-certificate may be a CA-certificate (a certificate for a CA issued
by another CA), but a CA-certificate may not be a cross-certificate (a
certificate for a CA issued by another CA in a different domain). I'm not
offering these as suggested definitions but simply to make the point that (in
my mind at least) these terms have different meanings.

Dave Oshman
Price Waterhouse
Electronic Commerce/Internet

Approved-By:  Stephen Kent <[email-masked]>
Date:         Wed, 11 Feb 1998 13:28: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: Stephen Kent <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
Comments: To: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Status:

Phill,

I concur with your observation, in most cases.  When a CA issues a cert to
another CA, it ought to include name constraints to limit the scope of
identities for which the target CA is authorized to certify.  This works
well for CA models where the CAs are authoritative for name spaces, not so
well for third-party CAs who have no such standing.  In the latter case,
name constraints generally don't well, so in that context distinguishing
cross-certs from other CA certs seems potentially useful.  However, if the
distinction appears only in the directory entry format, the utility may be
minimal.  This is the same problems we used to have with v1 certs, where
there was a presumption that one could rely on directory attributes to
learn important features about certs, since these attributes were not
present in the certs per se.

Steve

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Wed, 11 Feb 1998 10:02:14 -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 Clarification
To: [email-masked]
Status:

> From: Charles Moore <[email-masked]>
>
> A CA-Certificate is a certificate, a cross certificate may optionly  be both
> an forward and reverse certificate.

Ah haaaaah.  So that's the (at least one) source of confusion.
Fortunately, this one is easily cleared up.

One group of folks is using "cross-certificate" to refer to a single
X.509 Certificate which is issued across domain boundaries (as opposed
to within a heirarchy).

Another group of folks is using "cross-certificate" to refer to the
X.509 attribute type "crossCertificatePair", which has syntax
"CertificatePair".

Well, the mates have been quaffing too much Foster's :-).  They should be
using the term CertificatePair to refer to the structure which optionally
contains forward and reverse certificates.

Approved-By: [email-masked]
Date:         Tue, 10 Feb 1998 14:23: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: Gina DePlanche <[email-masked]>
Subject:      [IETF-PKIX] CMP draft question
Comments: To: [email-masked]
To: [email-masked]
Status:

        Hi!

        I have a question about the root CA fingerprint mentioned in
the CMP draft-ietf-pkix-ipki3cmp-06.txt. I was wondering if someone
could please clarify the procedure in section 4.1.  In particular,
in the second paragraph, I find the use of the terms "this information"
and "this value" unclear when several values are referred to in the section.
Also, how does the fingerprint allow an end entity to securely use the CAs
self-certificate, as mentioned in section 4.7.2?

        Thank you for your 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:  "David M. Balenson" <[email-masked]>
Date:         Wed, 11 Feb 1998 00:00:23 -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 M. Balenson" <[email-masked]>
Subject:      [IETF-PKIX] REMINDER: ISOC 1998 Network and Distributed Security Symposium
To: [email-masked]
Status:

Ok, now that I got your attention, here's the missing text ...

1998 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM
March 11-13, 1998
Catamaran Resort Hotel
San Diego, California
Sponsored by the Internet Society
Program Chairs:  Matt Bishop, University of California at Davis
                 Steve Kent, BBN Technologies

ONLINE INFORMATION AND REGISTRATION:  http://www.isoc.org/ndss98
EARLY REGISTRATION DISCOUNT DEADLINE:  February 13, 1998

This 5th annual Symposium brings together researchers, implementers,
and users of network and distributed system security technologies
to discuss today's important security issues and challenges.  The
Symposium provides a mix of technical papers and panel presentations
that describe promising new approaches to security problems that
are practical and, to the extent possible, have been implemented.
NDSS'98 fosters the exchange of technical information and encourages
the Internet community to deploy available security technologies
and develop new solutions to unsolved problems.

KEYNOTE SPEAKER: Howard Gittleson, Director of the Internet Security
Products Group at Bell Laboratories, Lucent Technologies

THIS YEAR'S TOPICS INCLUDE:
- Internet and Intranet security
- Implementation issues for electronic commerce
- All-optical networks security
- Secure single login
- Timestamping protocols
- Remote password protocols
- Mobile agent systems security
- Java security
- Trust management
- Traffic analysis of TCP gateways
- Secure bootstrapping
- Firewalls and IP security

NEW THIS YEAR!  PRE-CONFERENCE TECHNICAL TUTORIALS:
- Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies)
- Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI)
- Kerberos  (Jeffrey I. Schiller, MIT)
- Internet Security with Firewalls  (Fred Avolio, TIS)
- Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI)

FOR MORE INFORMATION contact the Internet Society:
     Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA
     Phone: +1 703 648 9888
     Fax: + 1 703 648 9887
     E-mail: [email-masked]
     URL: http://www.isoc.org/ndss98/

SPONSORSHIP OPPORTUNITIES AVAILABLE!  Take advantage of this high
visibility event.  Contact Torryn P. Brazell at the Internet Society
at +1 703 648 9888 or send e-mail to [email-masked].
Sponsorship Chair: George Conrades, GTE Internetworking

THE INTERNET SOCIETY is a non-governmental organization for global
cooperation and coordination for the Internet and its
internetworking technologies and applications.

Approved-By:  Charles Moore <[email-masked]>
Date:         Wed, 11 Feb 1998 14:33:23 +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 Clarification
To: [email-masked]
Status:

> -----Original Message-----
> From: Carlisle Adams [SMTP:[email-masked]]
> Sent: Wednesday, February 11, 1998 8:24 AM
> To:   [email-masked]
> Subject:      Re: [IETF-PKIX] Cross Certification Clarification
>
> Hi Charles,
>
> >----------
> >From:  Charles Moore[SMTP:[email-masked]]
> >Sent:  Tuesday, February 10, 1998 5:15 PM
> >To:    [email-masked]
> >Subject:       Re: [IETF-PKIX] Cross Certification Clarification
> >
> >Do you have a suggested term for repesenting the kind of certificate
> that is
> >created unilaterally by one entity (normally a CA) which includes
> another
> >entity's (normally another CA) public key, NOT necessarily as a
> result of a
> >request by CA which is being certified?
> ...
> >I don't object to the proposed terminology, but it leaves me without
> an
> >agreed term for what I believe may be the most common occurance
> >of what I would have otherwise called a cross-certificate.
        [Charles Moore]  Not my text actually ( problem with threads).

> The proposed text says:
>
> "For the purposes of this standard, a cross-certificate (also known as
> CA-certificate) is considered to be any certificate issued by one CA
> for
> another CA's signing key pair (that is, for another CA's public
> verification key)..."
>
> Why exactly do you think that this does not cover what you want?
>
>
>
>
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> [email-masked]
> --------------------------------------------

Approved-By:  Charles Moore <[email-masked]>
Date:         Wed, 11 Feb 1998 11:40:44 +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 Clarification
To: [email-masked]
Status:

-----Original Message-----
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Wednesday, 11 February 1998 1:18
Subject: Re: [IETF-PKIX] Cross Certification Clarification

:Michael Bungert wrote:
:
:> IMO, a cross-certificate should clearly be distinguished from a CA
:> certificate issued by a parent CA to a subordinated CA. I think that
:> this distinction emphasizes the important property of the PKIX
:> infrastructure that it does not rely on a global hierarchie of CAs
:> but allows a web of independent trust domains which can be linked by
:> 'real' cross-certificates.
:
:Funnily enough I think the terms should be defined to be the same for
:precisely the same reason.
:
:The question is whether there is an objective, semantic difference
:created when a certificate becomes a CA cert rather than a cross
:cert. I have a sneaking feeling that some people believe that the
:problems of inter-domain certification that are involved with
:CA certificates somehow magically disappear if they are called
:a 'cross-certificate'. In fact the only justification for introducing
:a special class for subordinated CA certificates would be if the
:problems of inter-domain certification disappeared in that special
:case which they don't.

A CA-Certificate is a certificate, a cross certificate may optionly  be both
an forward and reverse certificate.
If I want to find a cross cert ( symantics) I go look for a  cross cert
attribute ( if this only has one of the two, so what), if I want to find a
CA certificate I go look for a CA-certificate attribute. With the above I
can find the things I need to make a certifiaction path.
Thats the only different that matters for PKIX.

I have real difficulty with overloading CA-certificate with the symantics of
a cross cert.

:
:
:Unless there is a semantic difference defined between subordinate
:name CA certs and non-subordinate name certs why introduce confusion?

I belive it is useful to use a cross-certificate attribute to find cross
certificates, and CA-attribute to find CA-certificates, the difference in
symantics is very useful.

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

Attachment converted: Lutefisk:smime.p7s 51 (????/----) (0001E842)

Approved-By:  "David M. Balenson" <[email-masked]>
Date:         Tue, 10 Feb 1998 18:33:29 -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 M. Balenson" <[email-masked]>
Subject:      [IETF-PKIX] REMINDER: ISOC 1998 Network and Distributed System Security Symposium
To: [email-masked]
Status:

----------------------------------------------------------------------------
David M. Balenson, AR&E Cryptographic Technologies Group
Trusted Information Systems, 3060 Washington Road, Glenwood, MD 21738  USA
[email-masked]; 301-854-5358; fax 301-854-5363

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 10 Feb 1998 17:24:14 -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 Clarification
To: [email-masked]
Status:

Hi Charles,

>----------
>From:  Charles Moore[SMTP:[email-masked]]
>Sent:  Tuesday, February 10, 1998 5:15 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross Certification Clarification
>
>Do you have a suggested term for repesenting the kind of certificate that is
>created unilaterally by one entity (normally a CA) which includes another
>entity's (normally another CA) public key, NOT necessarily as a result of a
>request by CA which is being certified?
...
>I don't object to the proposed terminology, but it leaves me without an
>agreed term for what I believe may be the most common occurance
>of what I would have otherwise called a cross-certificate.

The proposed text says:

"For the purposes of this standard, a cross-certificate (also known as
CA-certificate) is considered to be any certificate issued by one CA for
another CA's signing key pair (that is, for another CA's public
verification key)..."

Why exactly do you think that this does not cover what you want?

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

Approved-By:  Charles Moore <[email-masked]>
Date:         Wed, 11 Feb 1998 08:15:36 +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 Clarification
Comments: To: Bob Jueneman <[email-masked]>
To: [email-masked]
Status:

-----Original Message-----
From: Bob Jueneman <[email-masked]>
To: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: Tuesday, 10 February 1998 4:35
Subject: Re: [IETF-PKIX] Cross Certification Clarification

My question to both the Australian mates and the Canadians (at least 2 out
of 3,
I assume, not being sure about Tim):

I tried to set out a simple defintion some time ago.

I would like the definition to be useful to support a variety of PKI
requirements.

Today we support the cross-certificate attribute defintion as the means to
find cross certificates, I dont realy care if some one wants one way two way
or any combination to meet the policy requirements. Certification path
navigation with Xcerts is difficult at the best of times  in a hetrogenious
envionment, having  a cross cert defined as a CA-certificate does not help
anyone ( or at least people that want to build this stuff).

Do you have a suggested term for repesenting the kind of certificate that is
created unilaterally by one entity (normally a CA) which includes another
entity's (normally another CA) public key, NOT necessarily as a result of a
request by CA which is being certified?

CertificatePair    ::= SEQUENCE {
 forward   [0] Certificate OPTIONAL,
 reverse   [1] Certificate OPTIONAL
       -- at least one of the pair shall be present -- }

Its just a cross certificate with only one of the options selected.

As a CA-certificate is defined as a certificate rather than a certificate
pair, the cross cert must work for the CA certificate case right?

Or is there something that I have just not understood here.

I don't object to the proposed terminology, but it leaves me without an
agreed term for what I believe may be the most common occurance
of what I would have otherwise called a cross-certificate.

I dont like the proposed text at all, but if we MUST have one then at least
it should, a) make some sense, b) be consistant with what exists in the
X.509 standards and not break stuff that is based on this.

If its not broken, dont fix it.

I raly dont see why there is such a problem, and the proposed solution just
confuses me.

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

Attachment converted: Lutefisk:smime.p7s 50 (????/----) (0001E835)

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 10 Feb 1998 16:16: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] CMP draft question
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

Hi Gina,

>----------
>From:  [email-masked][SMTP:[email-masked]]
>Sent:  Tuesday, February 10, 1998 2:23 PM
>To:    Carlisle Adams; [email-masked]
>Subject:       CMP draft question
>
>       Hi!
>
>       I have a question about the root CA fingerprint mentioned in
>the CMP draft-ietf-pkix-ipki3cmp-06.txt. I was wondering if someone
>could please clarify the procedure in section 4.1.  In particular,
>in the second paragraph, I find the use of the terms "this information"
>and "this value" unclear when several values are referred to in the section.

Is the following clearer?

"In  order to make the CA's self certificate useful to end entities that
do not acquire the self certificate via "out-of-band" means, the CA
must also produce a fingerprint for its public key.  End entities that
acquire this fingerprint securely via some "out-of-band" means can then
verify the CA's self-certificate and hence the other attributes
contained therein."

>Also, how does the fingerprint allow an end entity to securely use the CAs
>self-certificate, as mentioned in section 4.7.2?

In order to trust the CA's public key, I either need a trusted copy of
the key itself or I need a trusted fingerprint of the key.  If I have
the latter I can verify the self-signed certificate (which I may have
acquired by any untrusted means) because I can compute the fingerprint
of the key in the certificate, compare it with the fingerprint that I
have, and (if they are equal) use the key to verify the certificate.

Carlisle.

Approved-By:  Tony Bartoletti <[email-masked]>
Date:         Tue, 10 Feb 1998 12:50:43 -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: Tony Bartoletti <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

At 02:50 PM 2/10/98 -0500, you wrote:

[snip]

>In terms of the protocol itself, and in terms of the actual syntax of
>the resulting certificate, does it matter whether the two CAs involved
>are brother-and-sister or distant-cousins?  Does it matter whether they
>are housed in the same building or separated by oceans?  Does it matter
>whether they are owned by the same corporation or owned by different
>corporations?  Again, in terms of the *protocol* itself and in terms of
>the *syntax* of the resulting certificate, no it does not.

Why not take the argument a step further.  I.e., "Does it matter that
either party is actually a CA or not." To answer in the affirmative
presumes some globally accepted definition of CA qualification.  But as
one writer pointed out (with regard to registering extensions) "What if
I want to be my own CA, and certify my family members."  By extension,
perhaps a husband-and-wife wish both to be CAs, and "cross-certify".

Sometimes "PKI" seems less apt than "CKI" (Commercial Key Infrastructure;)

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

Tony Bartoletti                                             LL
SPI-NET GURU                                             LL LL
Computer Security Technology Center                   LL LL LL
Lawrence Livermore National Lab                       LL LL LL
PO Box 808, L - 303                                   LL LL LLLLLLLL
Livermore, CA 94551-9900                              LL LLLLLLLL
email: [email-masked]   phone: 510-422-3881             LLLLLLLL

Approved-By:  Carlisle Adams <[email-masked]>
Date:         Tue, 10 Feb 1998 14:50: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: Carlisle Adams <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Bob,

>----------
>From:  Bob Jueneman[SMTP:[email-masked]]
>Sent:  Tuesday, February 10, 1998 10:36 AM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross Certification Clarification
>
>As was probably demonstrated by Warwick's recent message, there appear to be
>political forces at work here that would like to institutionalize certain
>existing terminology and practices, whether or not they appear to make sense
>to the rest of the community.

It seems to me that those who look for politics everywhere tend to see
politics everywhere, whether or not it actually exists.  It's a
self-fulfilling prophecy.  There is no reason (or room) for politics in
this discussion; what PKIX is trying to define is a single piece of
syntax and a protocol for creating it.  All this Working Group is trying
to achieve in this instance is a name for a certificate which has a CA
as a subject and another CA as an issuer, along with a specification for
how the subject CA can request such a beast.

In terms of the protocol itself, and in terms of the actual syntax of
the resulting certificate, does it matter whether the two CAs involved
are brother-and-sister or distant-cousins?  Does it matter whether they
are housed in the same building or separated by oceans?  Does it matter
whether they are owned by the same corporation or owned by different
corporations?  Again, in terms of the *protocol* itself and in terms of
the *syntax* of the resulting certificate, no it does not.

Certainly, there may be differences in operating policies and
procedures.  Trust may already be inherent in the relationship or it may
need to be explicitly established by out-of-band means.  But this does
not affect the protocol or the certificate itself.

>To me, and apparently to you, the differences are quite distinct, and I am
>reluctant to blur them in our terminology.  These issues are difficult enough
>without obfuscation and  imprecision.

In the past few messages alone I've seen five or more different terms
for this stuff (CA-certificate, subordinate and non-subordinate name
certificate, normal certificate, cross-certificate, inter-domain
certificate, etc.).  Is this really helping to clarify things?

The PKIX-CMP protocol is perfectly general:  *any* CA-a asks *any* CA-b
to create a certificate which includes CA-a's public verification key.
The policies and procedures, the operational paradigms, the business
decisions which limit this protocol to specific purposes for specific
environments (such as "only within this hierarchy", or "only between two
organizations", etc.) have no place in the PKIX specifications.
Limiting the definition of cross-certificate or of the
cross-certification protocol in the PKIX documents simply results in the
documents not being applicable to all environments in the Internet.

Does it really make sense to do this?

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

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 10 Feb 1998 11:59:18 -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: Marc Branchaud <[email-masked]>
Organization: Xcert Software Inc.
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

David P. Kemp wrote:
>
> > From: Marc Branchaud <[email-masked]>
> >
> > Unfortunately, there's not much syntactic difference between the two types
> > of certificates.  Rather, they're distinguished by what they represent.
>
> I disagree with both "Unfortunately" and "not much".
>
> I would rephrase the sentence as:
>
> Fortunately, there is no syntactic difference between the two types of:
>  1) certificate contents and path validation procedures, (PKIX part 1)
>  2) protocol messages used to retrieve them from a repository (PKIX part 2), or
>  3) protocol messages used to issue/revoke them (PKIX part 3).
>
> There are operational considerations that arise when the system
> architecture allows multiple issuers for a single entity (path
> discovery or path development, DSA/DH parameter inheritance,
> legal/policy agreement between CAs, population of directory attributes,
> etc).  But none of those differences have any effect on what client and
> server applications need to implement in order to be PKIX-compliant.
>
> In the unlikely event that PKIX accepts the work item of profiling
> (defining compliance requirements for) various trust models (strict
> heirarchy, web/mesh, list-of-trusted-CAs, etc), then a distinction
> between "subordinate" CA certification and "cross" CA certification
> will have some meaning in the PKIX context.  But even then, the
> certificate syntax and protocols are not affected by the difference.
> Or in other words, the mechanisms are policy independent and trust
> model independent.
>
> Wouldn't you agree that this is a fortunate situation?
>
> Dave Kemp

Perhaps "unfortunate" was an unfortunate word to use.  I do agree with you
that PKIX is barely affected by this issue.  This line of reasoning leads to
the conclusion that defining cross-certification is outside the current scope
of PKIX's work, and that the drafts should just talk about CA-certificates
(perhaps defining cross-certificate as a synonym, like Warwick suggested).

I'm as open to that as to any of the other suggestions.

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 10 Feb 1998 14:00: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

> From: Marc Branchaud <[email-masked]>
>
> Unfortunately, there's not much syntactic difference between the two types
> of certificates.  Rather, they're distinguished by what they represent.

I disagree with both "Unfortunately" and "not much".

I would rephrase the sentence as:

Fortunately, there is no syntactic difference between the two types of:
 1) certificate contents and path validation procedures, (PKIX part 1)
 2) protocol messages used to retrieve them from a repository (PKIX part 2), or
 3) protocol messages used to issue/revoke them (PKIX part 3).

There are operational considerations that arise when the system
architecture allows multiple issuers for a single entity (path
discovery or path development, DSA/DH parameter inheritance,
legal/policy agreement between CAs, population of directory attributes,
etc).  But none of those differences have any effect on what client and
server applications need to implement in order to be PKIX-compliant.

In the unlikely event that PKIX accepts the work item of profiling
(defining compliance requirements for) various trust models (strict
heirarchy, web/mesh, list-of-trusted-CAs, etc), then a distinction
between "subordinate" CA certification and "cross" CA certification
will have some meaning in the PKIX context.  But even then, the
certificate syntax and protocols are not affected by the difference.
Or in other words, the mechanisms are policy independent and trust
model independent.

Wouldn't you agree that this is a fortunate situation?

Dave Kemp

Approved-By:  Marc Branchaud <[email-masked]>
Date:         Tue, 10 Feb 1998 09:59:31 -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: Marc Branchaud <[email-masked]>
Organization: Xcert Software Inc.
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Moshe Litvin wrote:
>
> I disagree.
>
> There is no difference in the validation process between a cross
> certificate (whatever that means) and a "normal" CA certificate.
> When you have a certificate chain from your trusted CA to some
> certificate you don't need to know which certificate along the way is a
> cross certificate and which is a "normal" CA certificate.
>

The key phrase there is "When you have a certificate chain..."  One of the
problems in non-subordinate-CA-certification (yeesh) is path discovery
given transitive relationships:  You have to know the path before you can
decide whether to trust it.

For example, imagine three independent CAs with one-way
inter-certification:

        CAx --> CAy --> CAz

If user A is certified by CAz and wants to send a message to user B who
only trusts CAx's key, then A has to know to send the above chain to B.
The problem can be highlighted if you place the CAs in their own little
hierarchies (think of the vertical lines as downward-pointing arrows):

        CA1     CA3     CA5
         |       |       |
        CAx --> CAy --> CAz
         |       |       |
        CA2     CA4     CA6

How does a user certified by CA6 know to send the chain
CA1->CAx->CAy->CAz->CA6 to a user who only trusts CA1's key?  CA6's
subjects probably aren't even aware of the CAx->CAy->CAz chain.  Heck, CA6
and even CAz itself probably don't know about it either.

As Bob said when he proposed his new algorithm for validating a certificate
across two hierarchies, "transitive cross-certification seems altogether
too scary."

This is one reason why, I think, people feel the need to differentiate
between certificates for subordinate and non-subordinate CAs.
Unfortunately, there's not much syntactic difference between the two types
of certificates.  Rather, they're distinguished by what they represent.

> Off course there are different trust aspects when dealing with cross
> certification, but they  should be encoded in the certificate
> extensions. Anything outside the certificate is not signed and therefor
> no reliable.

It's difficult to see how encoding trust aspects in the certificates solves
the above problem.  Even if we could somehow encode the relationships the
certificates represent into the certificates themselves, it's hard to see
how the actual processing of the chains would be any different than what is
already defined.

This, I think, is why people feel there should not be any distinction.  The
debate will probably linger until somebody figures out how to handle
transitive trust.

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                       \/
 Chief PKI Architect                                  /\CERT SOFTWARE INC.
 [email-masked]        PKI References page:              www.xcert.com
 604-640-6210x227      www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+

Approved-By:  Moshe Litvin <[email-masked]>
Date:         Tue, 10 Feb 1998 17:58:19 +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: Moshe Litvin <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

I disagree.

There is no difference in the validation process between a cross
certificate (whatever that means) and a "normal" CA certificate.
When you have a certificate chain from your trusted CA to some
certificate you don't need to know which certificate along the way is a
cross certificate and which is a "normal" CA certificate.

Off course there are different trust aspects when dealing with cross
certification, but they  should be encoded in the certificate
extensions. Anything outside the certificate is not signed and therefor
no reliable.

Bob Jueneman wrote:
>
> Phil,
>
> I disagree.
>
> In addition to the semantic differences in the two trust domains (the signer and the relying party), there is a substantial syntactic difference in how the certificates are acquired and validated. That's enough difference to warrant two different names, 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]
>

-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

[email-masked]            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 10 Feb 1998 08:29:23 -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 Clarification
Comments: To: [email-masked]
To: [email-masked]
Status:

Phil,

I disagree.

In addition to the semantic differences in the two trust domains (the signer and the relying party), there is a substantial syntactic difference in how the certificates are acquired and validated. That's enough difference to warrant two different names, 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."

>>> Phillip Hallam-Baker <[email-masked]> 02/10 8:03 AM >>>
Michael Bungert wrote:

> IMO, a cross-certificate should clearly be distinguished from a CA
> certificate issued by a parent CA to a subordinated CA. I think that
> this distinction emphasizes the important property of the PKIX
> infrastructure that it does not rely on a global hierarchie of CAs
> but allows a web of independent trust domains which can be linked by
> 'real' cross-certificates.

Funnily enough I think the terms should be defined to be the same for
precisely the same reason.

The question is whether there is an objective, semantic difference
created when a certificate becomes a CA cert rather than a cross
cert. I have a sneaking feeling that some people believe that the
problems of inter-domain certification that are involved with
CA certificates somehow magically disappear if they are called
a 'cross-certificate'. In fact the only justification for introducing
a special class for subordinated CA certificates would be if the
problems of inter-domain certification disappeared in that special
case which they don't.

Unless there is a semantic difference defined between subordinate
name CA certs and non-subordinate name certs why introduce confusion?

The only good reason to call them cross certificates is that people
get cross talking about them.

                Phill

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Tue, 10 Feb 1998 08:36:54 -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 Clarification
Comments: To: [email-masked]
To: [email-masked]
Status:

>Hi all,
>
>this is my first message to the PKIX mailing list. I've followed the
>discussions on cross-certification and I'm astonished that the
>discussions are going to lead to the definition of cross-certificates
>as CA certificates.
>IMO, a cross-certificate should clearly be distinguished from a CA
>certificate issued by a parent CA to a subordinated CA. I think that
>this distinction emphasizes the important property of the PKIX
>infrastructure that it does not rely on a global hierarchie of CAs
>but allows a web of independent trust domains which can be linked by
>'real' cross-certificates.
>
>For me, a cross-certificate is a certificate issued by an issuer CA
>to another CA (or even another end entity) that is not subordinated
>to the issuer CA.
>
>Michael

Precisely.

As was probably demonstrated by Warwick's recent message, there appear to be political forces at work here that would like to institutionalize certain existing terminology and practices, whether or not they appear to make sense to the rest of the community.

To me, and apparently to you, the differences are quite distinct, and I am reluctant to blur them in our terminology.  These issues are difficult enough without obfuscation and  imprecision.

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."

Approved-By:  Phillip Hallam-Baker <[email-masked]>
Date:         Tue, 10 Feb 1998 10:03:29 -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] Cross Certification Clarification
To: [email-masked]
Status:

Michael Bungert wrote:

> IMO, a cross-certificate should clearly be distinguished from a CA
> certificate issued by a parent CA to a subordinated CA. I think that
> this distinction emphasizes the important property of the PKIX
> infrastructure that it does not rely on a global hierarchie of CAs
> but allows a web of independent trust domains which can be linked by
> 'real' cross-certificates.

Funnily enough I think the terms should be defined to be the same for
precisely the same reason.

The question is whether there is an objective, semantic difference
created when a certificate becomes a CA cert rather than a cross
cert. I have a sneaking feeling that some people believe that the
problems of inter-domain certification that are involved with
CA certificates somehow magically disappear if they are called
a 'cross-certificate'. In fact the only justification for introducing
a special class for subordinated CA certificates would be if the
problems of inter-domain certification disappeared in that special
case which they don't.

Unless there is a semantic difference defined between subordinate
name CA certs and non-subordinate name certs why introduce confusion?

The only good reason to call them cross certificates is that people
get cross talking about them.

                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 49 (????/----) (0001E82F)

Priority: Normal
Approved-By:  Michael Bungert <[email-masked]>
Date:         Tue, 10 Feb 1998 15:02:45 PST
Reply-To: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
Sender: "IETF X.509-based public key infrastructure mailing list" <[email-masked]>
From: Michael Bungert <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Hi all,

this is my first message to the PKIX mailing list. I've followed the
discussions on cross-certification and I'm astonished that the
discussions are going to lead to the definition of cross-certificates
as CA certificates.
IMO, a cross-certificate should clearly be distinguished from a CA
certificate issued by a parent CA to a subordinated CA. I think that
this distinction emphasizes the important property of the PKIX
infrastructure that it does not rely on a global hierarchie of CAs
but allows a web of independent trust domains which can be linked by
'real' cross-certificates.

For me, a cross-certificate is a certificate issued by an issuer CA
to another CA (or even another end entity) that is not subordinated
to the issuer CA.

Michael

In "[IETF-PKIX] Cross Certification Clarification", Warwick Ford wrote:

> Following on from the thread on Cross-Certification Terminology, Carlisle
> Adams, Tim Polk, and I have agreed on the following, which we believe to
> fairly reflect a concensus of the various views expressed.  In order to
> clarify use of the term "cross-certification" in the PKIX standards, we
> propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
> and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
> existing text in both cases.
>
> cross-certification:  A requesting CA requests issuance of a
> cross-certificate by a responding CA.  For the purposes of this standard, a
> cross-certificate (also known as CA-certificate) is considered to be any
> certificate issued by one CA for another CA's signing key pair (that is,
> for another CA's public verification key), regardless of the particular
> surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> organizational relationships between CAs.  Issuance of cross-certificates
> may be, but is not necessarily, mutual, i.e., two CAs may issue
> certificates for each other.
>
> Warwick
>
> ---------------------------------------------------------------------
> Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>    [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
> ---------------------------------------------------------------------
>

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

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Tue, 10 Feb 1998 12:39: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 Clarification
To: [email-masked]
Status:

Bob Jueneman wrote:

> My question to both the Australian mates and the Canadians (at least 2 out of 3,
> I assume, not being sure about Tim):

Are non-Autralian and Non-Canadian people allowed to comment ?   :-)

> Do you have a suggested term for repesenting the kind of certificate that is
> created unilaterally by one entity (normally a CA) which includes another
> entity's (normally another CA) public key, NOT necessarily as a result of a
> request by CA which is being certified?

You may call it a "cross-certificate" or an "inter-domain certificate",
whichever you prefer.

If you look carefully at the proposal I made yesterday the term "cross
certification" is no more used. "Cross-certificate request" used
instead. This means that a cross-certificate may be issued as the result
of a request, but may also be issued spontenaously by a CA.

> I don't object to the proposed terminology, but it leaves me without an
> agreed term for what I believe may be the most common occurance
> of what I would have otherwise called a cross-certificate.
>
> Bob
>
> >>> Charles Moore <[email-masked]> 02/08 2:43 PM >>>
>
> -----Original Message-----
> From: Warwick Ford <[email-masked]>
> To: [email-masked] <[email-masked]>
> Date: Monday, 9 February 1998 7:05
> Subject: [IETF-PKIX] Cross Certification Clarification
>
> :Following on from the thread on Cross-Certification Terminology, Carlisle
> :Adams, Tim Polk, and I have agreed on the following, which we believe to
> :fairly reflect a concensus of the various views expressed.  In order to
> :clarify use of the term "cross-certification" in the PKIX standards, we
> :propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
> :and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
> :existing text in both cases.
> :
> :cross-certification:  A requesting CA requests issuance of a
> :cross-certificate by a responding CA.  For the purposes of this standard, a
> :cross-certificate (also known as CA-certificate) is considered to be any
> :certificate issued by one CA for another CA's signing key pair (that is,
> :for another CA's public verification key), regardless of the particular
> :surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> :organizational relationships between CAs.  Issuance of cross-certificates
> :may be, but is not necessarily, mutual, i.e., two CAs may issue
> :certificates for each other.
>
> My three mates and myself, got together over a few beers and decided the
> following was the concesus of the group:
>
> cross-certification:  A requesting CA requests issuance of a
> cross-certificate by a responding CA.  For the purposes of this standard, a
> cross-certificate is considered to be any
> certificate issued by one CA for another CA's signing key pair (that is,
> for another CA's public verification key), regardless of the particular
> surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> organizational relationships between CAs.  Issuance of cross-certificates
> may be, but is not necessarily, mutual, i.e., two CAs may issue
> certificates for each other.
>
> PS: We also promise that we have not patented CA certificates ( but then who
> knows).

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Phillip Hallam-Baker <[email-masked]>
Date:         Mon, 9 Feb 1998 14:56: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: Phillip Hallam-Baker <[email-masked]>
Organization: VeriSign Inc.
Subject:      Re: [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Sharon Boeyen wrote:
>
> Warwick -  an unfortunate style choice, especially for a message from a
> WG co-chair. Can we please leave issues such as  what "Entrust" insists
> on, and whether or not "Entrust" needs to deal with "real" issues,  off
> the PKIX list.

I think it is more likely that Warwick intended the message to be
private
and did not notice that the reply-to field of messages is now set to
point to the list.

I hope this does not mean that Lynda Tripp has taken over as mailing
list
manager.

                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 48 (????/----) (0001E825)

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 9 Feb 1998 11:34: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] Cross Certification Clarification
Comments: To: [email-masked]
To: [email-masked]
Status:

My question to both the Australian mates and the Canadians (at least 2 out of 3,
I assume, not being sure about Tim):

Do you have a suggested term for repesenting the kind of certificate that is
created unilaterally by one entity (normally a CA) which includes another
entity's (normally another CA) public key, NOT necessarily as a result of a
request by CA which is being certified?

I don't object to the proposed terminology, but it leaves me without an
agreed term for what I believe may be the most common occurance
of what I would have otherwise called a cross-certificate.

Bob

>>> Charles Moore <[email-masked]> 02/08 2:43 PM >>>

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, 9 February 1998 7:05
Subject: [IETF-PKIX] Cross Certification Clarification

:Following on from the thread on Cross-Certification Terminology, Carlisle
:Adams, Tim Polk, and I have agreed on the following, which we believe to
:fairly reflect a concensus of the various views expressed.  In order to
:clarify use of the term "cross-certification" in the PKIX standards, we
:propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
:and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
:existing text in both cases.
:
:cross-certification:  A requesting CA requests issuance of a
:cross-certificate by a responding CA.  For the purposes of this standard, a
:cross-certificate (also known as CA-certificate) is considered to be any
:certificate issued by one CA for another CA's signing key pair (that is,
:for another CA's public verification key), regardless of the particular
:surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
:organizational relationships between CAs.  Issuance of cross-certificates
:may be, but is not necessarily, mutual, i.e., two CAs may issue
:certificates for each other.

My three mates and myself, got together over a few beers and decided the
following was the concesus of the group:

cross-certification:  A requesting CA requests issuance of a
cross-certificate by a responding CA.  For the purposes of this standard, a
cross-certificate is considered to be any
certificate issued by one CA for another CA's signing key pair (that is,
for another CA's public verification key), regardless of the particular
surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
organizational relationships between CAs.  Issuance of cross-certificates
may be, but is not necessarily, mutual, i.e., two CAs may issue
certificates for each other.

PS: We also promise that we have not patented CA certificates ( but then who
knows).

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Mon, 9 Feb 1998 12:56: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: Sharon Boeyen <[email-masked]>
Subject:      [IETF-PKIX] FW: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Warwick -  an unfortunate style choice, especially for a message from a
WG co-chair. Can we please leave issues such as  what "Entrust" insists
on, and whether or not "Entrust" needs to deal with "real" issues,  off
the PKIX list.

Putting that aside, can you provide some substantive clarification, for
the benefit of the WG participants on:
-  Specifically which aspects of the definition do you consider trivial
and
   why do you "not like" the definition?
-  What do you consider the "real" issues to be.

Thanks,
Sharon

------------------
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:  February 9, 1998 1:11 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross-certification
>
>Michael:
>
>
>I don't like the definition of cross-certification either, but it is
>better than not having a precise definition at all.  Entrust insisted on
>this trivial definition, since they do not face the need to deal with the
>real issues.  I want to continue working on the type of issue you raise
>but propose we do that under the topic "inter-domain certification".
>
>
>Warwick
>

Approved-By:  Santoni Adriano <[email-masked]>
Date:         Mon, 9 Feb 1998 18:01:29 +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] Cross-certification
To: [email-masked]
Status:

I agree with Peter. Either the "cross" it dropped, or it should make
some sense.
IMO, the concept of "crossing" something does not have anything to do
with the mere concept of issuing a certificate to a subject CA. Crossing
implies creating some sort of "bridge" for connecting two "worlds" or,
in practice, two domains (PKI's) X and Y which initially were born with
potentially different rules, for servicing potentially different
communities, in support of potentially different applications. At a
certain point in time, the two communities acknowledge the fact that the
need/want interoperability. Then, two comparable trust points (i.e. the
two (root) CA's of the two domains X and Y) examine the suitability of
establishing a parithetical trust relationship with each other, possibly
a unilateral one. Eventually, if all conditions are met, one of the two
CA's issues a cross-cert for the other CA, and possibly viceversa, with
the result that one or both of the two communities X and Y have the
possibility of automatically validate some (or all) types of
certificates issued by the other community's CA, and possibly viceversa.
That's my understanding of what cross-certification means. It is thus a
different and more complicated thing than issuing certificates for
subject CA's.
The inner organization of the two involved PKI's may not be relevant, in
principle, as regards the feasibility and suitability of
cross-certification.

  Adriano

> -----Messaggio originale-----
> Da:   Peter Sylvester [SMTP:[email-masked]]
> Inviato:      luned“ 9 febbraio 1998 17.14
> A:    [email-masked]
> Oggetto:      Re: [IETF-PKIX] Cross-certification
>
> >
> > I don't like the definition of cross-certification either, but it is
> > better than not having a precise definition at all.  Entrust
> insisted on
> > this trivial definition, since they do not face the need to deal
> with the
> > real issues.  I want to continue working on the type of issue you
> raise
> > but propose we do that under the topic "inter-domain certification".
> >
> Can you tell what do you mean by 'real issues'?
>
> Btw: IMHO the definition is not trivial but might be
> considered rather confusing, it mentions:
>
> "... regardless of the particular surrounding structure of CAs
>    (e.g., hierarchy or web) and regardless of the organizational
>    relationships between CAs."
>
> What is meant by SURROUNDING ? What is the meaning of 'structure
> of CAs'? what means 'regardless'? And what would be the purpose of
> that
> cert in this situation?
>
>
> Thanks in advance
> Peter Sylvester -- EdelWeb France

Approved-By:  Peter Sylvester <[email-masked]>
Date:         Mon, 9 Feb 1998 17:13:44 +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: Peter Sylvester <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

>
> I don't like the definition of cross-certification either, but it is
> better than not having a precise definition at all.  Entrust insisted on
> this trivial definition, since they do not face the need to deal with the
> real issues.  I want to continue working on the type of issue you raise
> but propose we do that under the topic "inter-domain certification".
>
Can you tell what do you mean by 'real issues'?

Btw: IMHO the definition is not trivial but might be
considered rather confusing, it mentions:

"... regardless of the particular surrounding structure of CAs
   (e.g., hierarchy or web) and regardless of the organizational
   relationships between CAs."

What is meant by SURROUNDING ? What is the meaning of 'structure
of CAs'? what means 'regardless'? And what would be the purpose of that
cert in this situation?

Thanks in advance
Peter Sylvester -- EdelWeb France

Approved-By:  "Arsenault, Al W." <[email-masked]>
Date:         Mon, 9 Feb 1998 11:02: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: "Arsenault, Al W." <[email-masked]>
Subject:      Re: [IETF-PKIX] Cross-certification
To: [email-masked]
Status:

Why should we address Michel's issues under the topic of "inter-domain
certification"?  To me, that's exactly what has always been meant by
"cross-certification", and I'd personally rather see those issues
addressed under that topic than introduce yet another term that will
only serve to confuse everybody.

                Al Arsenault

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

>----------
>From:  Warwick Ford[SMTP:[email-masked]]
>Sent:  Monday, February 09, 1998 1:11 PM
>To:    [email-masked]
>Subject:       Re: [IETF-PKIX] Cross-certification
>
>Michael:
>
>
>I don't like the definition of cross-certification either, but it is
>better than not having a precise definition at all.  Entrust insisted on
>this trivial definition, since they do not face the need to deal with the
>real issues.  I want to continue working on the type of issue you raise
>but propose we do that under the topic "inter-domain certification".
>
>
>Warwick
>
>
>
>At 10:40 AM 2/9/98 +0100, Michel Beretta wrote:
>
>>>>>
>
><excerpt>Warvick,
>
>
>I found this definition you made in the ietf-pkix mailing list.
>
>
>-----------------------------------------------------------------------
>
>cross-certification:  A requesting CA requests issuance of a
>
>cross-certificate by a responding CA.  For the purposes of this standard,
>a
>
>cross-certificate (also known as CA-certificate) is considered to be any
>
>certificate issued by one CA for another CA's signing key pair (that is,
>
>for another CA's public verification key), regardless of the particular
>
>surrounding structure of CAs (e.g., hierarchy or web) and regardless of
>the
>
>organizational relationships between CAs.  Issuance of cross-certificates
>
>may be, but is not necessarily, mutual, i.e., two CAs may issue
>
>certificates for each other.
>
>--------------------------------------------------------------------
>
>
>This is very clear, and I understand from this definition that a
>cross-certificate is no more than a non-self-signed CA-Certificate.
>
>
>In my previous understanding, cross-certification was dealing with
>sharing trust between two independant security domains.
>
>
>Let's imagine two independant CA hierarchies, one CA from hierarchy (1)
>wants to be trusted by another CA from another hierachy (2). It will
>request a certificated from this other CA (2) and have a new certificate,
>different from the first it was given in his first hierarchy.
>
>- Don't you think this kind of certificate has a special meaning?
>
>- <bold>How would you call such certificates </bold>which allow a CA to
>be trusted in several hierarchy/web?
>
>- Does CMP address the issue of managing multiple certificates for each
>CA?
>
>
>I know this is not a "natural" way of thinking, but I wonder if the big
>issue to manage "cross-security domain managemnt " is to forget the
>hierarchy certification model and allow CAs to have multiple Parent-CA,
>
>and be able to manage that.
>
>Does it make sense?
>
>
>Thank you for your feed back.
>
>Michel.
>
>
>
>
>
>
>--
>
>-------------------------------------------------------------------
>
>Michel BERETTA
>
>HEWLETT PACKARD - Internet Communication Appliances Division
>
>5,avenue Raymond Chanas 38053  GRENOBLE Cedex 9 FRANCE
>
>Phone: +33-(0)4.76.14.40.83 - FAX: +33-(0)4.76.14.12.86
>
><<mailto:[email-masked]>mailto:[email-masked] -
><<http://icad.grenoble.hp.com>http://icad.grenoble.hp.com
>
>-------------------------------------------------------------------
>
>
>
></excerpt>
>
>
>
>
>---------------------------------------------------------------------
>
>Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140
>
>   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716
>
>---------------------------------------------------------------------
>

Approved-By:  Warwick Ford <[email-masked]>
Date:         Mon, 9 Feb 1998 10:11:23 -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
Comments: To: [email-masked]
To: [email-masked]
Status:

<x-rich>Michael:

I don't like the definition of cross-certification either, but it is
better than not having a precise definition at all.  Entrust insisted on
this trivial definition, since they do not face the need to deal with the
real issues.  I want to continue working on the type of issue you raise
but propose we do that under the topic "inter-domain certification".

Warwick

At 10:40 AM 2/9/98 +0100, Michel Beretta wrote:

>>>>

<excerpt>Warvick,

I found this definition you made in the ietf-pkix mailing list.

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

cross-certification:  A requesting CA requests issuance of a

cross-certificate by a responding CA.  For the purposes of this standard,
a

cross-certificate (also known as CA-certificate) is considered to be any

certificate issued by one CA for another CA's signing key pair (that is,

for another CA's public verification key), regardless of the particular

surrounding structure of CAs (e.g., hierarchy or web) and regardless of
the

organizational relationships between CAs.  Issuance of cross-certificates

may be, but is not necessarily, mutual, i.e., two CAs may issue

certificates for each other.

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

This is very clear, and I understand from this definition that a
cross-certificate is no more than a non-self-signed CA-Certificate.

In my previous understanding, cross-certification was dealing with
sharing trust between two independant security domains.

Let's imagine two independant CA hierarchies, one CA from hierarchy (1)
wants to be trusted by another CA from another hierachy (2). It will
request a certificated from this other CA (2) and have a new certificate,
different from the first it was given in his first hierarchy.

- Don't you think this kind of certificate has a special meaning?

- <bold>How would you call such certificates </bold>which allow a CA to
be trusted in several hierarchy/web?

- Does CMP address the issue of managing multiple certificates for each
CA?

I know this is not a "natural" way of thinking, but I wonder if the big
issue to manage "cross-security domain managemnt " is to forget the
hierarchy certification model and allow CAs to have multiple Parent-CA,

and be able to manage that.

Does it make sense?

Thank you for your feed back.

Michel.

--

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

Michel BERETTA

HEWLETT PACKARD - Internet Communication Appliances Division

5,avenue Raymond Chanas 38053  GRENOBLE Cedex 9 FRANCE

Phone: +33-(0)4.76.14.40.83 - FAX: +33-(0)4.76.14.12.86

<<mailto:[email-masked]>mailto:[email-masked] -
<<http://icad.grenoble.hp.com>http://icad.grenoble.hp.com

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

</excerpt>

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

Warwick Ford, VeriSign, Inc., One Alewife Center, Cambridge, MA 02140

   [email-masked]; Tel: (617)492 2816 x225; Fax: (617)661 0716

---------------------------------------------------------------------
</x-rich>

Approved-By:  Denis Pinkas <[email-masked]>
Date:         Mon, 9 Feb 1998 10:54:00 -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 Clarification
To: [email-masked]
Status:

Warwick Ford wrote:

> Following on from the thread on Cross-Certification Terminology, Carlisle
> Adams, Tim Polk, and I have agreed on the following, which we believe to
> fairly reflect a concensus of the various views expressed.  In order to
> clarify use of the term "cross-certification" in the PKIX standards, we
> propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
> and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
> existing text in both cases.

Thanks for providing this input.

> cross-certification:  A requesting CA requests issuance of a
> cross-certificate by a responding CA.

Do we really need to use (and thus define) that term ? However we surely
need to say what is a "cross-certificate" versus a "CA-certificate". I
would prefer to use "cross-certificate request" instead, keep the same
definition and thus have :

"Cross-certificate request: A requesting CA requests issuance of a
cross-certificate by a responding CA."

> For the purposes of this standard, a cross-certificate (also
> known as CA-certificate) is considered to be any certificate

So, the option that is presented is the case where a cross-certificate
is fully equivalent to a CA-certificate.

It is difficult to say where the consensus was/is, but I had the feeling
that there existed a difference between the two notions, but that we did
not reached an agreement on the exact wording.

In other words, a CA-certificate applies to any kind of relationship
between CAs, whereas a cross-certificate only applies when, at the time
of the issuance of the CA-certificate, there is no particular
surrounding structure for the two CAs (e.g., hierarchy or web) nor
particular organizational relationships between the two CAs.

Whether a "cross-certificate request" is being made or a "CA-certificate
request" is being made, the protocol to be used is the same.

> issued by one CA for another CA's signing key pair (that is,
> for another CA's public verification key), regardless of the particular
> surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
> organizational relationships between CAs.  Issuance of cross-certificates
> may be, but is not necessarily, mutual, i.e., two CAs may issue
> certificates for each other.

  cross-certificates for each other.

Denis

--
 ***  Please note that the E-mail address has changed ! Update it.  ***
      Denis Pinkas     Bull S.A.          mailto:[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

Approved-By:  Charles Moore <[email-masked]>
Date:         Mon, 9 Feb 1998 07:43:30 +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 Clarification
To: [email-masked]
Status:

-----Original Message-----
From: Warwick Ford <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, 9 February 1998 7:05
Subject: [IETF-PKIX] Cross Certification Clarification

:Following on from the thread on Cross-Certification Terminology, Carlisle
:Adams, Tim Polk, and I have agreed on the following, which we believe to
:fairly reflect a concensus of the various views expressed.  In order to
:clarify use of the term "cross-certification" in the PKIX standards, we
:propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
:and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
:existing text in both cases.
:
:cross-certification:  A requesting CA requests issuance of a
:cross-certificate by a responding CA.  For the purposes of this standard, a
:cross-certificate (also known as CA-certificate) is considered to be any
:certificate issued by one CA for another CA's signing key pair (that is,
:for another CA's public verification key), regardless of the particular
:surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
:organizational relationships between CAs.  Issuance of cross-certificates
:may be, but is not necessarily, mutual, i.e., two CAs may issue
:certificates for each other.

My three mates and myself, got together over a few beers and decided the
following was the concesus of the group:

cross-certification:  A requesting CA requests issuance of a
cross-certificate by a responding CA.  For the purposes of this standard, a
cross-certificate is considered to be any
certificate issued by one CA for another CA's signing key pair (that is,
for another CA's public verification key), regardless of the particular
surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
organizational relationships between CAs.  Issuance of cross-certificates
may be, but is not necessarily, mutual, i.e., two CAs may issue
certificates for each other.

PS: We also promise that we have not patented CA certificates ( but then who
knows).

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

Attachment converted: Lutefisk:smime.p7s 47 (????/----) (0001E7BF)

Approved-By:  Warwick Ford <[email-masked]>
Date:         Sun, 8 Feb 1998 15:57: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: Warwick Ford <[email-masked]>
Subject:      [IETF-PKIX] Cross Certification Clarification
To: [email-masked]
Status:

Following on from the thread on Cross-Certification Terminology, Carlisle
Adams, Tim Polk, and I have agreed on the following, which we believe to
fairly reflect a concensus of the various views expressed.  In order to
clarify use of the term "cross-certification" in the PKIX standards, we
propose adoption of the following text in both PKIX Part I (Sec 3.5 (g))
and PKIX CMP (Sec. 1.3 PKI Management Operations, 3.5), to replace the
existing text in both cases.

cross-certification:  A requesting CA requests issuance of a
cross-certificate by a responding CA.  For the purposes of this standard, a
cross-certificate (also known as CA-certificate) is considered to be any
certificate issued by one CA for another CA's signing key pair (that is,
for another CA's public verification key), regardless of the particular
surrounding structure of CAs (e.g., hierarchy or web) and regardless of the
organizational relationships between CAs.  Issuance of cross-certificates
may be, but is not necessarily, mutual, i.e., two CAs may issue
certificates for each other.

Warwick

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

Approved-By:  Robert Moskowitz <[email-masked]>
Date:         Fri, 6 Feb 1998 13:35:50 -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: Robert Moskowitz <[email-masked]>
Subject:      [IETF-PKIX] Joint X.509 / IPsec discussion
Comments: To: [email-masked]
To: [email-masked]
Status:

This has been long overdue, and a long time coming, but I am arranging a
meeting for CA software companies and IPsec technologists to discuss the
issues surrounding use of X.509 certificates by IPsec and the interaction
of IPsec products with CA software products.

We are planning this meeting for Feb 19th at BBN/GTE's facility in the
Boston area.  Plan on a full day meeting.  I suspect that around 12 CA
software companies, averaging 2 people would attend with around 6 - 10
IPsec specialists (space planing for Pat Cain).

The goal of this meeting would be to establish the X.509/CA guidelines so
that CA software vendors can attend the IPsec workshop the week of March
2nd in Raleigh NC to address product interoperabilty.

This meeting will also have as its goal to investigate the realm of CA
software certification, ie is the software delivering the security services
as specified.

An agenda will follow.

Robert Moskowitz
ICSA
Security Interest EMail: [email-masked]

Approved-By:  "Phillip H. Griffin" <[email-masked]>
Date:         Wed, 4 Feb 1998 21:26:53 -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] User Notice fields (short line lengths.)
To: [email-masked]
Status:

Bob Jueneman wrote:
>
snip
>
> ---
>
> I've been trying to think about how to implement both CA and user
> notices in a multilingual environment.
>
> And the more I think about it, the more I think the current
> mechanism is pretty badly broken,.
>
> In <draft-ietf-pkix-part1-06.txt>, paragraph 4.2.1.5 Certificate
> Policies, UserNotice is defined as
>
> UserNotice ::= SEQUENCE {
>   noticeRef     NoticeReference OPTIONAL,
>   explicitText   DisplayText OPTIONAL}
>
> As I interpret that, the CA is free to include as many
> noticeRefs or explictText sequences as might be desired
> within the certificate.
>
> However, the noticeRef merely names an organization (in
> IA5String, which obviously limits the kinds of organizations
> that can be named to those with European language names) and
> provides a message number.
>

The IA5String type will only support *some* European names,
not accented characters or characters with umlats. It will
allow all of the ASCII control characters, such as ESC and
DEL, to appear in a value of the type.

> How the application is supposed to know where within an organization
> that message number is defined is a mystery. Presumably it is recorded s
> omewhere on Vogon, and the location communicated by mental telepathy?
> Why wasn't the obvious approach -- a URL to the message -- used for
> this notice field?
>
> The text says that "In a typical implementation, the application software
> will have a notice file for CertsRUs; the application will extract the notice
> file from the file and display it."
>
> I believe that would be very dangerous from a liability standpoint.
>
> If that sentence means that the application statically _contains_ the
> message file, that raises the extremely serious question of what happens
> if the CA changes the message, yet the application is still displaying the
> old one. From a legal standpoint, who is to blame if there is a
> misunderstanding as to the terms and conditions under which the
> certificate was issued?
>
> The text goes on to say that "Messages may be multilingual, allowing
> the software to select the particular language message for its own environment."
>

The text also state that explicitText "is a string with a
maximum size of 200 characters", but there is no size
constraint on type DisplayText (which would be easy to
do if it were a parameterized type like the X.5* type
DirectoryString{}). This would require 400 octets for
a BMPString, but only allow 200 for VisibleString.

> That sounds like a pretty good trick as well.  Normally, for such applications,
> messages need to be multi-cultural, and not just multi-lingual.  In addition to
> minor spelling variations between American English and British (UK) English,
> there are differences in wording, different legal systems, and a whole host of
> other nuance differences to contend with. Consider the differences between
> American English, Indian English, Australian English, and even Canadian
> English (don't ask for a napkin in Nova Scotia when you mean a serviette),
> and that is presumably one language with (in most cases) a common code page.
>
> How is the application supposed to figure out which of the message variants
> to use?  Is it intended that along with the static definition of the message
> content (acquired who knows how), the application would also acquire 128
> variants of a single message and somehow guess which message is supposed
> to be delivered to which user in a particular country? This gets more and
> more interesting.
>
> The definition of noticeNumbers is SEQUENCE OF INTEGER. Are those
> intended to be different notices, each with built-in variants for different
> languages, or are the noticeNumbers themselves supposed to be different
> for each language or cultural variant?

Since the SEQUENCE OF in noticeNumbers is not constrained,
it appears that it might be null, containing zero integers.
This may cause problems. A size constraint here, 1..MAX,
might be helpful.

>
> In the same manner, I conclude that the UserNotice field can contain multiple
> explictText fields, each of which is represented in either VisibleString or BMPString.
> Wonderful.  Now I can encode messages in 120 languages, most of which are
> represented in BMPString, and display them all to the poor user, who watches
> page after page scroll by in languages he can't read.
>
> The text also states that "If both the noticeRef and explicitText options are
> included ion the one qualifier and if the application software can locate the
> notice text indicated by the noticeRef option then that text should be
> displayed; otherwise, the explicitText string should be displayed."
>
> That seems to be broken as well. Since the definition allows a SEQUENCE
> (not CHOICE) of two optional forms, noticeRef and explicitText, any
> assumption that a pair of noticeRef and explictText fields are supposed to
> correspond seems unwarranted.  What is supposed to happen if there is
> one noticeRef and two explicitText fields?
>
> In addition to these problems, the entire concept seems to be rather
> CA-centric, and ignores the possibility of a SUBSCRIBER who wishes
> to include some caveats or limitations of use on his certificate to protect
> himself and his organization, rather than just protecting the CA's interests.
>
> Obviously application software is not going to have a built-in list of
> numbered organizational messages (joke numbers) for all possible users.
> So either a URL or an explicit text is the only possible choice.
>
> Since in many cases all of the user's within a given organization would
> have the same userNotice associated with their certificates, a URL would
> seem to be most appropriate.
>
> Finally, although we had discussed the need for a message digest which
>  would apply to any message which is incorporated by reference into a
> certificate (so that the CA or the user can't change the message content
> after the certificate is issued without the change being detected), the
> noticeRef fields do not include such a provision.
>
> I hesitate to propose new ASN.1 definitions before I have heard others
> express an opinion, but I am thinking about something along the following lines:
>
> 1.  NoticeReference should probably be something like:
>
> NoticeReference ::= SEQUENCE {
>    noticeUriBase  IA5String,
>    SEQUENCE {
>          noticeCountry  NoticeCountryCode
>              -- somebody pick a format, maybe the currency code,
>           noticeFilename  IA5String
>               --  file name to be appended to the noticeUriBase
>               --  to form a complete URI for the matching country code}
>           noticeMessageDigest  MessageDigestFormat }
>
> 2.  DisplayText (referenced by explicitText) should be defined similarly:
>
> DisplayText ::= SEQUENCE {
>    displayStringType  DisplayStringType,
>    displayCountry  NoticeCountryCode }
>
> 3.  Alternatively, we might leave the country code out of the notice and
> display fields and include them in the UserNotice field instead, something like:
>
> UserNotice  ::= SEQUENCE {
>      CHOICE {
>           noticeRef  NoticeReference
>           explicitText  DisplayText }
>      countryCode  CountryCode }
>
> NoticeReference  ::= SEQUENCE {
>       noticeUri                      IA5String, -- a complete URI
>       noticeMessageDigest  MessageDigestFormat }
>

Shouldn't URIs contain only the non-control characters in
VisibleString?

> Thoughts?
>
> 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."

--
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:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Feb 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: Bob Jueneman <[email-masked]>
Subject:      [IETF-PKIX] User Notice fields (short line lengths.)
To: [email-masked]
Status:

My sincere apologies to those who might not have been able to read
my previous message on the same subject.

It appears that the list server operated by Tandem is erroneously
converting MIME message prepared in quotable-string format to
7-bit format, and in the process stripping off the soft carriage returns
which GroupWise inserts.  As a result, anyone without a MIME reader
would see very long lines, and anyone with a M<IME reader which does
not line wrap would also see long lines.  This is very frustrating.

In addition, it appears that either our gateway or the Tandem list server
is converting messages intended to be sent in non-MIME, simple SMTP
format to MIME format, although I'm not quite as certain about that.  This
message is being prepared and address in non-MIME format -- we'll see
how it shows up.

Anyway, here is the original message, with manually inserted carriage returns.
I hope this is readable.

---

I've been trying to think about how to implement both CA and user notices
in a multilingual environment.

And the more I think about it, the more I think the current mechanism is pretty
badly broken,.

In <draft-ietf-pkix-part1-06.txt>, paragraph 4.2.1.5 Certificate Policies,
UserNotice is defined as

UserNotice ::= SEQUENCE {
  noticeRef     NoticeReference OPTIONAL,
  explicitText   DisplayText OPTIONAL}

As I interpret that, the CA is free to include as many noticeRefs or explictText
sequences as might be desired within the certificate.

However, the noticeRef merely names an organization (in IA5String, which
obviously limits the kinds of organizations that can be named to those with
European language names) and provides a message number.

How the application is supposed to know where within an organization
that message number is defined is a mystery. Presumably it is recorded s
omewhere on Vogon, and the location communicated by mental telepathy?
Why wasn't the obvious approach -- a URL to the message -- used for
this notice field?

The text says that "In a typical implementation, the application software
will have a notice file for CertsRUs; the application will extract the notice
file from the file and display it."

I believe that would be very dangerous from a liability standpoint.

If that sentence means that the application statically _contains_ the
message file, that raises the extremely serious question of what happens
if the CA changes the message, yet the application is still displaying the
old one. From a legal standpoint, who is to blame if there is a
misunderstanding as to the terms and conditions under which the
certificate was issued?

The text goes on to say that "Messages may be multilingual, allowing
the software to select the particular language message for its own environment."

That sounds like a pretty good trick as well.  Normally, for such applications,
messages need to be multi-cultural, and not just multi-lingual.  In addition to
minor spelling variations between American English and British (UK) English,
there are differences in wording, different legal systems, and a whole host of
other nuance differences to contend with. Consider the differences between
American English, Indian English, Australian English, and even Canadian
English (don't ask for a napkin in Nova Scotia when you mean a serviette),
and that is presumably one language with (in most cases) a common code page.

How is the application supposed to figure out which of the message variants
to use?  Is it intended that along with the static definition of the message
content (acquired who knows how), the application would also acquire 128
variants of a single message and somehow guess which message is supposed
to be delivered to which user in a particular country? This gets more and
more interesting.

The definition of noticeNumbers is SEQUENCE OF INTEGER. Are those
intended to be different notices, each with built-in variants for different
languages, or are the noticeNumbers themselves supposed to be different
for each language or cultural variant?

In the same manner, I conclude that the UserNotice field can contain multiple
explictText fields, each of which is represented in either VisibleString or BMPString.
Wonderful.  Now I can encode messages in 120 languages, most of which are
represented in BMPString, and display them all to the poor user, who watches
page after page scroll by in languages he can't read.

The text also states that "If both the noticeRef and explicitText options are
included ion the one qualifier and if the application software can locate the
notice text indicated by the noticeRef option then that text should be
displayed; otherwise, the explicitText string should be displayed."

That seems to be broken as well. Since the definition allows a SEQUENCE
(not CHOICE) of two optional forms, noticeRef and explicitText, any
assumption that a pair of noticeRef and explictText fields are supposed to
correspond seems unwarranted.  What is supposed to happen if there is
one noticeRef and two explicitText fields?

In addition to these problems, the entire concept seems to be rather
CA-centric, and ignores the possibility of a SUBSCRIBER who wishes
to include some caveats or limitations of use on his certificate to protect
himself and his organization, rather than just protecting the CA's interests.

Obviously application software is not going to have a built-in list of
numbered organizational messages (joke numbers) for all possible users.
So either a URL or an explicit text is the only possible choice.

Since in many cases all of the user's within a given organization would
have the same userNotice associated with their certificates, a URL would
seem to be most appropriate.

Finally, although we had discussed the need for a message digest which
 would apply to any message which is incorporated by reference into a
certificate (so that the CA or the user can't change the message content
after the certificate is issued without the change being detected), the
noticeRef fields do not include such a provision.

I hesitate to propose new ASN.1 definitions before I have heard others
express an opinion, but I am thinking about something along the following lines:

1.  NoticeReference should probably be something like:

NoticeReference ::= SEQUENCE {
   noticeUriBase  IA5String,
   SEQUENCE {
         noticeCountry  NoticeCountryCode
             -- somebody pick a format, maybe the currency code,
          noticeFilename  IA5String
              --  file name to be appended to the noticeUriBase
              --  to form a complete URI for the matching country code}
          noticeMessageDigest  MessageDigestFormat }

2.  DisplayText (referenced by explicitText) should be defined similarly:

DisplayText ::= SEQUENCE {
   displayStringType  DisplayStringType,
   displayCountry  NoticeCountryCode }

3.  Alternatively, we might leave the country code out of the notice and
display fields and include them in the UserNotice field instead, something like:

UserNotice  ::= SEQUENCE {
     CHOICE {
          noticeRef  NoticeReference
          explicitText  DisplayText }
     countryCode  CountryCode }

NoticeReference  ::= SEQUENCE {
      noticeUri                      IA5String, -- a complete URI
      noticeMessageDigest  MessageDigestFormat }

Thoughts?

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."

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Wed, 4 Feb 1998 10:53: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:      [IETF-PKIX] User Notice fields
To: [email-masked]
Status:

I've been trying to think about how to implement both CA and user notices in a multilingual environment.

And the more I think about it, the more I think the current mechanism is pretty badly broken,.

In <draft-ietf-pkix-part1-06.txt>, paragraph 4.2.1.5 Certificate Policies, UserNotice is defined as

UserNotice ::= SEQUENCE {
  noticeRef     NoticeReference OPTIONAL,
  explicitText   DisplayText OPTIONAL}

As I interpret that, the CA is free to include as many noticeRefs or explictText sequences as might be desired within the certificate.

However, the noticeRef merely names an organization (in IA5String, which obviously limits the kinds of organizations that can be named to those with European language names) and provides a message number.

How the application is supposed to know where within an organization that message number is defined is a mystery. Presumably it is recorded somewhere on Vogon, and the location communicated by mental telepathy?  Why wasn't the obvious approach -- a URL to the message -- used for this notice field?

The text says that "In a typical implementation, the application software will have a notice file for CertsRUs; the application will extract the notice file from the file and display it."

I believe that would be very dangerous from a liability standpoint.

If that sentence means that the application statically _contains_ the message file, that raises the extremely serious question of what happens if the CA changes the message, yet the application is still displaying the old one. From a legal standpoint, who is to blame if there is a misunderstanding as to the terms and conditions under which the certificate was issued?

The text goes on to say that "Messages may be multilingual, allowing the software to select the particular language message for its own environment."

That sounds like a pretty good trick as well.  Normally, for such applications, messages need to be multi-cultural, and not just multi-lingual.  In addition to minor spelling variations between American English and British (UK) English, there are differences in wording, different legal systems, and a whole host of other nuance differences to contend with. Consider the differences between American English, Indian English, Australian English, and even Canadian English (don't ask for a napkin in Nova Scotia when you mean a serviette), and that is presumably one language with (in most cases) a common code page.

How is the application supposed to figure out which of the message variants to use?  Is it intended that along with the static definition of the message content (acquired who knows how), the application would also acquire 128 variants of a single message and somehow guess which message is supposed to be delivered to which user in a particular country? This gets more and more interesting.

The definition of noticeNumbers is SEQUENCE OF INTEGER. Are those intended to be different notices, each with built-in variants for different languages, or are the noticeNumbers themselves supposed to be different for each language or cultural variant?

In the same manner, I conclude that the UserNotice field can contain multiple explictText fields, each of which is represented in either VisibleString or BMPString.  Wonderful.  Now I can encode messages in 120 languages, most of which are represented in BMPString, and display them all to the poor user, who watches page after page scroll by in languages he can't read.

The text also states that "If both the noticeRef and explicitText options are included ion the one qualifier and if the application software can locate the notice text indicated by the noticeRef option then that text should be displayed; otherwise, the explicitText string should be displayed."

That seems to be broken as well. Since the definition allows a SEQUENCE (not CHOICE) of two optional forms, noticeRef and explicitText, any assumption that a pair of noticeRef and explictText fields are supposed to correspond seems unwarranted.  What is supposed to happen if there is one noticeRef and two explicitText fields?

In addition to these problems, the entire concept seems to be rather CA-centric, and ignores the possibility of a SUBSCRIBER who wishes to include some caveats or limitations of use on his certificate to protect himself and his organization, rather than just protecting the CA's interests.

Obviously application software is not going to have a built-in list of numbered organizational messages (joke numbers) for all possible users. So either a URL or an explicit text is the only possible choice.

Since in many cases all of the user's within a given organization would have the same userNotice associated with their certificates, a URL would seem to be most appropriate.

Finally, although we had discussed the need for a message digest which would apply to any message which is incorporated by reference into a certificate (so that the CA or the user can't change the message content after the certificate is issued without the change being detected), the noticeRef fields do not include such a provision.

I hesitate to propose new ASN.1 definitions before I have heard others express an opinion, but I am thinking about something along the following lines:

1.  NoticeReference should probably be something like:

NoticeReference ::= SEQUENCE {
   noticeUriBase  IA5String,
   SEQUENCE {
         noticeCountry  NoticeCountryCode
             -- somebody pick a format, maybe the currency code,
          noticeFilename  IA5String
              --  file name to be appended to the noticeUriBase
              --  to form a complete URI for the matching country code}
          noticeMessageDigest  MessageDigestFormat }

2.  DisplayText (referenced by explicitText) should be defined similarly:

DisplayText ::= SEQUENCE {
   displayStringType  DisplayStringType,
   displayCountry  NoticeCountryCode }

3.  Alternatively, we might leave the country code out of the notice and display fields and include them in the UserNotice field instead, something like:

UserNotice  ::= SEQUENCE {
     CHOICE {
          noticeRef  NoticeReference
          explicitText  DisplayText }
     countryCode  CountryCode }

NoticeReference  ::= SEQUENCE {
      noticeUri                      IA5String, -- a complete URI
      noticeMessageDigest  MessageDigestFormat }

Thoughts?

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."

Approved-By:  Judie Mulholland <[email-masked]>
Date:         Wed, 4 Feb 1998 10:09:17 -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: Judie Mulholland <[email-masked]>
Subject:      [IETF-PKIX] announcing E-CARM, a new mailing list
To: [email-masked]
Status:

Our apologies for any cross posting, but we are anxious to get the word
out asap :)

----------------------------------------------------------------------
              Announcing the creation of a new mailing list:

             ***E-COMMERCE AND RIGHTS MANAGEMENT (E-CARM)***

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

This mailing list has been established to foster and support an on-line
discussion forum where we can:

        * debate (non) technical, administrative and managerial issues
          pertaining to: secure transactions, competing rights management
          models (e.g. ECMS, PICS, certificates, FIRM, etc.), evolving
          standards, supporting technologies and other approaches for
          enabling electronic commerce;
        * inform each other about upcoming conferences, workshops, etc.
        * point to online papers, resources/links, new apps, web
          sites, etc.
        * identify the critical factors relevant to design, development
          and implementation of a rights management infrastructure;
        * raise questions, share problems, relate concerns;
        * share success/horror stories;
        * and much, much more ...

If you are interested in subscribing to this list, please send a message
to:

<[email-masked]>

with the following line in body of the message (NOT the subject):

subscribe e-carm "FirstName LastName" (without the quotation marks)

and after you are notified that you have been subbed, we would ask that
you send a short note to the list, briefly introducing yourself and your
interests in e-commerce and rights management so that we can begin to come
together as a community of shared interest(s).

E-CARM is intended to be a member-driven, open, collaborative mailing
list. However, its success in creating a viable on-line forum will
depend on individual contributions. As a step in this direction, we
encourage you to share this announcement with other mailing lists or
anyone who may be interested in getting involved.

Looking forward to seeing all of you on E-CARM,

Judie Mulholland
Rajiv Kaushik

List Moderators

Approved-By:  "Miklos, Sue A." <[email-masked]>
Date:         Tue, 3 Feb 1998 14:00:58 -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: "Miklos, Sue A." <[email-masked]>
Subject:      Re: [IETF-PKIX] Attribute Cert examples?
To: [email-masked]
Status:

Dave... did you find anything?  The ANSI X9F (certco?) may be an
answer...

Sandi

>----------
>From:  David P. Kemp[SMTP:[email-masked]]
>Sent:  Monday, February 02, 1998 1:23 PM
>To:    [email-masked]
>Subject:       [IETF-PKIX] Attribute Cert examples?
>
>Does anyone have or know of a publicly-available example of an X.509
>Attribute Certificate?  I'm looking for test data to independently
>validate some parsing software, and for an instance to include in the
>PKIX Part 1 examples appendix.
>
>Thanks,
>  Dave Kemp
>

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Tue, 3 Feb 1998 13:27: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: Sharon Boeyen <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: Attributes clarification in 509
To: [email-masked]
Status:

John,

You're absolutely correct and thanks for catching that. During last
week's meeting Warwick mentioned the directions as well and I said I'd
double check whether I had them correct or not. I'll revise the text
before ballot as follows:

"Clause 8
(Add the following text immediately following the asn.1 for
certificatePair)

The cACertificate attribute, held in a particular CA's directory entry,
may be used to store self-signed certificates.

Note - The cACertificate attribute should not be confused with the
defined term CA-certificate.

The crossCertificatePair attribute, held in a particular CA's directory
entry,  may be used to store certificates issued by this CA to other
CAs, as well as certificates issued for this CA by other CAs. Values
held in the forward element are certificates issued for this CA by other
CAs, while values in the reverse element are certificates issued by this
CA for other CAs. Either certificate, if present,  may be used in
building certificate paths for validation and may be published in the
directory entries of either CA or both. "

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

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

>

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Tue, 3 Feb 1998 10:02: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: "David P. Kemp" <[email-masked]>
Subject:      Re: [IETF-PKIX] Tag type for rfc822name
Comments: To: [email-masked]
To: [email-masked]
Status:

> From: Nilsson Hans <[email-masked]>

> The question is: Should it use IMPLICIT or EXPLICIT tags?
> Below are two extracts from PKIX-1, which uses IMLICIT in one example
> and EXPLICIT in another.
>
> Which way has it been implemented in existing S/MIME products? Can they
> handle both IMPLICIT and EXPLICIT coding of rfc822Name?

There can be only one correct encoding, otherwise DER would not be unique.

> Here are the examples from PKIX-1:
> ------------------------ IMPLICIT TAG:
> ------------------------------------------
> 0606 a3 1d         29: . . [3]
> 0608 30 1b         27: . . . SEQUENCE
> 0610 30 19         25: . . . . SEQUENCE
> 0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
> 0617 04 12         18: . . . . . OCTET STRING
>                      : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
>                      : 6f 76
>
> 0000 30 10         16: SEQUENCE
> 0002 81 0e         14: . [1]
>                      : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
> Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
> note is taken from PKIX-1!)

When I wrote that note in PKIX-1, I intended to call attention to the
fact that there appeared to be an error in the software that generated
that example.  I wasn't confident enough to phrase it as a definite
statement that THIS EXAMPLE IS WRONG, but intended to warn developers
that there might be a problem.

I am confident now that GeneralName must be encoded using EXPLICIT TAGS,
and that the above example is indeed incorrect.

> I have consulted different experts and of course received different
> reponses:
>
> Response A:
>     [must be IMPLICIT]
>
> Response B:
>     [must be EXPLICIT]
>
> Response C:
>     [rfc822Name is IMPLICIT but directoryName is EXPLICIT]

Wow, that response C is really creative!  I like it :-).

But I still hope that ASN.1 experts will step forward to confirm that
Response B is the correct one.

Approved-By:  John Pawling <[email-masked]>
Date:         Tue, 3 Feb 1998 10:35: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: John Pawling <[email-masked]>
Subject:      Re: [IETF-PKIX] FW: Attributes clarification in 509
To: [email-masked]
Status:

Sharon and friends,

The use of "forward" and "reverse" in Sharon's message seems contradictory
to the definitions stated in the X.509 spec, Section 8, Intro, which defines
forward and reverse as follows:

"If user A, trying to obtain the public key of user B, has already obtained
the public key of CA(B), then the process is complete. In order to enable A
to obtain the public key of CA(B), the directory entry of each Certification
Authority, X, contains a number of certificates. These certificates are of
two types. First there are forward certificates of X generated by other
Certification Authorities. Second there are reverse certificates generated
by X itself which are the certified public keys of other certification
authorities. The existence of these certificates enables users to construct
certification paths from one point to another."

Recommend that the X.509 editors should ensure that their use of forward and
reverse is consistent thorughout the document.

================================
John Pawling
[email-masked]
J.G. Van Dyke & Associates, Inc.
================================

At 07:58 AM 2/3/98 -0500, Sharon Boeyen wrote:
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>
>>----------
>>From:  Sharon Boeyen
>>Sent:  February 2, 1998 11:25 AM
>>To:    [email-masked]'
>>Subject:       Attributes clarification in 509
>>
>>As promised,
>>
>>Here is the text that was agreed at last week's X.509 meeting to clarify the
>>use of the cACertificate and crossCertificatePair attributes. This text
>>change to X.509 forms the draft technical corrigendum for defect report 185
>>and will be sent for ballot by ISO.
>>
>>"Clause 8
>>(Add the following text immediately following the asn.1 for certificatePair)
>>
>>The cACertificate attribute, held in a particular CA's directory entry, may
>>be used to store self-signed certificates.
>>
>>Note - The cACertificate attribute should not be confused with the defined
>>term CA-certificate.
>>
>>The crossCertificatePair attribute, held in a particular CA's directory
>>entry,  may be used to store certificates issued by this CA to other CAs, as
>>well as certificates issued for this CA by other CAs. Values held in the
>>forward element are certificates issued by this CA to other CAs, while values
>>in the reverse element are certificates issued for this CA by other CAs.
>>Either certificate, if present,  may be used in building certificate paths
>>for validation and may be published in the directory entries of either CA or
>>both. "
>>
>>------------------
>>
>>Hoyt will be sending another liaison statement to the IETF giving an update
>>of the other work being done in the 509 group and when I've completed the
>>editing task for the 509 enhancements wd and its made available on the Bull
>>server, we'll send another message to the list.
>>
>>
>>------------------
>>Sharon Boeyen
>>Entrust Technologies
>>
>>mailto:[email-masked]       Tel: (613) 247-3181
>>http://www.entrust.com          Fax: (613) 247-3690
>>         Orchestrating Enterprise Security
>>
>>
>

Approved-By:  Sharon Boeyen <[email-masked]>
Date:         Tue, 3 Feb 1998 07:58:56 -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] FW: Attributes clarification in 509
To: [email-masked]
Status:

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

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

>----------
>From:  Sharon Boeyen
>Sent:  February 2, 1998 11:25 AM
>To:    [email-masked]'
>Subject:       Attributes clarification in 509
>
>As promised,
>
>Here is the text that was agreed at last week's X.509 meeting to clarify the
>use of the cACertificate and crossCertificatePair attributes. This text
>change to X.509 forms the draft technical corrigendum for defect report 185
>and will be sent for ballot by ISO.
>
>"Clause 8
>(Add the following text immediately following the asn.1 for certificatePair)
>
>The cACertificate attribute, held in a particular CA's directory entry, may
>be used to store self-signed certificates.
>
>Note - The cACertificate attribute should not be confused with the defined
>term CA-certificate.
>
>The crossCertificatePair attribute, held in a particular CA's directory
>entry,  may be used to store certificates issued by this CA to other CAs, as
>well as certificates issued for this CA by other CAs. Values held in the
>forward element are certificates issued by this CA to other CAs, while values
>in the reverse element are certificates issued for this CA by other CAs.
>Either certificate, if present,  may be used in building certificate paths
>for validation and may be published in the directory entries of either CA or
>both. "
>
>------------------
>
>Hoyt will be sending another liaison statement to the IETF giving an update
>of the other work being done in the 509 group and when I've completed the
>editing task for the 509 enhancements wd and its made available on the Bull
>server, we'll send another message to the list.
>
>
>------------------
>Sharon Boeyen
>Entrust Technologies
>
>mailto:[email-masked]       Tel: (613) 247-3181
>http://www.entrust.com          Fax: (613) 247-3690
>         Orchestrating Enterprise Security
>
>

Approved-By:  Nilsson Hans <[email-masked]>
Date:         Tue, 3 Feb 1998 11:49: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: Nilsson Hans <[email-masked]>
Subject:      [IETF-PKIX] Tag type for rfc822name
Comments: To: "[email-masked]" <[email-masked]>
To: [email-masked]
Status:

I am editing the revision a certificate specification for the national
Swedish Electronic Identity Card (see www.seis.se), to harmonize it with
the certificate specifications of PKIX-1 and S/MIME. I am also going to
include examples of DER-coded certificates. In that context I have come
across different ways of encoding the subjectAltName rfc822Name
extension. The question is: Should it use IMPLICIT or EXPLICIT tags?
Below are two extracts from PKIX-1, which uses IMLICIT in one example
and EXPLICIT in another.

Which way has it been implemented in existing S/MIME products? Can they
handle both IMPLICIT and EXPLICIT coding of rfc822Name?

Here are the examples from PKIX-1:
------------------------ IMPLICIT TAG:
------------------------------------------
0606 a3 1d         29: . . [3]
0608 30 1b         27: . . . SEQUENCE
0610 30 19         25: . . . . SEQUENCE
0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
0617 04 12         18: . . . . . OCTET STRING
                     : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
                     : 6f 76

0000 30 10         16: SEQUENCE
0002 81 0e         14: . [1]
                     : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
note is taken from PKIX-1!)
-----------------------EXPLICIT TAG:
----------------------------------------------------
               30 3d
                  id-ce-subjectAltName = { 2 5 29 17 }
                  06 03 55 1d 11
                  by default, critical = FALSE
                  octet string
                  04 36
                     30 34
                        rfc822name
                        a1 1a
                           IA5String "[email-masked]"
                           16 18 65 73 63 65 72 74 2d 75 70 63 40 65 73
63
                           65 72 74 2e 75 70 63 2e 65 73
 ---------------------------------------------------------------
I have consulted different experts and of course received different
reponses:

Response A:
The Certificate Extensions module uses specifies IMPLICIT tags
('DEFINITIONS IMPLICIT TAGS ::= BEGIN ...).  Hence, IMPLICIT tags must
be used for selecting the 'rfc822Name' (e-mail) choice in the
'subjectAltName' extension.

Response B:

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.

Response C:
In the definition of GeneralName we have
rfc822Name              [1]     IA5String,
directoryName           [4]     Name,

And from X.680:
>     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.
With rfc822name, the Type is IAString, which means that IMPLICIT should
be used
BUT for directoryName the Type is Name, which is a CHOICE, which means
that EXPLICIT should be used.
------------------------------------------------------------------------
------------------------------------
Looking forward to your help!

Hans Nilsson
AU-System
Stockholm, Sweden

Approved-By:  Bob Jueneman <[email-masked]>
Date:         Mon, 2 Feb 1998 14:28:02 -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] Attribute Cert examples?
Comments: To: [email-masked]
To: [email-masked]
Status:

Has such an animal even been completely defined yet?  I though X9 was still working on the spec.

I'll be interested to se what kind of a reply you receive.

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."

>>> "David P. Kemp" <[email-masked]> 02/02 11:23 AM >>>
Does anyone have or know of a publicly-available example of an X.509
Attribute Certificate?  I'm looking for test data to independently
validate some parsing software, and for an instance to include in the
PKIX Part 1 examples appendix.

Thanks,
  Dave Kemp

Approved-By:  "David P. Kemp" <[email-masked]>
Date:         Mon, 2 Feb 1998 13:23: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: "David P. Kemp" <[email-masked]>
Subject:      [IETF-PKIX] Attribute Cert examples?
To: [email-masked]
Status:

Does anyone have or know of a publicly-available example of an X.509
Attribute Certificate?  I'm looking for test data to independently
validate some parsing software, and for an instance to include in the
PKIX Part 1 examples appendix.

Thanks,
  Dave Kemp

Approved-By:  Olivier Onimus <[email-masked]>
Date:         Mon, 2 Feb 1998 12:04:03 +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: Olivier Onimus <[email-masked]>
Subject:      [IETF-PKIX] Time Stamp and Hash Alg
Comments: cc: Rob Zuccherato <[email-masked]>
To: [email-masked]
Status:

Hi,

I have one question and one suggestion about time-stamp:

In PKIX Part V Time Stamp Protocols, the
data to be time-stamped must have the form:

MessageImprint ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentifier,
     hashedMessage OCTET STRING}

And  AlgorithmIdentifier  is definesd as:
  AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

For most of the implementations realised with standard
ASN.1-Tools-and-compilers,
this means that SW must "know" in advance all the
accepted Alg.-OIDs to link the expected parameter to them.

Now my question:

   Is there a profile of the supported hash-algorithms with the
   corresponding parameter-syntaxes ?

Now a remark:
   A time-Stamp-Server does NOT need the crypto-algorithm like an application
   which must decrypt data or check a signature !
   It just has to notice "OK, the client did hash the data with this alg.,
and that's
   all (anyway, the server has no chance to control that the received data
   are the correct result of the specified algorithm !).
   So, why should a Time-Stamp-Implementation be limited by the
   hash-algorithms it can decode ?
   IMO, a construct like:
   AlgorithmIdentifierTS  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              OCTET STRING OPTIONAL
                                -- contains DER-coding of parameters of OID
                                -- identified by algorihtm
                               }

   would still allow the TimeStamp-Server to control the used OID, but had
the benefit,
   that ASN.1-SW does not have to be modified for every new hash-algorithm !

Any opinion ?

Bye.

Olivier

 _______________________________________________________________________
 Olivier Onimus
 Danet GmbH, Business Unit Telecommunications Technology
 Gutenbergstrasse 10, D-64331 Weiterstadt, Germany
 Tel: +49-6151-868-127   Fax: +49-6151-868-264   E-mail: [email-masked]
 _______________________________________________________________________

Approved-By:  Simonetti David <[email-masked]>
Date:         Sun, 1 Feb 1998 10:53: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: Simonetti David <[email-masked]>
Subject:      Re: [IETF-PKIX] Key Usage
Comments: To: Rodney Thayer <[email-masked]>
To: [email-masked]
Status:

Rodney,

I had forwarded the following shortly after the Washington meeting.  The minimal
response I received was favorable, but I never received an absolute response from
the PKIX-1 authors...

Tim (et al),

As you stated at the meeting last week with respect to the key usage profile, I
agree that PKIX should not restrict the bit combinations.  However, I think the
previous discussions on this topic proved obvious that there are multiple
interpretations of these bits.

In an attempt to clarify the meaning of several of the bits, I suggest
the following editorial changes to PKIX-1:

Section 4.2.1.3, paragraph beginning with "The digitalSignature bit is
asserted...", add the following, "The digitalSignature bit should be set
when the key is for use in ephemeral applications, e.g., for a single
session authentication application."

Paragraph beginning with "The nonRepudiation bit is asserted...", add
the following, "The nonRepudiation bit should be set when when the key
is used to sign an object which may require the validation of the
signature at a future time."

I also suggest adding, "If the key may be used for both digitalSignature
and nonRepudiation applications, both bits may be set."

Finally, after the descriptions of encipherOnly and decipherOnly I
suggest adding the following:

"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 own certificate
with bits 4 and 8 along with the message."

Dave S.
(I will be out of e-mail contact 2-9 Feb.)

Rodney Thayer wrote:

> >X-Mailer: Mozilla 4.03 [en] (Win95; U)
> >Approved-By:  Simonetti David <[email-masked]>
> >Date:         Fri, 30 Jan 1998 12:55:39 -0500
> Gentlemen, with all due respect some of us don't care what X.509 says we
> want to make the PKIX IETF documents clear.
>
> So what do you want the PKIX document to say?  And, in IEFT style, can you
> specify which document and where you would like the text changed?
>
> -- Rodney Thayer <[email-masked]>