Subject: Re: Draft Memphis PKIX Minutes
From: "Housley, Russ" <[email-masked]>
To: [email-masked], Warwick Ford <[email-masked]>
Date: Wed, 23 Apr 97 18:37:35

Warwick:

The draft minutses say:

   Hiroaki accepted the invitation to contact Russ Housley regarding any 
   contributions he desires to produce for Part 2.

They should say:

   Hiroaki accepted the invitation to write a contribution for Part 2 
   dealing with the use of HTTP for obtain certificates and CRLs from a 
   repository.

Russ

Date: Wed, 23 Apr 97 03:05:00 
From: "Housley, Russ" <[email-masked]>
Encoding: 2641 Text
To: [email-masked], <[email-masked]>
Subject: Re: authorityInfoAccess ATTRIBUTE

Mike:

I thought that someone wanted it to be defined as a PKCS#9 attribute, not 
an X.500 directory attribute.  Did I miss something?

Russ

______________________________ Reply Separator _________________________________
Subject: authorityInfoAccess ATTRIBUTE
Author:  <[email-masked]> at internet
Date:    4/17/97 4:08 PM

<bigger>A request was made at the WG in Memphis to define 
AuthorityInfoAccess as an ATTRIBUTE to enable its inclusion in a PKCS 7 
message.  When included in a PKCS 7 message, this attribute can be used 
to identify and locate certificates associated with the message rather 
than include the certificates directly, thereby reducing the size of the 
encapsulated message (or object).

</bigger>

Following is a proposed amendement to section 4.2.2.2 of PKIX Part 1 
responding to this requirement.

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

4.2.2.2  Authority Information Access

(To the existing text, append the following:)

The authorityInfoAccess extension may be included in a PKCS 7 
encapsulation as an X.501 ATTRIBUTE.  This attribute can then be used to 
locate certificates automatically rather than include the certificates 
directly.  The intended effect is to reduce the size of the encapsulated 
message or object.

PKCS 9 identifies attributes for inclusion in PKCS 7, referencing X.520 
standard attributes and defining additional attributes unique to PKCS 9. 
The attributes defined in X.520 are based on the definition of ATTRIBUTE 
in ITU-T X.501 | ISO/IEC 9594-2.

The following syntax defines authorityInfoAccess as an ATTRIBUTE suitable 
for inclusion in a PKCS 7 message:

authorityInfoAccess ATTRIBUTE ::= {

    WITH SYNTAX    authorityInfoAccessSyntax,

    ID             id-pkix-authorityInfoAccess }

PKIX Part 2 establishes requirements on certificate retrieval mechanisms.
 It is expected that applications using the URI form of the authorityInfo
field for such a purpose will:

1.  Prepend a suitable HTTP retrieval primitive to the URL (e.g. 
"GET").

2.  Append a filename to the URL.

3.  Use the result to retrieve a file containing the requested 
certificate.

4.  Use the authorityInfoAccess extension in that and subsequent 
certificates to complete a certificate path.

The filename will be formed as the IA5string representation of SHA1( 
Issuer DN | certificate serial number) concatenated with ".cer."  The 
SignerInfo syntax of PKCS 7 provides the necessary information as 
issuerAndSerialNumber.

The specified file will contain a single DER encoded certficate.

From: <[email-masked]>
Date: Tue, 22 Apr 1997 05:08:54 -0400
Subject: Delivery-Report (failure) for [email-masked]
To: [email-masked]
Importance: low
Message-Type: Delivery Report

--(null)--

	messsage id:	<[email-masked]>
	subject:	Re: Draft Memphis PKIX Minutes
Delivery failed to [email-masked]
	reason:	 INVALID DESTINATION ADDRESS 

Date: Tue, 22 Apr 97 03:57:31 -0500
From: "Karoki Michael"<[email-masked]>
To: <[email-masked]>
Subject: cc:Mail Link to SMTP Undeliverable Message

--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit

Message is undeliverable.
Reason: User "[email-masked]" is not found in the cc:Mail Directory.
Original text follows:
---------------------

--simple boundary
Content-Type: text/plain; charset=US-ACSII
Content-Transfer-Encoding: 7bit

From: Stefan Kelm <[email-masked]>
Date: Tue, 22 Apr 1997 09:18:46 +0200 (MET DST)
To: [email-masked]
Subject: Re: Draft Memphis PKIX Minutes
Reply-To: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

>
> ftp://ftp.icat.or/lp/pub/interauth/icap
>

Warwick,

just a minor correction to the above URL. It should read:

        ftp://ftp.icat.or.jp/pub/interauth/icap

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm                                                  <[email-masked]>
DFN-PCA, University of Hamburg                    http://www.pca.dfn.de/~kelm/
Vogt-Koelln-Str. 30             "finger [email-masked]" to get my PGP key
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

--simple boundary--

From: Stefan Kelm <[email-masked]>
Date: Tue, 22 Apr 1997 09:18:46 +0200 (MET DST)
To: [email-masked]
Subject: Re: Draft Memphis PKIX Minutes
Reply-To: [email-masked]

-----BEGIN PGP SIGNED MESSAGE-----

>
> ftp://ftp.icat.or/lp/pub/interauth/icap
>

Warwick,

just a minor correction to the above URL. It should read:

        ftp://ftp.icat.or.jp/pub/interauth/icap

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm                                                  <[email-masked]>
DFN-PCA, University of Hamburg                    http://www.pca.dfn.de/~kelm/
Vogt-Koelln-Str. 30             "finger [email-masked]" to get my PGP key
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241

Date: Mon, 21 Apr 1997 23:47:34 -0600
To: Carlisle Adams <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>
From: [email-masked]
Subject: Challenge-Response Question
Cc: [email-masked]

Carlisle:

At 10:19 AM 4/21/97 -0400, Carlisle Adams wrote:
>. . .
>>6.  The challenge-response model is based on a protocol documented in the
>>Handbook of Applied Cryptography.  It was asked if internal details of this
>>protocol can be dropped as long as the challenge-response endpoints are
>>maintained.
>>
>>Resolution:  The specification does not preclude doing so.
>
>I don't actually recall this discussion, and can't seem to find it in my
>notes.  From the "resolution" given above, it sounds like everything's
>fine, but could someone remind me what was actually asked?  I'm not sure
>I fully understand what's written in point 6...

The original question came from Keith Vogel.  It came and went very
quickly.  This was my best record of the exchange.

--Mike

Date: Mon, 21 Apr 1997 13:50:48 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Comments on pkix part 1, draft 4

A few small nits concerning PKIX Part 1:

* Section 3.4, "Operational Protocols" should contain a reference to
  Part 2.  Perhaps change the sentence "These specifications include
  definitions of ..." to "Part 2 of the PKIX specifications include ...".

* Section 4.1 contains definitions of most Certificate structures, but
  omits Name and AlgorithmIdentifier.  May want to include them here for
  completeness.

* Section 4.2.1.5, Certificate Policies, and many other sections contain
  the construct "SEQUENCE SIZE (1..MAX) OF ...".  I have never been able
  to find a definition of what MAX refers to - it is apparently not
  from upper-bounds definitions. (Or if it is, where is the upper bound
  for the policyQualifiers SEQUENCE, for example?)  A tutorial on the
  meaning of MAX would be useful in the PKIX specification.

* Section 4.2.1.7, GeneralName, includes iPAddress, an OCTET STRING.
  The format of the data in the OCTET STRING should be specified
  (binary data in network byte order?, dotted decimal notation?).

* Section 4.2.2, Private Internet Extensions, contains the definition
  of the pkix OID, but probably should be spelled out:

    { iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) }

  and a reference to the IANA file

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

  should be added.

* Section 5.1, CRL Fields, includes the definition

      revokedCertificates  SEQUENCE OF SEQUENCE { ... } OPTIONAL,

  It might be a tiny bit clearer to write:

      revokedCertificates  SEQUENCE OF crlEntry OPTIONAL,

      crlEntry ::= SEQUENCE { ... }

* Section 8, Examples.  It might be better to move the examples to
  the very end, in an Appendix A (or Annex A, if you prefer ISO
  terminology :-).

* Section 9, "ASN.1 structures and OIDs" contains the definition of
  AlgorithmIdentifier on page 60 under CRL structures.  It would be
  easier to find if it were located at the beginning, after the
  definition of Name on page 54.

* The definitions of Version, Extensions, and Extension appear twice, once
  under the Certificate structure and again under CRL structures.  I guess
  this doesn't hurt anything, but the other common elements (Name,
  AlgorithmIdentifier) aren't defined twice.

* Patent Statements begins with 4 paragraphs, the first two of which
  appear to be redundant with the second two.  Delete paragraphs 3 and 4?

* X.509 contains two definitions of cert paths:

    Certificates ::= SEQUENCE {
       userCertificate    Certificate,
       certificationPath  ForwardCertificationPath OPTIONAL }

    ForwardCertificationPath ::= SEQUENCE OF CrossCertificates

    CrossCertificates ::= SET OF Certificate

and

    CertificationPath ::= SEQUENCE {
       userCertificate    Certificate,
       theCACertificates  SEQUENCE OF CertificatePair OPTIONAL }

    CertificatePair ::= SEQUENCE {
       forward  [0]  Certificate OPTIONAL,
       reverse  [1]  Certificate OPTIONAL }

Unfortunately, X.509 does not define a structure to contain the simplest,
most common type of cert path - similar to Certificates, but where
ForwardCertificationPath is a SEQUENCE OF Certificate.

PKIX should profile the contents of an Internet cert path in a way that
implementors will find sufficiently general yet still easy to use.
However, I don't know where to draw the line.

Strawman proposal:
  MUST support Certificates, where CrossCertificates contains a single
  Certificate.

  MAY support multiple Certificate's in CrossCertificates.

  MAY support CertificationPath.

We could change either or both of the MAY's to SHOULD's if anyone
presents a convincing rationale for needing them.

The TLS working group currently uses a list of certificates in a
TLS-specific data structure (not a SEQUENCE).  I believe they would
benefit from a PKIX-defined cert path.

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Warwick Ford'" <[email-masked]>
Subject: RE: Draft Memphis PKIX Minutes
Date: Mon, 21 Apr 1997 10:19:01 -0400
Encoding: 57 TEXT

Hi,

Great minutes!

Just a couple of small things:

>----------
>From: 	Warwick Ford[SMTP:[email-masked]]
>Sent: 	Sunday, April 20, 1997 11:12 PM
>To: 	[email-masked]
>Subject: 	Draft Memphis PKIX Minutes
>
>Thanks to Michael Myers, here are the draft minutes of the Memphis meeting,
>for review by the attendees and for the information of the non-attendees.
>
>Warwick
>------------------------------------
>
>PKIX WG Minutes, April 7-8 1997
>
>
>SUMMARY

(...stuff deleted...)

>6.  The challenge-response model is based on a protocol documented in the
>Handbook of Applied Cryptography.  It was asked if internal details of this
>protocol can be dropped as long as the challenge-response endpoints are
>maintained.
>
>Resolution:  The specification does not preclude doing so.

I don't actually recall this discussion, and can't seem to find it in my
notes.  From the "resolution" given above, it sounds like everything's
fine, but could someone remind me what was actually asked?  I'm not sure
I fully understand what's written in point 6...

(...more stuff deleted...)

>TIMESTAMPING / NOTARIES
>
>Carlisle Adams proposed that PKIX begin work in this area, based on ISO
>1388 part 3.  Several members of the WG, including representatives from
>BBN, Spyrus and VeriSign, offered to participate.

The ISO document is 13888 part 3.

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

Date: Sun, 20 Apr 1997 20:12:29 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Draft Memphis PKIX Minutes

Thanks to Michael Myers, here are the draft minutes of the Memphis meeting,
for review by the attendees and for the information of the non-attendees.

Warwick
------------------------------------

PKIX WG Minutes, April 7-8 1997

SUMMARY

The PKIX WG met in two sessions at the April 1997 IETF meeting in Memphis.
The main agenda topics were status briefings on Parts 1, 3 and 4 of the
PKIX document set and an initial briefing Part 2.  In the follow-up
session, several technical amendments were proposed, discussed and moved
forward.

There was also an informational presentation drawing attention to an
alternative certificate management protocol based on HTTP and HTML
technology.  This information was presented for the WG's consideration in
the development of the IETF standard certificate management protocol.

Parts 1 and 3 will transition to WG Last Call following this IETF.  Part 2
will take longer, but is also targeted for standards track.  Part 4
provides guidance for authors of certificate policies and certification
practice statements, and is targeted for an Informational RFC.  Additional
work is expected in the areas of Attribute Certificates and their
relationship to access control, Timestamping and Notarial services, and the
evolution of PKCS #10.

MONDAY, 7 APR 97

PART 1:  CERTIFICATE AND CRL PROFILES

Tim Polk presented the changes to Part 1 between the Dec. 97 draft and the
current draft.  These were:

* Reduced private extensions from three to two, both non-critical
* Eliminated sliding window for time encoding, instead a fixed date.
* URIs in alt name fields point to certificates in repositories
* URI in authority InfoAccess points to on-line validation service
* Cylink patent statement added
* ASN.1 is believed complete
* ASN.1 EXPLICIT/IMPLICIT problems corrected
* KEA encoding added
* Examples added
* Improved references

OPEN ISSUES
* RSA patent statement still outstanding, should be resolved soon.
* Examples:  expand?  remove?
* ASN.1 checking (check '88 vs. '93 constructs)

It is the intent of the WG that Part 1 will go to WG Last Call following
this IETF.

DISCUSSION
1.  KEA is an unpublished algorithm.  References to it in Part 1 should be
removed.

Resolution: References to KEA will be removed from Part 1.  Parties
interested in such a specification may publish an informational draft
addressing the issue.

2.  The RSA patent statement is still an outstanding issue, but it should
be resolved soon.

Resolution:  Tim Polk will take action to move this issue to closure.

3.   The current draft indicates 1996 date, should be changed to indicate a
1997 date.

Resolution:  The document will be changed to reflect the correct expiration
date. The title of the Part 1 document correctly indicates version 4.

PART 2:  OPERATIONAL PROTOCOLS

Sharon Boeyen presented the work to date on Part 2 regarding the use of
LDAP and FTP for retrieval of certificates and CRLs and the requirements
for and specification of an Online Certificate Status Protocol (OCSP).

DISCUSSION
1 - Should we consider splitting the document into two separate ones, since
the OCSP is a new protocol definition which may require significant more
review and discussion than the LDAP and FTP profiles?

Resolution: Although we agree that OCSP may require additional review, the
document will remain a single draft and we will re-address this issue, if
the OCSP discussion is such that it will require a longer review period and
impede progression of the remainder of the document.

2 - A question was raised about privacy when searching directories via LDAP
(e.g. email addresses may not be made public). 

Resolution: The intent of PKIX part 2 is NOT to suggest that any attributes
need to be made public. If some attributes, such as email addresses, happen
to be public information, then the LDAP profile defined in PKIX part 2 will
support searching on such attributes.

3 - A question raised regarding the requirement of a public key operation
on each OCSP validation operation and had there been any consideration
given to ways to reduce that requirement.

Resolution: Some support for reducing the load on the server can be
provided by caching signed responses for frequently requested certificates.

4 - A question was raised on the specific contents of a ".cer" file.

Resolution: Each .cer file contains exactly one certificate, encoded in DER
format.

5 - LDAP profile for adding, modifying, deleting PKI information was raised
as an issue - should these operations be added to PKIX part 3 (since they
are data management operations) or should they be added to PKIX part 2
(keeping the complete LDAP profile together).

Resolution: The LDAP operations will be profiled in PKIX part 2 and
appropriate references added to PKIX part 3.

6 - LDAP versions 

Resolution: The progress of LDAP v3 will be tracked and when stable,
consideration will be given to moving this profile from v2 to v3. V3
support for strong authentication will probably help satisfy some concerns
raised over the ability of someone to masquerade as a repository.

PART 3:  MANAGEMENT PROTOCOL

Carlisle Adams presented the current state of Part 3.  The current draft
currently resides on Entrust's web server at www.entrust.com.  It will be
moved to the Internet Drafts directory after the IETF.

Substantive changes from the previous draft:
* Addition of PKCS 10 as a valid certification request message.
* Recognition of PKCS 7 as an alternate security protocol.
* Text regarding Proof of Possession (POP) of a private key.
* Added a challenge-response mechanism in support of Registration Authorities.

It is the intent of the WG that Part 3 will go to WG Last Call following
this IETF.

DISCUSSION
1. It was pointed out that the current statement regarding PKCS 10 usage
was overly specific as to the allowable context of its use.

Resolution:  The text will be amended to generally accommodate PKCS 10
requests.

2.   At the San Jose meeting, a general consensus was established within
the WG that evolutionary support for PKCS 7 & PKCS 10 is desirable as an
alternative to PKIX Part 3.  A question was raised regarding the current
status of this issue.

Resolution:  It should be expected that work will be performed to advance
PKCS 10 forward to address requirements met by Part 3.

3.  More flexibility in the statements regarding requirements on POP is
desired.

Resolution:  The editor will amend the text to more fully express the
intended flexibility.

4.  A question was raised concerning the exact definition of "operational
protocols".

Resolution:  The term "operational protocols"  within PKIX refers to those
relevant to delivering PKI services.  Application protocols, e.g. S/MIME or
TLS, are out of scope.

5.  It was noted that there is no means to indicate a type of CA in the
certification request.

Resolution:  Type of CA is defined by policy OID or by reading the CPS.

6.  The challenge-response model is based on a protocol documented in the
Handbook of Applied Cryptography.  It was asked if internal details of this
protocol can be dropped as long as the challenge-response endpoints are
maintained.

Resolution:  The specification does not preclude doing so.

7.  In the challenge-response model of registration, can the RA reformat
the request received from the subscriber when forwarding it to the CA?

Resolution:  Yes.  The intent is to establish a general model of
Subscriber-RA-CA interaction that is extensible to detailed operational
requirements.  The RA may choose to simply re-encapsulate the subscriber's
request, but is not required to do so.  The RA could receive a certificate
request in one format and forward to a CA in another format.

8.  It was asked if conformance to Part 3 is defined by the text, or by the
tables in Appendix B, or if there should be some other external document
defining conformance.

Resolution:  It is the authors' intent that the tables in Appendix B define
conformance.  A blanket statement will be added to the text to clarify this
intent.

PART 4:  POLICY GUIDELINES

Santosh Chokhani presented details on status of Part 4.

1.  A questioner asked if Part 4 is intended to be prescriptive with
respect to the Internet.

Resolution:  It is beyond the scope of Part 4 to prescribe Internet
certificate management policy or acceptable certification practices.  Part
4 is informational in nature, and intended as an aid to the development of
certificate policies and certification practices statements.  Any
requirement governing the implementation of automated certificate policy
recognition and decision logic will be addressed by Part 1. LDAP could be
used to gain access to electronic policy elements, to the extent such
policy elements exist.

2.  There was an observation that the document does not discuss storage of
CRLs, or the role of repositories generally.

Resolution:  It was pointed out that Part 4 does indeed recognizes the
existence of repositories, their role with respect to CRL distribution and
provides some discussion of their relevance to the overall PKI policy
management solution.  Part 4 does not establish policy; rather, it
identifies the elements that may be included in a certificate management
policy.  It was ultimately recognized that additional work was needed on
specific obligations for CRLs and repositories.

3.  It was requested that PKIX work with IANA to register an OID so that
policy elements can be identified if and when they're defined.

Resolution:  One of the PKIX editors noted that we have an OID arc already
in place.

TUESDAY, 8 APR 97

KIKUCHI DRAFT:  WEB-BASED CERTIFICATE AND CRL REPOSITORY

Hiroaki Kikuchi presented an alternative to PKIX part 3.  The proposal
addresses an HTML-based value encoding instead of BER encoding for the
purposes of human readability.  It further presents an alternative
text-based protocol for various certificate management functions.  A
software package--ICAT CA Package ver 1.0, implementing the described
functionality is available at:

ftp://ftp.icat.or/lp/pub/interauth/icap

DISCUSSION

It was noted that the proposal needs to be updated to reflect the reduction
of PKIX private extensions from three to two.

Part of the proposal involves the use of relative URLs.  It was noted this
is useful if all operations are confined to a well-known repository; the
general case suffers, however. One repository would not work in general.

The HTML is still not all that readable.  Hiroaki concurred that some of
his colleagues have made the same observation.

It was hypothesized that an HTML representation of a reasonable complex
certificate would be substantially larger than its corresponding ASN.1
equivalent.  Hiroaki drew attention to the fact that the HTML syntax maps
one-to-one to BER encoding rules.

Hiroaki accepted the invitation to contact Russ Housley regarding any
contributions he desires to produce for Part 2.

CERTIFICATE STORAGE INTEREST GROUP

Christopher Allen of Consensus Development discussed a proposed
standardization activity on personal information storage .  Schemes under
consideration include PFX and a scheme that is substantially simpler than
the current PFX proposal.  Under the second proposal, all information
relevant to the transport of a subscriber's security context would be
encapsulated in an "ASCII-armored" format, formatted using base-64
encoding.  Internal to the storage context, PKCS 7 would be used for
certificate and CRL encapsulation and PKCS 5 and 8 for private keys.

Interested parties are encouraged to participate in a mailing list
dedicated to this topic ([email-masked], subject: subscribe).
 If sufficient interest accumulates around the topic, a BOF may be formed
at the next IETF to consider moving the topic forward more formally. 

TIMESTAMPING / NOTARIES

Carlisle Adams proposed that PKIX begin work in this area, based on ISO
1388 part 3.  Several members of the WG, including representatives from
BBN, Spyrus and VeriSign, offered to participate.

TLS LIASON

Rodney Thayer, Christopher Allen and Tim Dierks of TLS working group led a
discussion on the relationship between TLS and PKIX.  Following are issues
raised, and their corresponding resolution:

1.  It was noted that the current PKIX Part 1 does not spell out use of MD5
as a supported alternative.  The text and corresponding examples are
inconsistent in their suggestion of MD5 as a requirement.  MD5 is required
in order to enable the mandatory TLS cipher suite.

Resolution: PKIX Part 1 will be amended to provide the necessary support.

2.  There exists some uncertainty as to the interpretation of KeyUsage bits
when applied to the TLS protocol.  Part 1 should make explicit the
circumstances applicable to given KeyUsage bits.

Resolution: Text will be added to provide additional guidance on the
assignment of KeyUsage bits.  In particular, it was agreed that
DigitalSignature should be set for client certificates, since TLS clients
signs an object (the MasterSecret of the TLS protocol.).  In the case of
server authentication, the server's decryption and subsequent successful
use of the client's keys (which were encrypted under the server's public)
is proof of server authentication.  In this case KeyEncipherment shall be
set.  When ephemeral RSA is used to sign an ephemeral DH key,
DigitalSignature shall apply.  (See also Extended Key Usage below.)

3:  It is preferable to be able to express name strings containing regular
expressions for the purpose of flexible domain administration and load
balancing.  Clarification was requested as to whether such constructs are
to be included in the Subject Name of the base certificate, or in the
dNSName variant of SubjectAltName.

Resolution:  Use SubjectAltName.

PART 1 MODIFICATIONS

Enhanced Key Usage

The current key usage bits extension is insufficient to meet needs to
identify the full set of purposes for which a public key may be used.  The
following syntax was proposed at the meeting.

KeyPurpose ::= SEQ SIZE (1 .. MAX) of OBJECT IDENTIFIER

PKIX-1 defines OIDs for all defined values of KeyPurpose.

KeyPurpose will be presented to ISO as standard replaced for KeyUsage.

There was an observation that the certificate policy extension could be
used to satisfy this requirement.  It was felt however that certificate
policies are conceptually orthogonal to key purpose.  Certificate policies
express a measure of reliance strength, independent of purpose.

After much debate, it was decided to retain the existing KeyUsage bits and
propose another standard extension called enhancedKeyUsage (or
extendedKeyUsage) to carry the purpose OIDs.

AuthorityInfoAcces syntax

Kevin Vogel described the need for additional flexibility to define new
formats for CRL retrieval in a standard fashion.  He suggested reverting
back to the December 96 draft concepts.  The following syntax was proposed:

AccessDescription::=SEQUENCE {
format OBJECT IDENTIFIER default PKIX2
location GeneralNAME }

AuthorityInfoAccessSyntax ::= SEQUENCE {
	authorityInfo	[0]  GeneralName	OPTIONAL
	statusInfo	[1]  SEQUENCE OF  accessDescription OPTIONAL }

Keith also requested that AuthorityInfoAccessSyntax be defined as an
ATTRIBUTE so it can be included in PKCS 7 messages.  This would be used to
point to certificate storage area, given only the Issuer DN + cert. serial
number in SignerInfo of PKCS 7.  With the ability to automatically locate
certificates by reference, they  need not be included in the PKCS 7
encapsulation, thus reducing its size.

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

From: Brian Korver <[email-masked]>
Subject: Re: RSA Encryption OID
To: [email-masked] (David P. Kemp)
Date: Fri, 18 Apr 1997 14:28:25 -0700 (PDT)
Cc: [email-masked]

David P. Kemp writes:
> 
> Where did the SET group find definitions for {1 2 840 113549 1 1 6} and
> {1 2 840 113549 3 10}?

RSA provided these to the SET group.

> The copy of PKCS-1 on RSA's web site only goes up to {1 2 840 113549 1 1 4}
> (md5WithRSAEncryption).  And the S/MIME Implementation Guide only
> contains encryptionAlgorithm definitions for {1 2 840 113549 3 2} (RC2-CBC)
> and {1 2 840 113549 3 7} (DES-EDE3-CBC).

brian
[email-masked]

FYI,

> > >------------
> > >
> > >ALGORITHM IDENTIFIER FOR IBM's CDMF ALGORITHM
> > >
> > >At the request of IBM, RSA has registered an ASN.1 algorithm 
> > >identifier for their patented algorithm for the Commercial
> > >Data Masking Facility (CDMF). This note defines that
> > >identifier and associated information.
> > >
> > >RSA Data Security, Inc.'s OSI (Open Systems Interconnection) object
> > >identifier is 1.2.840.113549 (2a, 0x86, 0x48, 0x86, 0xf7, 0x0d in hex), 
> > >as registered by the American National Standards Institute (ANSI). 
> > >In the following, the prefix "rsadsi" refers to that object identifier. 
> > >All object identifiers registered by RSA Data Security begin with this 
> > >prefix. 
> > >
> > >
> > >CDMFCBCPad
> > >
> > >This is a Cipher Block Chaining mode of operation with padding
> > >of a 40-bit variant of DES. The algorithm is defined in:
> > >
> > >  IBM Journal of Research and Development, "The Commercial Data
> > >  Masking Facility (CDMF) Data Privacy Algorithm", Volume 38,
> > >  Number 2, March 1994.
> > >
> > >Following the ASN.1 style of the "Agreements for Open Systems
> > >Interconnection Protocols: Part 12 OS Security", it is defined by: 
> > >
> > >ALGORITHM MACRO ::=
> > >BEGIN
> > > TYPE NOTATION ::= "PARAMETER" type
> > > VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)
> > >END -- of ALGORITHM
> > >
> > >IV8 ::= OCTET STRING (SIZE(8))
> > >
> > >CBC8Parameter ::= IV8
> > >
> > >CDMFCBCPad ALGORITHM
> > > PARAMETER CBC8Parameter
> > > ::= {iso(1) member-body(2) US(840) rsadsi(113549)
> > >      encryptionAlgorithm(3) 10}
> > >-- In hex, the CDMFCBCPad algorithm ID is: 
> > >-- { 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x03, 0x0a }
> > >
> > >The PARAMETER is needed to specify the Initialization Vector,
> > >which need not be kept secret. It is 8 octets long.
> > >
> > >This mode should be used to encrypt multiple blocks, where the
> > >full message is available. The random IV prevents code book
> > >analysis of the start of the chain. The IV may be public.
> > >
> > >This mode will propagate a single bit error in one plaintext
> > >block into all succeeding blocks, and will propagate a single bit
> > >error in the ciphertext into a garbled plaintext block on
> > >decryption as well as a single bit error in the next plaintext
> > >block. 
> > >
> > >The following padding mechanism should be used if the data 
> > >to be encrypted is octet aligned, unless the security policy
> > >dictates otherwise:
> > >
> > >The input to the CDMF CBC encryption process must be padded to a
> > >multiple of 8 octet, in the following manner.  Let n be the
> > >length in octets of the input. Pad the input by appending 8-(n
> > >mod 8) octet to the end of the message, each having the value
> > >8-(n mod 8), the number of octets being added. In hexadecimal,
> > >the  possible paddings  are: 01,  0202, 030303,  04040404,
> > >0505050505, 060606060606, 07070707070707, and 0808080808080808.
> > >All input is padded with 1 to 8 octets to produce a multiple of 8
> > >octets in length. The padding can be removed unambiguously after
> > >decryption.
> > >
> > >Editor's Note - If adding the padding rules would cause
> > >existing implementations to break, this should be registered
> > >as a separate algorithm identifier.  Note, however, that
> > >[FIPS 81] specifies its own padding rules for padding binary
> > >data, in the absence of application-defined rules such as
> > >those above; those rules require an indication (which could
> > >be conveyed as an algorithm PARAMETER) of whether the data
> > >has been padded or not.
> > >
> > >
> > >------------
> > >
> > >OTHER ENCRYPTION ALGORITHMS REGISTERED BY RSA
> > >
> > >rsadsi                             1.2.840.113549 
> > >encryptionAlgorithm                rsadsi.3                 
> > >  rc2CBC                             encryptionAlgorithm.2  
> > >  rc2ECB                             encryptionAlgorithm.3  
> > >  rc4                                encryptionAlgorithm.4  
> > >  rc4WithMAC                         encryptionAlgorithm.5  
> > >  DESX-CBC                           encryptionAlgorithm.6  
> > >  DES-EDE3-CBC                       encryptionAlgorithm.7  
> > >  RC5CBC                             encryptionAlgorithm.8  
> > >  RC5CBCPad                          encryptionAlgorithm.9  
> > >  CDMFCBCPad                         encryptionAlgorithm.10 
> > >

Date: Fri, 18 Apr 1997 16:47:07 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: RE: RSA Encryption OID

> From: "Lewis, Tony" <[email-masked]>
> 
> In the original publication of SET on February 23, 1996, SET defined
> 
> id-sha-with-rsa-signature OBJECT IDENTIFIER ::= {1 3 14 3 2 15}
> 
> 
> When SET was updated on June 24, 1994, it defined
> 
> id-sha1-with-rsa-signature OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 5}
> 
> This was necessary because the earlier definition described SHA rather
> than SHA-1. I don't know when {1 3 14 3 2 29} was defined, but this is
> the first time I've heard about it. Given that the cut-off for
> requesting changes to SET has passed, I have mixed feelings about this.
> On the one hand, I like using a shorter OID in an arc that is managed by
> an identified-organization and tweaking this OID for version 1.0 would
> not be that difficult to do (provided it happened today). On the other
> hand, we are trying to minimize gratuituous last minute changes to SET.
> 
> 
> SET also uses the following definitions under RSADSI:
> 
> rsaOAEPEncryptionSET OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 6}
> id-rsaEncryption OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 1}
> id-desDCMF ::= {1 2 840 113549 3 10}
> 
> Are any of these others available in the secsig arc?

This is my list of OIW secsig OIDs, extracted from the stable and
working agreements documents dated December 1994. (I don't know the date
they were actually published).  The sha1 definitions were apparently added
as a block after FIPS 180-1 was released:

Petty annoyance note: the OIW added password protection to their
webserver on April 1.  Pffffffttttttt!

	{ "1.3.14.3.2.2",  "md4WithRSA" },
	{ "1.3.14.3.2.3",  "md5WithRSA" },
	{ "1.3.14.3.2.4",  "md4WithRSAEncryption" },
	{ "1.3.14.3.2.6",  "desECB" },
	{ "1.3.14.3.2.7",  "desCBC" },
	{ "1.3.14.3.2.8",  "desOFB" },
	{ "1.3.14.3.2.9",  "desCFB" },
	{ "1.3.14.3.2.10", "desMAC" },
	{ "1.3.14.3.2.11", "rsaSignature" },
	{ "1.3.14.3.2.12", "dsa" },
	{ "1.3.14.3.2.13", "dsaWithSHA" },
	{ "1.3.14.3.2.14", "mdc2WithRSASignature" },
	{ "1.3.14.3.2.15", "shaWithRSASignature" },
	{ "1.3.14.3.2.16", "dhWithCommonModulus" },
	{ "1.3.14.3.2.17", "desEDE" },
	{ "1.3.14.3.2.18", "sha" },
	{ "1.3.14.3.2.19", "mdc-2" },
	{ "1.3.14.3.2.20", "dsaCommon" },
	{ "1.3.14.3.2.21", "dsaCommonWithSHA" },
	{ "1.3.14.3.2.22", "rsaKeyTransport" },
	{ "1.3.14.3.2.23", "keyed-hash-seal" },
	{ "1.3.14.3.2.24", "md2WithRSASignature" },
	{ "1.3.14.3.2.25", "md5WithRSASignature" },
	{ "1.3.14.3.2.26", "sha1" },
	{ "1.3.14.3.2.27", "dsaWithSHA1" },
	{ "1.3.14.3.2.28", "dsaCommonWithSHA1" },
	{ "1.3.14.3.2.29", "sha1WithRSASignature" },

Where did the SET group find definitions for {1 2 840 113549 1 1 6} and
{1 2 840 113549 3 10}?

The copy of PKCS-1 on RSA's web site only goes up to {1 2 840 113549 1 1 4}
(md5WithRSAEncryption).  And the S/MIME Implementation Guide only
contains encryptionAlgorithm definitions for {1 2 840 113549 3 2} (RC2-CBC)
and {1 2 840 113549 3 7} (DES-EDE3-CBC).

Date: Fri, 18 Apr 1997 11:34:24 +0000
From: [email-masked] (William A Franklin)
Subject: Address Change
To: [email-masked] ([email-masked]')

 4/18/97

Please change my email address from 

	[email-masked]

		to

	[email-masked]

effective immediately.

Bill Franklin

From: "Lewis, Tony" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Lusk, Steve" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: RSA Encryption OID
Date: Fri, 18 Apr 1997 12:03:07 -0700
Encoding: 77 TEXT

In the original publication of SET on February 23, 1996, SET defined

id-sha-with-rsa-signature OBJECT IDENTIFIER ::= {1 3 14 3 2 15}

When SET was updated on June 24, 1994, it defined

id-sha1-with-rsa-signature OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 5}

This was necessary because the earlier definition described SHA rather
than SHA-1. I don't know when {1 3 14 3 2 29} was defined, but this is
the first time I've heard about it. Given that the cut-off for
requesting changes to SET has passed, I have mixed feelings about this.
On the one hand, I like using a shorter OID in an arc that is managed by
an identified-organization and tweaking this OID for version 1.0 would
not be that difficult to do (provided it happened today). On the other
hand, we are trying to minimize gratuituous last minute changes to SET.

SET also uses the following definitions under RSADSI:

rsaOAEPEncryptionSET OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 6}
id-rsaEncryption OBJECT IDENTIFIER ::= {1 2 840 113549 1 1 1}
id-desDCMF ::= {1 2 840 113549 3 10}

Are any of these others available in the secsig arc?
_________________________________________________________________
Tony Lewis ([email-masked])
Chief Systems Architect, Internet Commerce
Visa International Service Association
>----------
>From: 	Lusk, Steve[SMTP:[email-masked]]
>Sent: 	Friday, April 18, 1997 8:07 AM
>To: 	[email-masked]'
>Cc: 	[email-masked]'
>Subject: 	RSA Encryption OID
>
>Rodney - I took you up on your offer. 
>
>Anyone want to comment on why PKIX choose a different OID than SET did,
>for signatures that use SHA-1 with RSA encryption. Was it an oversight,
>or should we prepare to support both OIDs. 
>
>Steve
>
>
>>----------
>>From: 	Rodney Thayer[SMTP:[email-masked]]
>>Sent: 	Friday, April 18, 1997 8:29 AM
>>To: 	[email-masked]
>>Subject: 	Re: IIS support chaining?
>>
>>so tell the pkix editors, they know the SET people and allegedly are
>>working to address SET's requirements at some point down the road.
>>
>>---Eric Young wrote...
>>>
>>>I still find it anoying that the PKIX standard uses
>>>sha-1WithRSAEncryption 1.3.14.3.2.29
>>>and SET uses
>>>sha-1-with-rsa-signature 1.2.840.113549.1.1.5
>>>
>>>Infact there apears to be complete duplication between these 2 trees :-(
>>>
>>>eric
>>>
>>>
>>>
>>
>>               Rodney Thayer <[email-masked]>       +1 617 332 7292
>>               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
>>               Fax: +1 617 332 7970           http://www.shore.net/~sable
>>                           "Developers of communications software"
>>
>>
>
>

Date: Fri, 18 Apr 1997 11:20:42 -0700
To: "Lusk, Steve" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Peter Williams <[email-masked]>
Subject: Re: RSA Encryption OID

-----=_=_ 146409925-6741220-11202064 _=_=---
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Steve,

Cobol-lovers is a private list, revisting cobol ideas.

On the main point, perhaps PKIX should align itself
with IEEE P1363, and in fact get out of the
algorithm and scheme profiling business altogether.

Perhaps let IEEE do what its good at - detailed engineering of
crypto mechanisms, and let IETF do what its good at - profiling
standard for interoperability.

-----=_=_ 146409925-6741220-11202064 _=_=---
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

-----=_=_ 146409925-6741220-11202064 _=_=-----

Date: Fri, 18 Apr 1997 11:07:57 -0400
From: "Lusk, Steve" <[email-masked]>
Subject: RSA Encryption OID
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>

Rodney - I took you up on your offer. 

Anyone want to comment on why PKIX choose a different OID than SET did,
for signatures that use SHA-1 with RSA encryption. Was it an oversight,
or should we prepare to support both OIDs. 

Steve

>----------
>From: 	Rodney Thayer[SMTP:[email-masked]]
>Sent: 	Friday, April 18, 1997 8:29 AM
>To: 	[email-masked]
>Subject: 	Re: IIS support chaining?
>
>so tell the pkix editors, they know the SET people and allegedly are
>working to address SET's requirements at some point down the road.
>
>---Eric Young wrote...
>>
>>I still find it anoying that the PKIX standard uses
>>sha-1WithRSAEncryption 1.3.14.3.2.29
>>and SET uses
>>sha-1-with-rsa-signature 1.2.840.113549.1.1.5
>>
>>Infact there apears to be complete duplication between these 2 trees :-(
>>
>>eric
>>
>>
>>
>
>               Rodney Thayer <[email-masked]>       +1 617 332 7292
>               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
>               Fax: +1 617 332 7970           http://www.shore.net/~sable
>                           "Developers of communications software"
>
>

Date: Fri, 18 Apr 1997 10:41:09 -0700
To: "G. Mack Hicks, VP Bank of America" <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: PKIX Part I - 4.2.1.5 Change - User Notice Qualifier
Cc: [email-masked], [email-masked], [email-masked]

Mack:

Thanks for the comments.

I propose that we not specify how the files of messages are distributed
and/or made accessible to applications.  This can be left to implementors.
Certainly, one approach would be to "install" a message file in an
application when a root cert is installed.  Another approach is that a user
organization (e.g., a bank) ensures that its applications are configured
with the message files used by the CAs with which it does business.  Also,
note that the "organization" linked with the message file is not
necessarily the CA itself.  For example, the American Bankers Association
might produce a file of standard notice messages for use by bank CAs - all
bank CAs could share that file. Better still, maybe the American Bar
Association or someone else can produce one set of standard notices that
ALL CAs can use - this is the long-term direction I would prefer.

We thought about using a URI.  (You will note that the CPS pointer is dealt
with precisely that way.)  However, for Notices, many people believe a much
more tightly-linked mechanism is needed.  In particular, Notices still need
to work when a system is not on-line to the Web (e.g., when reading all
those signed e-mails in the plane).  From the legal/practices perspective,
it is important that notices be delivered reliably.

If you were not so concerned with reliability and immediacy in your
environment, and preferred to just deal thru the Web, this is still
possible using the User Notices qualifier in conjunction with the CPS URI.
For example, the application could just generate a standard message
automatically, pointing to the CPS for full details.  For example:
 "WARNING: CertRUs Notices Nos. 1,2 apply. See: http://www.certsrus.com/cps". 
(In any case, this is probably a good fall-back in the event the
application does not recognize the particular message number in a cert.)

I think the current proposal is what goes closest to satisfying all needs,
while still giving us a lot of flexibility to try different variations.
Most importantly, we want to keep it simple.

Warwick

At 05:08 PM 4/16/97 -0800, G. Mack Hicks, VP Bank of America wrote:
>I applaud your effort to remove the text notice. The size of the certs
>today are dominated by the text notice. (aside: and some people only see
>key size - that is bits - this is bytes!)
>
>However, your implication that the appliations will contain the text
>notice may be a bit of a problem. My read is that applications would get
>the text and CertsRUs when the CA delivers the root to the application.
>EVERY application ?
>
>I am not of the opinion that most CAs will have established roots in
>every application. (EVERY informed banker I have met says that their
>bank will likely be a CA -- and will have their own root. The US has
>thousands of banks. And no thank you to having the Fed as root.)
>
>Therefore, I would like a URI to be the reference rather
>than a CertsRUs. This could be stored by the repository of the CA.

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

Date: Thu, 17 Apr 97 16:26:22 
From: "Housley, Russ" <[email-masked]>
Encoding: 1162 Text
To: [email-masked], Trevor Freeman <[email-masked]>
Subject: Re: e-mail for certificate distribution

Trevor:

Is this a volunteer statement to write a section for PKIX Part 2 about 
e-mail access to certificate and CRL repository?

Russ

______________________________ Reply Separator _________________________________
Subject: e-mail for certificate distribution
Author:  Trevor Freeman <[email-masked]> at internet
Date:    4/17/97 12:21 PM

pkix part 2 only documents LDAP, FTP and Online Status protocol as a 
means of certificate distribution. However, e-mail seems an equally good 
method, especially for e-mail clients

An email to an address such as [email-masked] with the subject 
line the email address of the user , CA or CRL you require the 
certificate for could be used to send a request. The system can reply 
with the certificate as an attachment.

Also....

Do we need to provide method of certificate retrieval in pkix part 2 for 
each alternate name type defined in pkix part 1?. There seems little 
point in having a name type unless we have a method of using that type.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel: UK(+44) 1734 270 412 
> 

Date: Thu, 17 Apr 1997 20:25:44 -0700
To: Tim Dierks <[email-masked]>
From: Warwick Ford <[email-masked]>
Subject: Re: Extended Key Usage Extension
Cc: [email-masked]

Tim:

At 07:51 PM 4/9/97 -0500, Tim Dierks wrote:
>First, the minor note: id-kp-serverAuth is also consistent with
>digitalSignature, for modes in which the server signs an ephemeral RSA or
>Diffie-Hellman key.

OK.  Shall fix this.

>Also, it is my contention that it would be a good idea to provide values
>for no-serverAuth and no-clientAuth as well. This is an issue that arises
>because implementors need to interoperate with non-PKIX usage spaces and/or
>would like flexibility in certificate use.

As you and Russ both suggest, I don't think this would be practical.  Also,
I am not sure it is needed.  Basically, the CA has to decide if a
certificate is to be limited to a particular purpose or set of purposes
(for example, client authentication and S/MIME) - the CA will have decided
this in order to protect itself from possible risks if its certs are used
for other (envisaged or unenvisaged) purposes.  In this case, the CA should
flag the extended key usage extension critical.

If the CA is not so dogmatic, it can flag the extension noncritical.  In
this case it is up to the cert-using application to decide, on the basis of
information in the cert and other context information, whether or not to
use a cert.  So your TLS web client might, for example, decide to accept
any of the following cert types from a server:
 - a v3 cert with id-kp-serverAuth set;
 - a v3 cert with the appropriate bit set in a Netscape proprietary extension;
 - a v1 cert or v3 cert without the extended key usage extension (in which
case a warning message might be displayed to the user).
The client would expressly not use any cert with an extended key usage
extension without id-kp-serverAuth set, since this is clearly wrong.

>Specifically, let's say I am a TLS web client vendor. For interoperability
>reasons and backwards compatibility, I would like to allow servers to use
>X.509v1 certs and/or non-PKIX compliant X.509v3 certs. Since I cannot deny
>access because id-kp-serverAuth isn't there, I can't keep PKIX compatible
>clients (who I suggest should have no-serverAuth OIDs) from masquerading as
>SSL servers.
>
>You could battle this by marking the extension critical, but this would
>lead to an undesirable lack of flexibility: when we introduce secure
>telephony, one wouldn't be able to use a TLS client certificate for secure
>telephony because it presumably wouldn't have an
>id-kp-watsonComeHereINeedYou OID (which hadn't been invented when the cert
>was signed), even though the policy and distinguished name of the
>certificate might allow it.
>
>On the other hand, I suppose that it would be bad to have to list all the
>various things a certificate can't do, as well: id-kp-serverAuth,
>id-kp-breakTheLaw, id-kp-enableDoomsdayDevice, etc.
>
> - Tim

Warwick

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

From: <[email-masked]>
Date: Thu, 17 Apr 1997 16:10:42 -0600
To: [email-masked]
Subject: authorityInfoAccess ATTRIBUTE

<bigger>A request was made at the WG in Memphis to define
AuthorityInfoAccess as an ATTRIBUTE to enable its inclusion in a PKCS 7
message.  When included in a PKCS 7 message, this attribute can be used
to identify and locate certificates associated with the message rather
than include the certificates directly, thereby reducing the size of the
encapsulated message (or object).

</bigger>

Following is a proposed amendement to section 4.2.2.2 of PKIX Part 1
responding to this requirement.

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

4.2.2.2  Authority Information Access

(To the existing text, append the following:)

The authorityInfoAccess extension may be included in a PKCS 7
encapsulation as an X.501 ATTRIBUTE.  This attribute can then be used to
locate certificates automatically rather than include the certificates
directly.  The intended effect is to reduce the size of the encapsulated
message or object.

PKCS 9 identifies attributes for inclusion in PKCS 7, referencing X.520
standard attributes and defining additional attributes unique to PKCS 9. 
The attributes defined in X.520 are based on the definition of ATTRIBUTE
in ITU-T X.501 | ISO/IEC 9594-2.

The following syntax defines authorityInfoAccess as an ATTRIBUTE suitable
for inclusion in a PKCS 7 message:

authorityInfoAccess ATTRIBUTE ::= {

    WITH SYNTAX    authorityInfoAccessSyntax,

    ID             id-pkix-authorityInfoAccess }

PKIX Part 2 establishes requirements on certificate retrieval mechanisms.
 It is expected that applications using the URI form of the authorityInfo
field for such a purpose will:

1.  Prepend a suitable HTTP retrieval primitive to the URL (e.g. 
"GET").

2.  Append a filename to the URL.

3.  Use the result to retrieve a file containing the requested
certificate.

4.  Use the authorityInfoAccess extension in that and subsequent
certificates to complete a certificate path.

The filename will be formed as the IA5string representation of SHA1(
Issuer DN | certificate serial number) concatenated with ".cer."  The
SignerInfo syntax of PKCS 7 provides the necessary information as
issuerAndSerialNumber.

The specified file will contain a single DER encoded certficate.

Sender: "Tim Howes" <[email-masked]>
Date: Thu, 17 Apr 1997 10:47:16 -0700
From: Tim Howes <[email-masked]>
Organization: Netscape Communications Corp.
To: Sharon Boeyen <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "'G. Mack Hicks, VP Bank of America'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Subject: Re: PKIX Part 2 Questions - Authenticated & Signed LDAP response ?

Sharon Boeyen wrote:
> 
> Mack, thanks for the observations and comments.
> 
> As a general comment - PKIX Part 2, for its use of LDAP, is currently
> based on LDAP v2 not v3. When LDAP v3 reaches a more stable state we do
> intend to look at it and may move from LDAP v2 to v3 in PKIX.
> 
> Below are my initial comments on the PKIX part 2 issues.
> 
> Tim - can you comment on the current LDAP v3 spec and how it handles the
> issues raised by Mack?

Sure, see below.

> >"A Public-Key Search service MAY implement authenticated search access."
> >
> >Did the authors have other ideas about how LDAPv3 authentication can be
> >achieved other than session level (SSL) and SASL? Simple passwords are
> >being discouraged on open networks.
> 
> Nothing specific defined at this time. LDAP v3 will have some additional
> authentication support that we will look at (including those you mention
> as well asanother InternetDraft on X.509 based strong authentication for
> LDAP also) but until the LDAP v3 is solid (and I confess I had to leave
> Memphis before the asid meeting, so I don't know what happened there -
> Tim?)

At the memphis ASID meeting, several relatively minor changes
to the core LDAPv3 documents were agreed upon. The plan is to
revise the documents, publish to the list (eta this weekend),
and issue a working group last call. Assuming that goes well
(it should - but keep your fingers crossed!), we progress to
the IESG for proposed standard.

> >2.1.2.2 SearchResponse
> >
> >"An application providing LDAP repository read service over LDAPv2 MUST
> >implement the full SearchResponse."
> >
> >If an entry has multiple certificates, does the quoted statement mean
> >that ALL certificates for the entry have to be returned upon any query?
> >I did not see any granularity in the LDAPv3 spec that would allow for
> >specification within a query of a particular certificate--say by serial
> >number, CA, validity period, public key usage.
> 
> I think the feature you are looking for is the extensible match filter
> in the 93 X.511. LDAP v2 does not include this - Tim can you comment on
> the LDAP v3 spec with respect to extensible match? X.509 (1997) includes
> a detailed set of matching rules for both certificates and crls that can
> be used in the extensible match filter.
> 
> Tim does the current LDAP v3 include extensible match?

Yes, LDAPv3 includes extensible matching, pretty much just like
it is in X.500.                        -- Tim

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: e-mail for certificate distribution
Date: Thu, 17 Apr 1997 10:15:50 -0700

pkix part 2 only documents LDAP, FTP and Online Status protocol as a
means of certificate distribution. However, e-mail seems an equally good
method, especially for e-mail clients

An email to an address such as [email-masked] with the subject
line the email address of the user , CA or CRL you require the
certificate for could be used to send a request. The system can reply
with the certificate as an attachment.

Also....

Do we need to provide method of certificate retrieval in pkix part 2 for
each alternate name type defined in pkix part 1?. There seems little
point in having a name type unless we have a method of using that type.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel: UK(+44) 1734 270 412 
> 

From: Sharon Boeyen <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'G. Mack Hicks, VP Bank of America'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "'Tim Howes'" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Subject: RE: PKIX Part 2 Questions - Authenticated & Signed LDAP response ?
Date: Thu, 17 Apr 1997 11:01:14 -0400
Encoding: 253 TEXT

Mack, thanks for the observations and comments.

As a general comment - PKIX Part 2, for its use of LDAP, is currently
based on LDAP v2 not v3. When LDAP v3 reaches a more stable state we do
intend to look at it and may move from LDAP v2 to v3 in PKIX.

Below are my initial comments on the PKIX part 2 issues.  

Tim - can you comment on the current LDAP v3 spec and how it handles the
issues raised by Mack?

Mike can you add some insight to the OCSP issues Mack raises?

As agreed in Memphis, we will also be adding to PKIX part 2 the LDAP
operations profile required for the CA to add/delete certificate and crl
information for the repository. I also have other comments received on
the document and hope to have an update available sometime in May
(always an optimist!)

------------------
Sharon Boeyen                 
Entrust Technologies
mailto:[email-masked]       Tel: (613) 765-4931
http://www.entrust.com          Fax: (613) 765-3520

         Orchestrating Enterprise Security

>----------
>From: 	G. Mack Hicks, VP Bank of America[SMTP:[email-masked]]
>Sent: 	April 16, 1997 8:37 PM
>To: 	[email-masked]
>Cc: 	[email-masked]; [email-masked]
>Subject: 	PKIX Part 2 Questions - Authenticated & Signed LDAP response ?
>
>
>For IETF PKIX Mailing list
>
>RE: PKIX Part 2 - <draft-ietf-pkix-ipki2opp-00.txt>
>
>Questions
>
>2.1.1.1 Bind Request
>
>"simpleauth ... MUST accept NULL simple"
>
>Pardon please my lack of understanding of this line.
>The implication is that LDAP authentication is not allowed?
>Or that a null password must be allowed -- a strange concept?
>If authentication is allowed, may the other authentication
>methods of LDAPv3 be used (specifically SASL)?
>
>LDAPv3 does allow for session based queries to use session level
>authentication like SSLv3. May a PKIX Part 2 compliant directory use
>SSLv3 client authentication?
>
>"A LDAP repository read service SHOULD implement some level of anonymous
>search access."

On the authentication issue, to clarify:

Both anonymous and simple password based authentication are included in
PKIX part 2. From an implementation standpoint, anonymous binds should
be supported and authenticated binds may also be supported.

Remember that implementation and deployment are different. What this
means to an entity deploying a service is that any product conforming to
this aspect of PKIX Part 2 should be able to support the anonymous bind
but not all will necessarily support the simple bind.  When deploying a
service, you set your own requirements and not all products may suit
your needs.

>
>May a PKIX Part 2 compliant directory reply with "unwillingToPerform"
>for unauthenticated LDAP queries?

YES - and you may also choose not to accept anonymous binds and respond
with the "inappropriateAuthentication" error in the bindResponse (see
2.1.1.2)

>"A Public-Key Search service MAY implement authenticated search access."
>
>Did the authors have other ideas about how LDAPv3 authentication can be
>achieved other than session level (SSL) and SASL? Simple passwords are
>being discouraged on open networks.

Nothing specific defined at this time. LDAP v3 will have some additional
authentication support that we will look at (including those you mention
as well asanother InternetDraft on X.509 based strong authentication for
LDAP also) but until the LDAP v3 is solid (and I confess I had to leave
Memphis before the asid meeting, so I don't know what happened there -
Tim?)
 
>2.1.2.2 SearchResponse
>
>"An application providing LDAP repository read service over LDAPv2 MUST
>implement the full SearchResponse."
>
>If an entry has multiple certificates, does the quoted statement mean
>that ALL certificates for the entry have to be returned upon any query?
>I did not see any granularity in the LDAPv3 spec that would allow for
>specification within a query of a particular certificate--say by serial
>number, CA, validity period, public key usage.

I think the feature you are looking for is the extensible match filter
in the 93 X.511. LDAP v2 does not include this - Tim can you comment on
the LDAP v3 spec with respect to extensible match? X.509 (1997) includes
a detailed set of matching rules for both certificates and crls that can
be used in the extensible match filter.

Tim does the current LDAP v3 include extensible match?
>
>2.3 Transport
>
>"An ... LDAP repository ... service MUST support LDAPv2 transport
>over TCP ... "
>
>Does this statement prohibit the use of UDP (since it is unreliable)?
>Does this statement prohibit the use of SSLv3 with client authentication?

This statement doesn't prohibit anything. It only says what MUST be
supported. 
>
>2.4 Security Considerations
>
>" <snip>
>  ... CAs should bind to the repository with a minimum of
>  simple authentication."
>
>Simple authentication is password based.
>Will the CA be expected to provide a password to each subscriber or user?

No, the intent of this statement is that when a CA is accessing the
repository it should be using simple authentication, whereas end user
searching is generally ok anonymously.
>
>Section 4 - Online Certificate Status Protocol (OCSP)
>
>Comment
>
>This is a good first effort to a difficult subject.  The problem
>I see is that implementations of browsers, emailers, and other
>certificate aware applications will not present to the end user
>a certificate in a way that would allow the end user (recipient)
>to utilize a browser based function.
>
>Most appliations will have already written an LDAP enabled environment.
>Augmenting the LDAP response to include OCSP response in an LDAPv3
>extension would be suitable. Applications that would like to keep the
>signed validity response could do so -- those that are not capable of
>supporting the response would ignore the field (a non-critical extension
>to LDAPv3). LDAP repositories that did not support the extension would
>not be penalized since unrecognized extensions must be ignored.

One of the environments where OCSP is expected to fit is that where
directory protocols are not implemented. Are you proposing adding a
second protocol for OCSP (in addition to HTTP) or replacing the HTTP
version with an LDAP one?
I prefer not to see a lot of different ways standardized for
accomplishing the same task because that inevitably result in
interoperability issues further down the road.

> 
>
>4.1.2 Response
>
>"authenticated with the responding CA's digital signature."
>
>The may be a problem for the CA since the signature for a certificate
>requires the use of the CA private key which would likely be strongly
>protected.

OCSP is currently defined as a protocol between an application
(generally a certificate using system or relying party) and the
certificate issuer or CA - the repository, as a separate entity isn't
really addressed in this protocol. However, the issue of signatures (how
many and which ones) probably needs to be addressed for processing
certificate chains and dealing with scalability issues for these
services. Mike?

>I suggest: Signing by the repository.
>           I realize that the user would need the repository's
>           certificate.  LDAP could be used to get the key.
>           The repository could return a certificate signed by
>           the CA in question.  This CA public key would already
>           by in the certificate in question.
>
>4.2.1 Definition of Services
>
>"... 1) certificate path validation ..."
>
>I think I know what this means: A request to validate each step in the
>queried certificate chain. But I can find no reference in the PKIX
>literature. (Sorry if I missed it.)

Thanks for finding this. I'll do a search on the other docs too and if
there isn't a definition, we can add one.
>
>4.2.2 Error Response
>
>4th paragraph "... response as described in Section 2.1.2"
>
>(I think this has already been mentioned in the list - pardon me.)
>2.1.2 should read 2.1.1.2 IMHO.
>
>"The means by which a CA signals to a relying party which
>error behavior is offered should be through certificate contents."
>
>I would like a reference to PKIX Part 1 to the appropriate extension and
>to the PKIX Part 3 to the appropriate section. I may have missed this
>one in my readings.
>
>4.3.1.1 Query Syntax
>
>"OSCP_query        :    url request version cert_id"
>
>I cannot find "version" defined. (Again likely to have already been
>mentioned.)
>
>==============================
>
>In short, can an online authenticated query using LDAP have a returned
>response (OSCP) in an LDAPv3 extension?

Not currently. The two services are totally different. The LDAP service
is for retrieving information from a repository. The OCSP is for
contacting a CA to get confirmation directly from the CA. Can you
elaborate on what the specific requirement is and what sort of
environment you're addressing?  Are you looking for authentication on
LDAP services, in a CRL environment where the relying party identity is
required by the repository provider, or for an LDAP protocol
implmentation of a yes/no certificate status check? A fundamental
difference between these two services is where the decision on validity
actually takes place. In LDAP the decision is made by the relying party,
after retrieving all the relevant information, crls arls etc, while in
OCSP, the decision on the validity is made by the CA and the relying
party should receive enough information to assure itself that the
decision is correct (e.g. that the response is for the same certificate
as the request was, that the responder has the authority to make that
statement, etc). If dealing with a certificate chain, either the relying
party needs to get these assurances from each CA in the chain or have
the "trust" in the CA that provides the total service to them.  Mike
anything to add?

>If so, would this be part of the Section 4 - OSCP or part of Section 2 -
>LDAP?
>
>===============================================================
>Mack Hicks (415) 278-7230  -- Interactive Banking Division
>425 1st St m/s3671, SF CA 94105 <[email-masked]>
>

Date: Thu, 17 Apr 1997 10:14:41 -0500 (CDT)
To: [email-masked]
From: Karl Nagel <[email-masked]>
Subject: subscribe

subscribe

==================================================================
                       Karl D. Nagel, CPA
             Karl Nagel & Co.  o  Accounting & Consulting Services
4108 Highland Ave., Suite 102  o  Manhattan Beach, CA 90266
         Tel (310) 546 - 6138  o  Fax (310) 546 - 7048
   E-mail: [email-masked]  o  Web: www.karlnagel.com
==================================================================
               "Fortune favors the brave" - Terence

Date: Thu, 17 Apr 1997 09:49:06 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: PKIX Part I - 4.2.1.5 Change - User Notice Qualifier

> From: "G. Mack Hicks, VP Bank of America" <[email-masked]>
>
>  [...]
>
> However, your implication that the appliations will contain the text
> notice may be a bit of a problem. My read is that applications would get
> the text and CertsRUs when the CA delivers the root to the application.
> EVERY application ?
> 
> I am not of the opinion that most CAs will have established roots in
> every application. (EVERY informed banker I have met says that their
> bank will likely be a CA -- and will have their own root. The US has
> thousands of banks. And no thank you to having the Fed as root.)
> 
> Therefore, I would like a URI to be the reference rather
> than a CertsRUs. This could be stored by the repository of the CA.

I don't think it's necessary or even implied that the data in the
"notice file" must come from "the root".  Every CA, regardless of
it's position in the validation path, may have textual notices. Those
notices could be created by the individual CA, published by the Fed
for any willing bank-CA to reference, standardized and published by
ANSI X9, or whatever.

It may make sense to include the notices in CA certs, but save space
by never including them in end-entity certs.  End entities could reference
notices from anywhere in the cert path, not just from the immediate issuer,
so CAs could inherit notices from higher-level CAs.

I'm not opposed to having a URI as an option, but it raises the question
of whether the CA could unilaterally change it's terms and conditions
just by updating the contents referenced by the URI.  With notices contained
in certs or notice files on the client machine, it's a little harder for
the CA to switch in midstream.

Sender: [email-masked]
Date: Thu, 17 Apr 1997 08:23:06 +0200
From: Jochen Keutel <[email-masked]>
To: [email-masked]
Subject: how to unsubscribe?

Hello,
  I'd like to unsubscribe ... But neither ietf-pkix-request nor
majordomo seems to work ...

Bye,
                Jochen.

X400-Received: by /c=US/admd=attmail/; Relayed; 16 Apr 97 17:08:03 -0800
X400-Received: by mta BofA-MTA in /c=US/admd=attmail/; Relayed;  16 Apr 97 17:08:03 -0800
X400-Mts-Identifier: [/c=US/admd=attmail/; 021AB335569E3003-attmail]
Content-Identifier: 021AB335569E3003
Content-Return: Allowed
X400-Content-Type:  P2-1984 ( 2 )
Conversion: Allowed
Conversion-With-Loss: Allowed
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date: 16 Apr 97 17:08:03 -0800
From: "G. Mack Hicks, VP Bank of America" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: PKIX Part I - 4.2.1.5 Change - User Notice Qualifier

Subject: PKIX Part I - 4.2.1.5 Change - User Notice Qualifier

Warwick Ford - Wrote

<snip>
The noticeRef option, if used, names an organization and identifies, by
number, a particular textual statement prepared by that organization.  For
example, it might identify the organization "CertsRUs" and notice number 1.
 In a typical implementation, the application software will have a notice
file containing the current set of notices for CertsRUs; the application
will extract the notice text from the file and display it.  Messages may be
multilingual, allowing the software to select the particular language
message for its own environment.

An explicitText option is also available, as before, but this option is
less flexible and cannot support multilingual messages.

  end quote

==============================

Warwick,

I applaud your effort to remove the text notice. The size of the certs
today are dominated by the text notice. (aside: and some people only see
key size - that is bits - this is bytes!)

However, your implication that the appliations will contain the text
notice may be a bit of a problem. My read is that applications would get
the text and CertsRUs when the CA delivers the root to the application.
EVERY application ?

I am not of the opinion that most CAs will have established roots in
every application. (EVERY informed banker I have met says that their
bank will likely be a CA -- and will have their own root. The US has
thousands of banks. And no thank you to having the Fed as root.)

Therefore, I would like a URI to be the reference rather
than a CertsRUs. This could be stored by the repository of the CA.

X400-Received: by /c=US/admd=attmail/; Relayed; 16 Apr 97 16:37:50 -0800
X400-Received: by mta BofA-MTA in /c=US/admd=attmail/; Relayed;  16 Apr 97 16:37:50 -0800
X400-Mts-Identifier: [/c=US/admd=attmail/; 00ED9335562CE00C-attmail]
Content-Identifier: 00ED9335562CE00C
Content-Return: Allowed
X400-Content-Type:  P2-1984 ( 2 )
Conversion: Allowed
Conversion-With-Loss: Allowed
Priority: normal
Disclose-Recipients: Prohibited
Alternate-Recipient: Allowed
X400-Originator: [email-masked]
X400-Recipients: non-disclosure;
Date: 16 Apr 97 16:37:50 -0800
From: "G. Mack Hicks, VP Bank of America" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: PKIX Part 2 Questions - Authenticated & Signed LDAP response ?

For IETF PKIX Mailing list

RE: PKIX Part 2 - <draft-ietf-pkix-ipki2opp-00.txt>

Questions

2.1.1.1 Bind Request

"simpleauth ... MUST accept NULL simple"

Pardon please my lack of understanding of this line.
The implication is that LDAP authentication is not allowed?
Or that a null password must be allowed -- a strange concept?
If authentication is allowed, may the other authentication
methods of LDAPv3 be used (specifically SASL)?

LDAPv3 does allow for session based queries to use session level
authentication like SSLv3. May a PKIX Part 2 compliant directory use
SSLv3 client authentication?

"A LDAP repository read service SHOULD implement some level of anonymous
search access."

May a PKIX Part 2 compliant directory reply with "unwillingToPerform"
for unauthenticated LDAP queries?

"A Public-Key Search service MAY implement authenticated search access."

Did the authors have other ideas about how LDAPv3 authentication can be
achieved other than session level (SSL) and SASL? Simple passwords are
being discouraged on open networks.

2.1.2.2 SearchResponse

"An application providing LDAP repository read service over LDAPv2 MUST
implement the full SearchResponse."

If an entry has multiple certificates, does the quoted statement mean
that ALL certificates for the entry have to be returned upon any query?
I did not see any granularity in the LDAPv3 spec that would allow for
specification within a query of a particular certificate--say by serial
number, CA, validity period, public key usage.

2.3 Transport

"An ... LDAP repository ... service MUST support LDAPv2 transport
over TCP ... "

Does this statement prohibit the use of UDP (since it is unreliable)?
Does this statement prohibit the use of SSLv3 with client authentication?

2.4 Security Considerations

" <snip>
  ... CAs should bind to the repository with a minimum of
  simple authentication."

Simple authentication is password based.
Will the CA be expected to provide a password to each subscriber or user?

Section 4 - Online Certificate Status Protocol (OCSP)

Comment

This is a good first effort to a difficult subject.  The problem
I see is that implementations of browsers, emailers, and other
certificate aware applications will not present to the end user
a certificate in a way that would allow the end user (recipient)
to utilize a browser based function.

Most appliations will have already written an LDAP enabled environment.
Augmenting the LDAP response to include OCSP response in an LDAPv3
extension would be suitable. Applications that would like to keep the
signed validity response could do so -- those that are not capable of
supporting the response would ignore the field (a non-critical extension
to LDAPv3). LDAP repositories that did not support the extension would
not be penalized since unrecognized extensions must be ignored.

4.1.2 Response

"authenticated with the responding CA's digital signature."

The may be a problem for the CA since the signature for a certificate
requires the use of the CA private key which would likely be strongly
protected.

I suggest: Signing by the repository.
           I realize that the user would need the repository's
           certificate.  LDAP could be used to get the key.
           The repository could return a certificate signed by
           the CA in question.  This CA public key would already
           by in the certificate in question.

4.2.1 Definition of Services

"... 1) certificate path validation ..."

I think I know what this means: A request to validate each step in the
queried certificate chain. But I can find no reference in the PKIX
literature. (Sorry if I missed it.)

4.2.2 Error Response

4th paragraph "... response as described in Section 2.1.2"

(I think this has already been mentioned in the list - pardon me.)
2.1.2 should read 2.1.1.2 IMHO.

"The means by which a CA signals to a relying party which
error behavior is offered should be through certificate contents."

I would like a reference to PKIX Part 1 to the appropriate extension and
to the PKIX Part 3 to the appropriate section. I may have missed this
one in my readings.

4.3.1.1 Query Syntax

"OSCP_query        :    url request version cert_id"

I cannot find "version" defined. (Again likely to have already been
mentioned.)

==============================

In short, can an online authenticated query using LDAP have a returned
response (OSCP) in an LDAPv3 extension?

If so, would this be part of the Section 4 - OSCP or part of Section 2 -
LDAP?

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

Date: Wed, 16 Apr 1997 17:40:39 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: PKIX Part I - 4.2.1.5 Change - User Notice Qualifier

Regarding the User Notice qualifier for the Certificate Policies extension,
I propose extending the syntax to allow for references to message texts as
an alternative to embedding the text in the certificate.  This can save
space significantly, while providing CAs with flexibility in making
different notice messages available.

The proposed new ASN.1 is as follows:

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

NoticeReference ::= SEQUENCE {
  organization  IA5String,
  noticeNumbers SEQUENCE OF INTEGER }

DisplayText ::= CHOICE {
  visibleString VisibleString,
  bmpString     BMPString }

The noticeRef option, if used, names an organization and identifies, by
number, a particular textual statement prepared by that organization.  For
example, it might identify the organization "CertsRUs" and notice number 1.
 In a typical implementation, the application software will have a notice
file containing the current set of notices for CertsRUs; the application
will extract the notice text from the file and display it.  Messages may be
multilingual, allowing the software to select the particular language
message for its own environment.

An explicitText option is also available, as before, but this option is
less flexible and cannot support multilingual messages.

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

Organization: ESAT, K.U.Leuven, Belgium
Date: Wed, 16 Apr 1997 16:38:20 +0200
To: [email-masked]
From: Filip Mertens <[email-masked]>
Subject: cross certification question

Hello,

can someone help me with the following question:

How do you make a cross certificate in X.509?
Do you just have to make an ordinary public key 
certificate, or do you also need to specify things
in some basic fields or in some extensions?
Is there some documentation about it?

                        Greetings, Filip

[email-masked]

Date: Tue, 15 Apr 1997 20:17:38 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: samples

This are useful samples.  I don't want to burden the documents, I'm
sensitive to the size of the document as it stands, but given the
(stone-age abysmal) state of the art in tools, samples are good.  Samples
make people able to understand how useful this stuff is and can be.

At 10:31 AM 4/15/97 -0400, you wrote:
>
>Tim and others,
>
>  At one of the wg sessions in Memphis, a desire was expressed for
>clearer certificate examples to go in PKIX Part 1, section 8.
>I don't know if the following examples are clearer, but they are
>different from the current ones :-).
>
>Please let me know if the formats are useful, and if so, how they could
>be improved.  The first example is from an X.509v3 certificate decoder,
>the second is the identical data decoded by a BER parser that has no
>certificate-specific knowledge.
>
>(Note: the Issuer name below is displayed in normal order, the Subject 
> name is in LDAP-bass-ackwards order.  For a real example, they should
> probably both be in the same order.)
>
>       Dave Kemp
>
>------------------------------- printcert ----------------------------
>
>      Version: v3
>Serial Number: 256
>Signature Alg: md2WithRSAEncryption (1.2.840.113549.1.1.2)
>       Issuer: C=ES, O=Universitat Politecnica de Catalunya, OU=Dept.
Arquitectura de Computadors
>     Validity: 960722173802Z
>             : 970722173802Z
>      Subject: CN=Francisco Jordan, OU=Dept. Arquitectura de Computadors,
O=Universitat Politecnica de Catalunya, C=ES
>SubjectPKInfo: rsaEncryption (1.2.840.113549.1.1.1)
>   Public Key:
>        00 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f
>        2f b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48
>        1e 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff
>        63 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1
>        33 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50
>        a9 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94
>        78 56 15 c6 1c 8b 02 03 01 00 01
>    issuerUID:
>   subjectUID:
> 6 extensions:
>     Exten  1:   authorityKeyIdentifier (2.5.29.35)        
>        30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf
>        04 ea 04 c3
>     Exten  2: ! keyUsage (2.5.29.15)        
>        03 02 07 80
>     Exten  3:   certificatePolicies (2.5.29.32)        
>        30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05
>        2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01
>        0a
>     Exten  4:   subjectAltName (2.5.29.17)        
>        30 81 80 81 10 6a 6f 72 64 61 6e 40 61 63 2e 75
>        70 63 2e 65 73 86 11 68 74 74 70 3a 2f 2f 61 63
>        2e 75 70 63 2e 65 73 2f a0 59 06 03 55 04 10 a0
>        52 30 50 13 14 44 72 2e 20 46 72 61 6e 63 69 73
>        63 6f 20 4a 6f 72 64 61 6e 13 05 55 2e 50 2e 43
>        13 19 43 2f 20 47 72 61 6e 20 43 61 70 69 74 61
>        20 73 6e 2c 20 4d 6f 64 2d 44 36 13 16 30 38 30
>        37 31 2d 42 61 72 63 65 6c 6f 6e 61 2c 20 53 70
>        61 69 6e
>     Exten  5: ! basicConstraints (2.5.29.19)        
>        30 00
>     Exten  6:   issuerAltName (2.5.29.18)        
>        30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75
>        70 63 2e 65 73 2f
>Signature Alg: md2WithRSAEncryption (1.2.840.113549.1.1.2)
>    Sig Value:
>        00 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04
>        ea 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a
>        ab eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c
>        91 a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6
>        50 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04
>        ea 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a
>        ab eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c
>        91 a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6
>        50
>
>
>------------------------------- printber ----------------------------
>
>
>offs tag lenbytes length        value
>---- -- --------- ---  ----------------------
>0000 30 80        859: SEQUENCE 
>0002 30 82 02 c0  704: . SEQUENCE 
>0006 a0 03          3: . . [0] 
>0008 02 01          1: . . . INTEGER 2
>0011 02 02          2: . . INTEGER 256
>0015 30 0d         13: . . SEQUENCE 
>0017 06 09          9: . . . OID 1.2.840.113549.1.1.2: md2WithRSAEncryption
>0028 05 00          0: . . . NULL 
>0030 30 68        104: . . SEQUENCE 
>0032 31 0b         11: . . . SET 
>0034 30 09          9: . . . . SEQUENCE 
>0036 06 03          3: . . . . . OID 2.5.4.6: C
>0041 13 02          2: . . . . . PrintableString  'ES'
>0045 31 2d         45: . . . SET 
>0047 30 2b         43: . . . . SEQUENCE 
>0049 06 03          3: . . . . . OID 2.5.4.10: O
>0054 13 24         36: . . . . . PrintableString  'Universitat Politecnica
de Catalunya'
>0092 31 2a         42: . . . SET 
>0094 30 28         40: . . . . SEQUENCE 
>0096 06 03          3: . . . . . OID 2.5.4.11: OU
>0101 13 21         33: . . . . . PrintableString  'Dept. Arquitectura de
Computadors'
>0136 30 1e         30: . . SEQUENCE 
>0138 17 0d         13: . . . UTCTime  '960722173802Z'
>0153 17 0d         13: . . . UTCTime  '970722173802Z'
>0168 30 81 83     131: . . SEQUENCE 
>0171 31 0b         11: . . . SET 
>0173 30 09          9: . . . . SEQUENCE 
>0175 06 03          3: . . . . . OID 2.5.4.6: C
>0180 13 02          2: . . . . . PrintableString  'ES'
>0184 31 2d         45: . . . SET 
>0186 30 2b         43: . . . . SEQUENCE 
>0188 06 03          3: . . . . . OID 2.5.4.10: O
>0193 13 24         36: . . . . . PrintableString  'Universitat Politecnica
de Catalunya'
>0231 31 2a         42: . . . SET 
>0233 30 28         40: . . . . SEQUENCE 
>0235 06 03          3: . . . . . OID 2.5.4.11: OU
>0240 13 21         33: . . . . . PrintableString  'Dept. Arquitectura de
Computadors'
>0275 31 19         25: . . . SET 
>0277 30 17         23: . . . . SEQUENCE 
>0279 06 03          3: . . . . . OID 2.5.4.3: CN
>0284 13 10         16: . . . . . PrintableString  'Francisco Jordan'
>0302 30 7c        124: . . SEQUENCE 
>0304 30 0d         13: . . . SEQUENCE 
>0306 06 09          9: . . . . OID 1.2.840.113549.1.1.1: rsaEncryption
>0317 05 00          0: . . . . NULL 
>0319 03 6b        107: . . . BIT STRING  (0 unused bits)
>                     : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
>                     : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
>                     : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
>                     : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
>                     : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
>                     : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
>                     : 56 15 c6 1c 8b 02 03 01 00 01
>0428 a3 82 01 16  278: . . [3] 
>0432 30 82 01 12  274: . . . SEQUENCE 
>0436 30 1b         27: . . . . SEQUENCE 
>0438 06 03          3: . . . . . OID 2.5.29.35: authorityKeyIdentifier
>0443 04 14         20: . . . . . OCTET STRING 
>                     : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf
>                     : 04 ea 04 c3
>0465 30 0e         14: . . . . SEQUENCE 
>0467 06 03          3: . . . . . OID 2.5.29.15: keyUsage
>0472 01 01          1: . . . . . BOOLEAN ff: True
>0475 04 04          4: . . . . . OCTET STRING 
>                     : 03 02 07 80
>0481 30 28         40: . . . . SEQUENCE 
>0483 06 03          3: . . . . . OID 2.5.29.32: certificatePolicies
>0488 04 21         33: . . . . . OCTET STRING 
>                     : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05
>                     : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01
>                     : 0a
>0523 30 81 8b     139: . . . . SEQUENCE 
>0526 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
>0531 04 81 83     131: . . . . . OCTET STRING 
>                     : 30 81 80 81 10 6a 6f 72 64 61 6e 40 61 63 2e 75
>                     : 70 63 2e 65 73 86 11 68 74 74 70 3a 2f 2f 61 63
>                     : 2e 75 70 63 2e 65 73 2f a0 59 06 03 55 04 10 a0
>                     : 52 30 50 13 14 44 72 2e 20 46 72 61 6e 63 69 73
>                     : 63 6f 20 4a 6f 72 64 61 6e 13 05 55 2e 50 2e 43
>                     : 13 19 43 2f 20 47 72 61 6e 20 43 61 70 69 74 61
>                     : 20 73 6e 2c 20 4d 6f 64 2d 44 36 13 16 30 38 30
>                     : 37 31 2d 42 61 72 63 65 6c 6f 6e 61 2c 20 53 70
>                     : 61 69 6e
>0665 30 0c         12: . . . . SEQUENCE 
>0667 06 03          3: . . . . . OID 2.5.29.19: basicConstraints
>0672 01 01          1: . . . . . BOOLEAN ff: True
>0675 04 02          2: . . . . . OCTET STRING 
>                     : 30 00
>0679 30 1d         29: . . . . SEQUENCE 
>0681 06 03          3: . . . . . OID 2.5.29.18: issuerAltName
>0686 04 16         22: . . . . . OCTET STRING 
>                     : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75
>                     : 70 63 2e 65 73 2f
>0710 30 80         15: . SEQUENCE 
>0712 06 09          9: . . OID 1.2.840.113549.1.1.2: md2WithRSAEncryption
>0723 05 00          0: . . NULL 
>0727 03 81 81     129: . BIT STRING  (0 unused bits)
>                     : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
>                     : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
>                     : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
>                     : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
>                     : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
>                     : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
>                     : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
>                     : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
>
>

Date: Tue, 15 Apr 1997 16:46:20 -0400
To: [email-masked]
From: "Kevin L. Hawkins" <[email-masked]>
Subject: unsubscribe

unsubscribe

Kevin L. Hawkins, Manager
FedWorld System Office

Phone: 703.321.0024		
Fax:   703.321.0081
email: [email-masked]

Date: Tue, 15 Apr 1997 15:07:25 -0400
To: [email-masked]
From: "Kevin L. Hawkins" <[email-masked]>
Subject: unsubscribe

unsubscribe

Kevin L. Hawkins, Manager
FedWorld System Office

Phone: 703.321.0024		
Fax:   703.321.0081
email: [email-masked]

Date: Tue, 15 Apr 1997 10:31:58 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: pkix part 1, draft 4
Cc: [email-masked]

Tim and others,

  At one of the wg sessions in Memphis, a desire was expressed for
clearer certificate examples to go in PKIX Part 1, section 8.
I don't know if the following examples are clearer, but they are
different from the current ones :-).

Please let me know if the formats are useful, and if so, how they could
be improved.  The first example is from an X.509v3 certificate decoder,
the second is the identical data decoded by a BER parser that has no
certificate-specific knowledge.

(Note: the Issuer name below is displayed in normal order, the Subject 
 name is in LDAP-bass-ackwards order.  For a real example, they should
 probably both be in the same order.)

       Dave Kemp

------------------------------- printcert ----------------------------

      Version: v3
Serial Number: 256
Signature Alg: md2WithRSAEncryption (1.2.840.113549.1.1.2)
       Issuer: C=ES, O=Universitat Politecnica de Catalunya, OU=Dept. Arquitectura de Computadors
     Validity: 960722173802Z
             : 970722173802Z
      Subject: CN=Francisco Jordan, OU=Dept. Arquitectura de Computadors, O=Universitat Politecnica de Catalunya, C=ES
SubjectPKInfo: rsaEncryption (1.2.840.113549.1.1.1)
   Public Key:
        00 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f
        2f b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48
        1e 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff
        63 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1
        33 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50
        a9 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94
        78 56 15 c6 1c 8b 02 03 01 00 01
    issuerUID:
   subjectUID:
 6 extensions:
     Exten  1:   authorityKeyIdentifier (2.5.29.35)        
        30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf
        04 ea 04 c3
     Exten  2: ! keyUsage (2.5.29.15)        
        03 02 07 80
     Exten  3:   certificatePolicies (2.5.29.32)        
        30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05
        2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01
        0a
     Exten  4:   subjectAltName (2.5.29.17)        
        30 81 80 81 10 6a 6f 72 64 61 6e 40 61 63 2e 75
        70 63 2e 65 73 86 11 68 74 74 70 3a 2f 2f 61 63
        2e 75 70 63 2e 65 73 2f a0 59 06 03 55 04 10 a0
        52 30 50 13 14 44 72 2e 20 46 72 61 6e 63 69 73
        63 6f 20 4a 6f 72 64 61 6e 13 05 55 2e 50 2e 43
        13 19 43 2f 20 47 72 61 6e 20 43 61 70 69 74 61
        20 73 6e 2c 20 4d 6f 64 2d 44 36 13 16 30 38 30
        37 31 2d 42 61 72 63 65 6c 6f 6e 61 2c 20 53 70
        61 69 6e
     Exten  5: ! basicConstraints (2.5.29.19)        
        30 00
     Exten  6:   issuerAltName (2.5.29.18)        
        30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75
        70 63 2e 65 73 2f
Signature Alg: md2WithRSAEncryption (1.2.840.113549.1.1.2)
    Sig Value:
        00 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04
        ea 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a
        ab eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c
        91 a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6
        50 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04
        ea 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a
        ab eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c
        91 a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6
        50

------------------------------- printber ----------------------------

offs tag lenbytes length        value
---- -- --------- ---  ----------------------
0000 30 80        859: SEQUENCE 
0002 30 82 02 c0  704: . SEQUENCE 
0006 a0 03          3: . . [0] 
0008 02 01          1: . . . INTEGER 2
0011 02 02          2: . . INTEGER 256
0015 30 0d         13: . . SEQUENCE 
0017 06 09          9: . . . OID 1.2.840.113549.1.1.2: md2WithRSAEncryption
0028 05 00          0: . . . NULL 
0030 30 68        104: . . SEQUENCE 
0032 31 0b         11: . . . SET 
0034 30 09          9: . . . . SEQUENCE 
0036 06 03          3: . . . . . OID 2.5.4.6: C
0041 13 02          2: . . . . . PrintableString  'ES'
0045 31 2d         45: . . . SET 
0047 30 2b         43: . . . . SEQUENCE 
0049 06 03          3: . . . . . OID 2.5.4.10: O
0054 13 24         36: . . . . . PrintableString  'Universitat Politecnica de Catalunya'
0092 31 2a         42: . . . SET 
0094 30 28         40: . . . . SEQUENCE 
0096 06 03          3: . . . . . OID 2.5.4.11: OU
0101 13 21         33: . . . . . PrintableString  'Dept. Arquitectura de Computadors'
0136 30 1e         30: . . SEQUENCE 
0138 17 0d         13: . . . UTCTime  '960722173802Z'
0153 17 0d         13: . . . UTCTime  '970722173802Z'
0168 30 81 83     131: . . SEQUENCE 
0171 31 0b         11: . . . SET 
0173 30 09          9: . . . . SEQUENCE 
0175 06 03          3: . . . . . OID 2.5.4.6: C
0180 13 02          2: . . . . . PrintableString  'ES'
0184 31 2d         45: . . . SET 
0186 30 2b         43: . . . . SEQUENCE 
0188 06 03          3: . . . . . OID 2.5.4.10: O
0193 13 24         36: . . . . . PrintableString  'Universitat Politecnica de Catalunya'
0231 31 2a         42: . . . SET 
0233 30 28         40: . . . . SEQUENCE 
0235 06 03          3: . . . . . OID 2.5.4.11: OU
0240 13 21         33: . . . . . PrintableString  'Dept. Arquitectura de Computadors'
0275 31 19         25: . . . SET 
0277 30 17         23: . . . . SEQUENCE 
0279 06 03          3: . . . . . OID 2.5.4.3: CN
0284 13 10         16: . . . . . PrintableString  'Francisco Jordan'
0302 30 7c        124: . . SEQUENCE 
0304 30 0d         13: . . . SEQUENCE 
0306 06 09          9: . . . . OID 1.2.840.113549.1.1.1: rsaEncryption
0317 05 00          0: . . . . NULL 
0319 03 6b        107: . . . BIT STRING  (0 unused bits)
                     : 30 68 02 61 00 be aa 8b 77 54 a3 af ca 77 9f 2f
                     : b0 cf 43 88 ff a6 6d 79 55 5b 61 8c 68 ec 48 1e
                     : 8a 86 38 a4 fe 19 b8 62 17 1d 9d 0f 47 2c ff 63
                     : 8f 29 91 04 d1 52 bc 7f 67 b6 b2 8f 74 55 c1 33
                     : 21 6c 8f ab 01 95 24 c8 b2 73 93 9d 22 61 50 a9
                     : 35 fb 9d 57 50 32 ef 56 52 50 93 ab b1 88 94 78
                     : 56 15 c6 1c 8b 02 03 01 00 01
0428 a3 82 01 16  278: . . [3] 
0432 30 82 01 12  274: . . . SEQUENCE 
0436 30 1b         27: . . . . SEQUENCE 
0438 06 03          3: . . . . . OID 2.5.29.35: authorityKeyIdentifier
0443 04 14         20: . . . . . OCTET STRING 
                     : 30 12 80 10 0e 6b 3a bf 04 ea 04 c3 0e 6b 3a bf
                     : 04 ea 04 c3
0465 30 0e         14: . . . . SEQUENCE 
0467 06 03          3: . . . . . OID 2.5.29.15: keyUsage
0472 01 01          1: . . . . . BOOLEAN ff: True
0475 04 04          4: . . . . . OCTET STRING 
                     : 03 02 07 80
0481 30 28         40: . . . . SEQUENCE 
0483 06 03          3: . . . . . OID 2.5.29.32: certificatePolicies
0488 04 21         33: . . . . . OCTET STRING 
                     : 30 1f 30 1d 06 04 2a 84 80 00 30 15 30 07 06 05
                     : 2a 84 80 00 01 30 0a 06 05 2a 84 80 00 02 02 01
                     : 0a
0523 30 81 8b     139: . . . . SEQUENCE 
0526 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
0531 04 81 83     131: . . . . . OCTET STRING 
                     : 30 81 80 81 10 6a 6f 72 64 61 6e 40 61 63 2e 75
                     : 70 63 2e 65 73 86 11 68 74 74 70 3a 2f 2f 61 63
                     : 2e 75 70 63 2e 65 73 2f a0 59 06 03 55 04 10 a0
                     : 52 30 50 13 14 44 72 2e 20 46 72 61 6e 63 69 73
                     : 63 6f 20 4a 6f 72 64 61 6e 13 05 55 2e 50 2e 43
                     : 13 19 43 2f 20 47 72 61 6e 20 43 61 70 69 74 61
                     : 20 73 6e 2c 20 4d 6f 64 2d 44 36 13 16 30 38 30
                     : 37 31 2d 42 61 72 63 65 6c 6f 6e 61 2c 20 53 70
                     : 61 69 6e
0665 30 0c         12: . . . . SEQUENCE 
0667 06 03          3: . . . . . OID 2.5.29.19: basicConstraints
0672 01 01          1: . . . . . BOOLEAN ff: True
0675 04 02          2: . . . . . OCTET STRING 
                     : 30 00
0679 30 1d         29: . . . . SEQUENCE 
0681 06 03          3: . . . . . OID 2.5.29.18: issuerAltName
0686 04 16         22: . . . . . OCTET STRING 
                     : 30 14 86 12 68 74 74 70 3a 2f 2f 77 77 77 2e 75
                     : 70 63 2e 65 73 2f
0710 30 80         15: . SEQUENCE 
0712 06 09          9: . . OID 1.2.840.113549.1.1.2: md2WithRSAEncryption
0723 05 00          0: . . NULL 
0727 03 81 81     129: . BIT STRING  (0 unused bits)
                     : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
                     : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
                     : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
                     : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50
                     : 5c 01 bd b5 41 88 87 7a 0e d3 0e 6b 3a bf 04 ea
                     : 04 cb 5f 61 72 3c a3 bd 78 f5 66 17 fe 37 3a ab
                     : eb 67 bf b7 da a8 38 f6 33 15 71 75 2f b9 8c 91
                     : a0 e4 87 ba 4b 43 a0 22 8f d3 a9 86 43 89 e6 50

Date: Tue, 15 Apr 1997 09:21:27 -0400
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: Re: non-U.S. characters in name fields?

thanks.  I wonder what happens when someone uses ANY... to encode
UNICODE...  but I live in a crass north american computing environment so
I'm supposed to be illiterate on such issues.

At 03:07 PM 4/14/97 -0400, you wrote:
>> From: Rodney Thayer <[email-masked]>
>> 
>> Gosh is the "PKIX 1" document set up to handle non-english names?
>> 
>> >From: [email-masked] (Peter williams)
>> >
>> >out of interest, have you tried putting cyrillic chars in the T.61
>> >fields of a cert Name field?
>> >
>> >Do attribute strings in non-ascii char sets get shown rightish in the
>> >various browsers?
>
>
>UTSL :-)       (in honor of the Star Wars re-release)
>
>
>
>PKIX-1 says:
>
>  DistinguishedName ::= RDNSequence
>
>  RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
>
>  RelativeDistinguishedName ::= SET OF AttributeTypeAndValue
>
>  AttributeTypeAndValue ::= SEQUENCE {
>                               type  AttributeType,
>                               value AttributeValue }
>
>  AttributeType ::= OBJECT IDENTIFIER
>
>  AttributeValue ::= ANY
>
>
>
>I don't see a PKIX-1 requirement in either section 4.1.2 or section 9
>for DNs to use T.61 strings (or any other specific character set).  In
>fact, PKIX-1 draft 4 uses the vile ANY construct :-) in lieu of ANY
>DEFINED BY or a table constraint - it's completely general.  The issue
>of whether a particular piece of software properly displays cyrillic
>characters is not a PKIX-1 issue, it's an implementation support
>issue.
>
>(Presumably PKIX-1 will at some point profile the contents of DN fields
>- it's pretty hard to fully support un-subsetted UNIVERSAL STRING and
>unrestricted CHARACTER STRING :-).
>
>

Date: Mon, 14 Apr 1997 15:07:31 -0400
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: non-U.S. characters in name fields?

> From: Rodney Thayer <[email-masked]>
> 
> Gosh is the "PKIX 1" document set up to handle non-english names?
> 
> >From: [email-masked] (Peter williams)
> >
> >out of interest, have you tried putting cyrillic chars in the T.61
> >fields of a cert Name field?
> >
> >Do attribute strings in non-ascii char sets get shown rightish in the
> >various browsers?

UTSL :-)       (in honor of the Star Wars re-release)

PKIX-1 says:

  DistinguishedName ::= RDNSequence

  RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

  RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

  AttributeTypeAndValue ::= SEQUENCE {
                               type  AttributeType,
                               value AttributeValue }

  AttributeType ::= OBJECT IDENTIFIER

  AttributeValue ::= ANY

I don't see a PKIX-1 requirement in either section 4.1.2 or section 9
for DNs to use T.61 strings (or any other specific character set).  In
fact, PKIX-1 draft 4 uses the vile ANY construct :-) in lieu of ANY
DEFINED BY or a table constraint - it's completely general.  The issue
of whether a particular piece of software properly displays cyrillic
characters is not a PKIX-1 issue, it's an implementation support
issue.

(Presumably PKIX-1 will at some point profile the contents of DN fields
- it's pretty hard to fully support un-subsetted UNIVERSAL STRING and
unrestricted CHARACTER STRING :-).

Date: Sun, 13 Apr 1997 23:04:40 -0500
From: jamesd <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: unsubscribe

unsubscribe

Date: Sun, 13 Apr 1997 09:22:16 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: non-U.S. characters in name fields?

Gosh is the "PKIX 1" document set up to handle non-english names?

>Resent-Date: Fri, 11 Apr 1997 22:38:40 -0700 (PDT)
>From: [email-masked] (Peter williams)
>Date: Fri, 11 Apr 1997 22:38:22 -0700
>To: [email-masked] (Hlupnov Sergey)
>Cc: [email-masked]
>Subject: Re: MSIE and CA certs again (certificate you are using is not yet
>	valid)
>Resent-Message-ID: <"r5rqp.0.cW3.K_nJp"@glacier>
>Resent-From: [email-masked]
>X-Mailing-List: <[email-masked]> archive/latest/4683
>X-Loop: [email-masked]
>Resent-Sender: [email-masked]
>
>out of interest, have you tried putting cyrillic chars in the T.61
>fields of a cert Name field?
>
>Do attribute strings in non-ascii char sets get shown rightish in the
>various browsers?
>
>------
>In anticipation of a real, lawyered,  disclaimer:  
>"Civis Internetus sum." 
>"Qui mori didicit servire dedidicit" - Seneca, (And George MacDonald
Fraser - 'Flash for Freedom' p62; fiction.)
>
>
>

Date: Fri, 11 Apr 97 10:43:49 
From: "Housley, Russ" <[email-masked]>
Encoding: 2508 Text
To: [email-masked], Tim Dierks <[email-masked]>
CC: [email-masked]
Subject: Re: Extended Key Usage Extension

Tim:

I do not like the idea of listing all of the thinks that a public key 
cannot be used to do.  Such a list is always incomplete.  Pleople will 
continute to invent applications and uses for public key cryptography.

Russ

______________________________ Reply Separator _________________________________
Subject: Re: Extended Key Usage Extension
Author:  Tim Dierks <[email-masked]> at internet
Date:    4/10/97 5:40 PM

At 11:50 AM -0700 4/10/97, Warwick Ford wrote: 
>id-kp-serverAuth   OBJECT IDENTIFIER ::= {id-kp 1} 
>-- TLS Web server authentication
>-- Key usage bits that may be consistent: keyEncipherment or keyAgreement 
>id-kp-clientAuth   OBJECT IDENTIFIER ::= {id-kp 2}
>-- TLS Web client authentication
>-- Key usage bits that may be consistent: digitalSignature

Warwick, thank you for this proposal.

First, the minor note: id-kp-serverAuth is also consistent with 
digitalSignature, for modes in which the server signs an ephemeral RSA or 
Diffie-Hellman key.

Also, it is my contention that it would be a good idea to provide values 
for no-serverAuth and no-clientAuth as well. This is an issue that arises 
because implementors need to interoperate with non-PKIX usage spaces and/or 
would like flexibility in certificate use.

Specifically, let's say I am a TLS web client vendor. For interoperability 
reasons and backwards compatibility, I would like to allow servers to use 
X.509v1 certs and/or non-PKIX compliant X.509v3 certs. Since I cannot deny 
access because id-kp-serverAuth isn't there, I can't keep PKIX compatible 
clients (who I suggest should have no-serverAuth OIDs) from masquerading as 
SSL servers.

You could battle this by marking the extension critical, but this would 
lead to an undesirable lack of flexibility: when we introduce secure 
telephony, one wouldn't be able to use a TLS client certificate for secure 
telephony because it presumably wouldn't have an 
id-kp-watsonComeHereINeedYou OID (which hadn't been invented when the cert 
was signed), even though the policy and distinguished name of the 
certificate might allow it.

On the other hand, I suppose that it would be bad to have to list all the 
various things a certificate can't do, as well: id-kp-serverAuth, 
id-kp-breakTheLaw, id-kp-enableDoomsdayDevice, etc.

 - Tim

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

Date: Fri, 11 Apr 1997 10:13:14 +0900
To: [email-masked]
From: [email-masked] (Yukio Nakata)
Subject: remove

I'd like to remove from this list.

Date: Wed, 9 Apr 1997 19:51:26 -0500
To: Warwick Ford <[email-masked]>
From: Tim Dierks <[email-masked]>
Subject: Re: Extended Key Usage Extension
Cc: [email-masked]

At 11:50 AM -0700 4/10/97, Warwick Ford wrote:
>id-kp-serverAuth			OBJECT IDENTIFIER	::=	{id-kp 1}
>-- TLS Web server authentication
>-- Key usage bits that may be consistent: keyEncipherment or keyAgreement
>id-kp-clientAuth			OBJECT IDENTIFIER	::=	{id-kp 2}
>-- TLS Web client authentication
>-- Key usage bits that may be consistent: digitalSignature

Warwick, thank you for this proposal.

First, the minor note: id-kp-serverAuth is also consistent with
digitalSignature, for modes in which the server signs an ephemeral RSA or
Diffie-Hellman key.

Also, it is my contention that it would be a good idea to provide values
for no-serverAuth and no-clientAuth as well. This is an issue that arises
because implementors need to interoperate with non-PKIX usage spaces and/or
would like flexibility in certificate use.

Specifically, let's say I am a TLS web client vendor. For interoperability
reasons and backwards compatibility, I would like to allow servers to use
X.509v1 certs and/or non-PKIX compliant X.509v3 certs. Since I cannot deny
access because id-kp-serverAuth isn't there, I can't keep PKIX compatible
clients (who I suggest should have no-serverAuth OIDs) from masquerading as
SSL servers.

You could battle this by marking the extension critical, but this would
lead to an undesirable lack of flexibility: when we introduce secure
telephony, one wouldn't be able to use a TLS client certificate for secure
telephony because it presumably wouldn't have an
id-kp-watsonComeHereINeedYou OID (which hadn't been invented when the cert
was signed), even though the policy and distinguished name of the
certificate might allow it.

On the other hand, I suppose that it would be bad to have to list all the
various things a certificate can't do, as well: id-kp-serverAuth,
id-kp-breakTheLaw, id-kp-enableDoomsdayDevice, etc.

 - Tim

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

Date: Thu, 10 Apr 97 12:03:34 
From: "Housley, Russ" <[email-masked]>
Encoding: 3939 Text
To: [email-masked], Trevor Freeman <[email-masked]>
Subject: Re: Key Usage Clarification in PKIX part 1

The following text will be added to the document in the Key Usage section 
(4.2.1.3).  I hope this addresses the concerns.  If not, please post recommended
text changes.

  Russ

= = = = = = = = = =

The key usage extension defines the purpose (e.g., encipherment, signature, 
certificate signing) of the key contained in the certificate.  The usage 
restriction might be employed when a key that could be used for more than one 
operation is to be restricted.  For example, when an RSA key should be used only
for signing, the digitalSignature and nonRepudiation bits would be asserted.  
Likewise, when an RSA key should be used only for key management, the 
keyEncipherment bit would be asserted.  The profile recommends that when used, 
this be marked as a critical extension.

Bits in the KeyUsage type are used as follows:

   The digitalSignature bit is asserted when the subject public key is used 
   to verifying digital signatures that have purposes other than 
   non-repudiation, certificate signature, and CRL signature.  For example, 
   The digitalSignature bit is asserted when the subject public key is used 
   to provide authentication.
   
   The nonRepudiation bit is asserted when the subject public key is used 
   to verifying digital signatures used to provide a non-repudiation 
   service which protects against the signing entity falsely denying some 
   action, excluding certificate or CRL signing.
   
   The keyEncipherment bit is asserted when the subject public key is used 
   for key transport.  For example, when an RSA key is to be used 
   exclusively for key management, then this bit must asserted.
   
   The dataEncipherment bit is asserted when the subject public key is used 
   for enciphering user data, other than cryptographic keys.
   
   The keyAgreement bit is asserted when the subject public key is used for 
   key agreement.  For example, when a Diffie-Hellman key is to be used 
   exclusively for key management, then this bit must asserted.
   
   The keyCertSign bit is asserted when the subject public key is used for 
   verifying a signature on certificates.  This bit may only be asserted in 
   CA certificates.

   The cRLSign bit is asserted when the subject public key is used for verifying 
   a signature on CRLs.  This bit may only be asserted in CA certificates.

______________________________ Reply Separator _________________________________
Subject: Key Usage Clarification in PKIX part 1
Author:  Trevor Freeman <[email-masked]> at internet
Date:    4/9/97 5:00 AM

Following yesterdays discussion with the SSL people, it would seem clear 
that some clarification on the meaning of the key usage types is 
required in pkix part 1. 
I cannot see that when SSL performs a series of cryptographic 
transformation on some data in order to derive a symmetric algorithm 
session key, it is performing a digital signature. You cannot use DSA in 
this protocol. 
Also SSL is performing what PKIX part 3 would describe as a direct proof 
of possession(POPO), that is they are establishing the binding between 
the public and private key pair. If the CA has a policy to ensure a 
strong binding between the public key and the user identity, then the 
application may also infer a authentication. The certificate consumers 
need to understand that if the CA has a weak binding between public key 
and identity, then the authentication is weak as any D Duck class 1 
certificate would testify. They also need to understand that if the CA 
has a policy of issuing certificate with a weak binding between the 
public and private key(i.e. does not do a POPO of the key pair, as part 
of certificate creation), then when SSL does a POPO, it does not prove 
very much.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel: UK(+44) 1734 270 412 
> 

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: Key Usage Clarification in PKIX part 1
Date: Thu, 10 Apr 1997 09:10:15 -0700

Tom,

I here what you are saying, and technically it looks a grey area as you
are using a signing operation as part of the transformation. 

My concern is more a legal concern. 

In Europe, there are a number of active discussions going on about how
law enforcement officers can gain warranted access to the users key
material. Like it or not, this is likely to end in some sort of
legislation as we do not have a constitution protecting us. I am well
aware of the problems and arguments in this area, and am far from
advocating the position. However in discussions, a difference is drawn
between signing and encrypting certs since the purest view of signed
things is that they remain in clear text. Law enforcement types are not
interested in signing key material. In the case in point, this mechanism
may not be acceptable under this type of legislation as the RSA or D-H
key pair used for the actual key exchange is dynamically generated and
is therefore not accessible.

The solution to the problem would seem yet another key usage definition
which would specifically allow or not a signing key to participate in
encryption key material transformation which PKIX needs to define and
the TLS code need to check. 

If signing certs are going to be used for this purpose this concern
needs to be addressed in the TLS documents or there is going to be
problems outside the US.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel: UK(+44) 1734 270 412 
> 

Date: Thu, 10 Apr 1997 11:50:27 -0700
To: [email-masked]
From: Warwick Ford <[email-masked]>
Subject: Extended Key Usage Extension

This message pertains to the discussion at the Memphis meeting regarding
extending the key usage extension to provide for OID-indicated key
purposes.  In light of valuable discussions with several individuals in
Memphis, including PKIX, TLS and IPSEC specialists, following is a specific
proposal to add a new extension field definition without changing the
existing keyUsage extension.  I shall also explore having ISO/IEC/ITU add
this to the standard, in response to an open defect report addressing
inadequacies in the key usage bit string.

Warwick
--------------------------- 

12.2.2.x	Extended key usage field

This field indicates one or more purposes for which the certified public
key may be used, in addition to or in place of the basic purposes indicated
in the key usage extension field.  This field is defined as follows:

extKeyUsage EXTENSION ::= {
	SYNTAX	SEQUENCE SIZE (1..MAX) OF KeyPurposeId
	IDENTIFIED BY id-ce-extKeyUsage }

KeyPurposeId ::= OBJECT IDENTIFIER

Key purposes may be defined by any organization with a need. Object
identifiers used to identify key purposes shall be assigned in accordance
with ITU-T Rec. X.660 | ISO/IEC 9834-1.

This extension may, at the option of the certificate issuer, be either
critical or non-critical. 

If the extension is flagged critical, then the certificate shall be used
only for one of the purposes indicated. 

If the extension is flagged non-critical, then it indicates the intended
purpose or purposes of the key, and may be used in finding the correct
key/certificate of an entity that has multiple keys/certificates. It is an
advisory field and does not imply that usage of the key is restricted by
the certification authority to the purpose indicated. (Using applications
may nevertheless require that a particular purpose be indicated in order
for the certificate to be acceptable to that application.) 

If a certificate contains both a critical key usage field and a critical
extended key usage field, then both fields shall be processed independently
and the certificate shall only be used for a purpose consistent with both
fields.  If there is no purpose consistent with both fields, then the
certificate shall not be used for any purpose.

[The following purpose definitions are for inclusion in the IETF PKIX
Profile but not the ISO/IEC/ITU standard.]

The following key usage purposes are defined by this profile:

id-kp-serverAuth			OBJECT IDENTIFIER	::=	{id-kp 1}
-- TLS Web server authentication
-- Key usage bits that may be consistent: keyEncipherment or keyAgreement
id-kp-clientAuth			OBJECT IDENTIFIER	::=	{id-kp 2}
-- TLS Web client authentication
-- Key usage bits that may be consistent: digitalSignature
id-kp-codeSigning			OBJECT IDENTIFIER	::=	{id-kp 3}
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
id-kp-emailProtection		OBJECT IDENTIFIER	::=	{id-kp 4}
-- E-mail protection
-- Key usage bits that may be consistent: digitalSignature, nonRepudiation,
and/or (keyEncipherment or keyAgreement)
id-kp-ipsecEndSystem			OBJECT IDENTIFIER	::=	{id-kp 5}
-- IP security end system (host or router)
-- Key usage bits that may be consistent: digitalSignature and/or
(keyEncipherment or keyAgreement)
id-kp-ipsecTunnel			OBJECT IDENTIFIER	::=	{id-kp 6}
-- IP security tunnel termination
-- Key usage bits that may be consistent: digitalSignature and/or
(keyEncipherment or keyAgreement)
id-kp-ipsecUser			OBJECT IDENTIFIER	::=	{id-kp 7}
-- IP security user
-- Key usage bits that may be consistent: digitalSignature and/or
(keyEncipherment or keyAgreement)

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

Sender: [email-masked] (Tom Weinstein)
Date: Wed, 09 Apr 1997 14:11:15 -0700
From: Tom Weinstein <[email-masked]>
Organization: Netscape Communications, Inc.
To: Trevor Freeman <[email-masked]>
CC: "Pkix List (E-mail)" <[email-masked]>
Subject: Re: Key Usage Clarification in PKIX part 1

Trevor Freeman wrote:
> 
> Following yesterdays discussion with the SSL people, it would seem
> clear that some clarification on the meaning of the key usage types is
> required in pkix part 1.  I cannot see that when SSL performs a series
> of cryptographic transformation on some data in order to derive a
> symmetric algorithm session key, it is performing a digital signature.
> You cannot use DSA in this protocol.

This is not completely accurate.  There are a couple of modes in which
SSL can operate using only signing certificates.

One mode is where the server generates a temporary RSA key, which it
then signs and sends to the client.  The client verifies the signature
on the temporary key and then encrypts key exchange data with it.  The
server decrypts the data and they both generate session keys.  There's
a similar mode using Diffie-Hellman key exchange.  In all of these
cases, DSA can be used as the signing algorithm.

You can certainly argue that, even though it's using a signing
operation, the real use of the key is for a key exchange operation.

> Also SSL is performing what PKIX part 3 would describe as a direct
> proof of possession(POPO), that is they are establishing the binding
> between the public and private key pair. If the CA has a policy to
> ensure a strong binding between the public key and the user identity,
> then the application may also infer a authentication. The certificate
> consumers need to understand that if the CA has a weak binding between
> public key and identity, then the authentication is weak as any D Duck
> class 1 certificate would testify. They also need to understand that
> if the CA has a policy of issuing certificate with a weak binding
> between the public and private key(i.e. does not do a POPO of the key
> pair, as part of certificate creation), then when SSL does a POPO, it
> does not prove very much.

Yes, if the binding between the certificate and the identity is weak,
then so will any authentication performed with that certificate.  You
must always be careful about the policies of the CAs you trust.

-- 
You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      | [email-masked]

Date: Wed, 09 Apr 1997 13:59:09 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Key Usage Clarification in PKIX part 1

Good comments.  Good also to differentiate between a digital signature vs. certificate-based authentication 

michael

>>> Trevor Freeman <[email-masked]> 04/09/97 05:55AM >>>
Following yesterdays discussion with the SSL people, it would seem clear
that some clarification on the meaning of the key usage types is
required in pkix part 1. 
I cannot see that when SSL performs a series of cryptographic
transformation on some data in order to derive a symmetric algorithm
session key, it is performing a digital signature. You cannot use DSA in
this protocol. 
Also SSL is performing what PKIX part 3 would describe as a direct proof
of possession(POPO), that is they are establishing the binding between
the public and private key pair. If the CA has a policy to ensure a
strong binding between the public key and the user identity, then the
application may also infer a authentication. The certificate consumers
need to understand that if the CA has a weak binding between public key
and identity, then the authentication is weak as any D Duck class 1
certificate would testify. They also need to understand that if the CA
has a policy of issuing certificate with a weak binding between the
public and private key(i.e. does not do a POPO of the key pair, as part
of certificate creation), then when SSL does a POPO, it does not prove
very much.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel: UK(+44) 1734 270 412 
> 

From: Trevor Freeman <[email-masked]>
To: "Pkix List (E-mail)" <[email-masked]>
Subject: Key Usage Clarification in PKIX part 1
Date: Wed, 9 Apr 1997 04:55:41 -0700

Following yesterdays discussion with the SSL people, it would seem clear
that some clarification on the meaning of the key usage types is
required in pkix part 1. 
I cannot see that when SSL performs a series of cryptographic
transformation on some data in order to derive a symmetric algorithm
session key, it is performing a digital signature. You cannot use DSA in
this protocol. 
Also SSL is performing what PKIX part 3 would describe as a direct proof
of possession(POPO), that is they are establishing the binding between
the public and private key pair. If the CA has a policy to ensure a
strong binding between the public key and the user identity, then the
application may also infer a authentication. The certificate consumers
need to understand that if the CA has a weak binding between public key
and identity, then the authentication is weak as any D Duck class 1
certificate would testify. They also need to understand that if the CA
has a policy of issuing certificate with a weak binding between the
public and private key(i.e. does not do a POPO of the key pair, as part
of certificate creation), then when SSL does a POPO, it does not prove
very much.

Dr Trevor Freeman
Senior Consultant
Microsoft Consulting Services
Microsoft Ltd ECU
> Tel: UK(+44) 1734 270 412 
> 

Date: Tue, 8 Apr 1997 13:16:46 -0700 (PDT)
From: Patrick Richard <[email-masked]>
To: Stef Hoeben <[email-masked]>
cc: [email-masked]
Subject: Re: operational protocols

On Tue, 8 Apr 1997, Stef Hoeben wrote:

> you). So (only) authentication (by the CA) of _all_ 
> answers the Directory gives are a solution to this
> spoofing, IMHO again.

Authenticated LDAP (via TLS or your choice of auth mechanism) solves the 
issue that you are describing. In the case of LDAP over SSL, a client 
only needs to accept a single root cert (the issuer of the directory 
server's cert), and can then accept (depending on policy) the remaining 
necessary compenents/information (including _other_ root certs) via the 
directory service.

Any information retreived in this fashion can only be trusted as much as 
the directory server is trusted (and in most cases, probably less).

For all of the requirements of PKIX part II, all of the information 
provided by the directory is already signed, so this really doesn't have 
anything to do with part II. It _does_ have implications if the use of 
LDAP as an OCSP is what you are talking about.

> > 			 Cheers, Stef > 

--
Pat Richard    /    [email-masked]
---
Public Key available via LDAP
   http://www.xcert.com

Sender: [email-masked]
Date: Tue, 08 Apr 1997 09:06:13 -0400
From: Reginald Carey <[email-masked]>
Organization: J. G. Van Dyke & Associates, Inc.
To: Stef Hoeben <[email-masked]>
Cc: [email-masked]
Subject: Re: operational protocols

Stef Hoeben wrote:
> 
> Since you're all shooting at me, I better withdraw
> and shut up (though in some cases a CIL could be
> usefull, IMHO:)
> 
> The main reason for me was to ask the two questions
> in my first mail ... (which still no-one bothered to
> answer)
> 
> By the way, even if you also trust your Directory
> (though it would off course be nicer to only trust
> the CA), there is still the risk of spoofing (someone
> who intercepts the reponse the Directory sends to
> you). So (only) authentication (by the CA) of _all_
> answers the Directory gives are a solution to this
> spoofing, IMHO again.
> 

The best way for a DUA to ensure that it is not being
spoofed by a rogue DSA impersonator is to require
signed operations on both directory requests and responses.
In that way you can trust your directory.  It may not give
you what you asked for but then again, you'll know that what
was sent by the directory will be what you receive.  Also, 
having secure prior knowledge of your CA's certificate is 
the ONLY way to know that any signature is valid.  This can
be done via some read only storage device provided by the CA.

-- 
+----------------------------------------------------------------------+
| Reginald B. Carey                 | J.G. Van Dyke & Associates, Inc. |
| Senior Systems Engineer           | 141 National Business Pkwy, #210 |
| Voice (301) 939-2707              | Annapolis Junction, MD 20701     |
| Fax   (301) 953-2901              | Office (301) 953-3600            |
| mailto:[email-masked]      | http://www.jgvandyke.com         |
+----------------------------------------------------------------------+

Organization: ESAT, K.U.Leuven, Belgium
Date: Tue, 8 Apr 1997 12:03:09 +0200 (MET DST)
From: Stef Hoeben <[email-masked]>
To: [email-masked]
Subject: Re: operational protocols

Since you're all shooting at me, I better withdraw
and shut up (though in some cases a CIL could be
usefull, IMHO:)

The main reason for me was to ask the two questions 
in my first mail ... (which still no-one bothered to
answer)

By the way, even if you also trust your Directory
(though it would off course be nicer to only trust
the CA), there is still the risk of spoofing (someone
who intercepts the reponse the Directory sends to
you). So (only) authentication (by the CA) of _all_ 
answers the Directory gives are a solution to this
spoofing, IMHO again.

			Cheers, Stef

From: <[email-masked]>
X400-Received: by mta bath.mail.pipex.net in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 7 Apr 1997 18:03:09 +0100
X400-Received: by mta fel01m2 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 7 Apr 1997 17:52:34 +0100
X400-Received: by mta bra01c1 in /PRMD=pipex/ADMD=pipex/C=gb/; Relayed; Mon, 7 Apr 1997 18:00:49 +0100
X400-Received: by /PRMD=icl/ADMD=gold 400/C=GB/; converted (ia5-text); Relayed; Mon, 7 Apr 1997 18:02:15 +0100
Date: Mon, 7 Apr 1997 18:02:15 +0100
X400-Originator: [email-masked]
X400-Recipients: non-disclosure:;
X400-MTS-Identifier: [/PRMD=icl/ADMD=gold 400/C=GB/;win0199 0000008800012030]
X400-Content-Type: P2-1984 (2)
Content-Identifier: 12030
Alternate-Recipient: Allowed
To: [email-masked]
Subject: RE(2): operational protocols

         Late into this thread as usual, but can anyone tell me why
         the CIL works at all? Why couldn't the bad Directory supply the
         caller with an old CIL ("I didn't get the latest CIL either")?
         
         My impression of the (maybe partial) solution to the "I didn't get
         it" problem was that a policy is defined on CRL update releases. 
         One release is defined to be expected every X days. This policy
         can be specified in a V3 certificate. If the CA has nothing to 
         say on a particular CRL issue time point it issues an empty one,
         or a copy of the previous one, depending on whether delta CRLs
         are being used.
         
         Under the policy described above, Validation of a certificate
         demands that all current CRLs, including empty ones have been 
         looked at. If a Directory says "didn't get the last issue", and 
         note that it can't hide the fact that there should be one,
         then the policy says the certificate cannot be treated as valid.
         You can't stop the denial of service threat but you can stop 
         revoked certificates being accepted.
         
         Tom Parker
         ICL, UK
         7.4.97

Date: Mon, 07 Apr 1997 11:03:28 -0500
To: [email-masked]
From: Rodney Thayer <[email-masked]>
Subject: comments on part1 (version 4) 

I can't find the message archive on ftp.tandem.com so forgive me if this is
old ground.

the md5 digest algorithm isn't covered in the text of algorithms or the
ASN.1.  However, the example uses it.  Does the document mean to not use
MD5, allow MD-2, and recommend SHA-1?

I do like having examples.  Tim asked that in the meeting.

               Rodney Thayer <[email-masked]>       +1 617 332 7292
               Sable Technology Corp, 246 Walnut St., Newton MA 02160 USA
               Fax: +1 617 332 7970           http://www.shore.net/~sable
                           "Developers of communications software"

Date: Mon, 07 Apr 1997 11:28:45 -0400
From: "Hoffman, Mort" <[email-masked]>
Subject: RE: OOPS -- Correction.  RE: pkix part 1, draft 4:  UTCTim
To: "[email-masked]'" <[email-masked]>, "'Housley, Russ'" <[email-masked]>

Russ,

Not quite.  I agree with you on what the encoding rules say.  However,
in 4.1.2.5.1, for purposes of decoding UTCTime it says

"Where YY is greater than 50, the year shall be itnerpreted as 19YY; and
Where YY is less than or equal to 50, the year shall be interpreted as
20YY."

Thus a UTCTime of 500101000000Z would be interpreted as midnight January
1, 2050, even though January 1, 2050 would be encoded in
GeneralizedTime!

Mort

>----------
>From: 	Housley, Russ[SMTP:[email-masked]]
>Sent: 	Sunday, April 06, 1997 3:42 PM
>To: 	[email-masked]; [email-masked]; [email-masked]
>Subject: 	Re: OOPS -- Correction.  RE: pkix part 1, draft 4:  UTCTim
>
>
>Mort:
>
>I think the text says that dates before 2050 should be encoded at UTCTime,
>and 
>that dates after 2049 should be encodes as GeneralizedTime.  Thus, a UTCTime 
>of 500101000000Z should be interpreted as midnight on January 1, 1950.
>
>Agree?
>
>Russ
>
>>Tim,
>>
>>Reading throught the spec I ran into the following anomaly:  section
>>>4.1.2.5 
>specifies that dates in the year 2050 should be generated as >GeneralizedTime
>(not UTCTime), and section 4.1.2.5.1 specifies that UTCTime >dates encoded
>with
>>the year set to 50 shall be interpreted as 2050.  Now, since there were 
>>no CAs existing in the year 1950, then there should not exist any such 
>>dates in certificates at all (OK, this could be argued with on strictly 
>>technical grounds, but I think it is basically true).  Therefore the 
>>anomaly in the spec should not really affect anything, but if someone 
>>writing code to generate certificates read section 4.1.2.5.1 instead of 
>>4.1.2.5, then he would be lead astray.
>>
>>I imagine all this traces back to the discussion in the X.509 arena on 
>>the dates, but I deleted that mail and I don't know if the anomaly 
>>existed there.  If it didn't then the fix would be to fully align to 
>>what was agreed in X.509.  Otherwise, I guess I'd recommend that a 
>>UTCTime encoded with 50 should be rejected, since it could not have been 
>>legally generated.
>>
>>Mort 
>>
>>
>

Date: Mon, 07 Apr 1997 08:29:56 -0600
From: Mike Smith <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: operational protocols

In the thread, some mention "agreements", "legally binding", "contractual relationship" -- These would need user authentication to enforce (charge for) the service agreement.  I realize that this thread is really discussing X.500 with unathenticated access assumed, but the business models become difficult outside a "private" or no-Trusted-Third-Party relationship.

With charging the certificate holder for access and not the entity accessing, then anyone can freely duplicate the contents of the directory for their own service.  Or, if the subscriber (owner of cert) has paid for "x" number of accesses (especially if their is a "reliance limit" or value associated with a cert or it useage) then a (potentially expensive) denial of service attack would be easily and anonymously available to even the most unsophisticated user.

By providing a free CIL to any and all, one then gives away their customer list (searching for individual certs is another matter).

I firmly believe that the only way certs will become accepted is if there exists explicit trust in the complete cert system -- especially across the public networks.  This requires knowing who your users are and what contractual obligations you have to that user.

Yes, I'm in the business of building repository services that require user authentication, but feel that I would build a system that requires authentication anyway.

Also, X.500 was to be just one of the directory options in PKIX.
Repositories, publication authorities, LDAP directories and more will be seen.  The strongest business model, IMHO, will survive (maybe that is a fully subsidized freely accessible anonymous access model, but I doubt that).

Michael

>>> David Boyce <[email-masked]> 04/07/97 05:01AM >>>
Stef Hoeben writes:
>
>Russ:
>
>> I do not see how the CIL can be usefully used as a certificate
>> extension.
>> Please provide a more detailed explaination.
>
>Normally, a CA gives its certs and CRL to a Directory, which is
>normally no _Trusted_ Third Party. Because the certs and CRL are
>signed by the CA, the Directory can't mess these up. But the
>Directory can answer on a request for a certificate: 'I don't have
>it, the CA never issued it'

[ My comments are being made from an X.500 point of view.  In order to 
understand where Stef is coming from, it is a good idea to read Silvio 
Micali's paper he referred to previously.  

An understated presumption is that the user has some kind of legal 
contract with the Directory to be supplied with certificate 
information, which places a duty on the Directory to justify its 
responses.  This seems dubious in the general case, although perhaps 
individual exceptions may be desirable. DJB]

There may be any number of reasons (insufficient access being just one 
of them) why a Directory might not return a certificate, and it doesn't 
even have to tell you why.  It doesn't have to be interpreted as a 
denial of service attack.

>So if a Directory really doesn't have a certificate, it must prove
>it to the user.

I don't see why, without some special contractual requirement.  This is 
an administrative issue.

> This can be done by the CIL: a list with the serial
>numbers (or other ID's) of all certificates the CA has given to the
>Directory, and this list must be signed by the CA.
>So if a user requests a cert which the Directory didn't have, the
>Directory _must_ give the CIL which the user can check so verify
>the requested cert isn't in the CIL.

This cannot be enforced.  Attribute substitution of this kind is not 
part of DAP or LDAP (the concept of attribute type hierarchy is an 
exception, although unlikely to apply in this case).

The user, on failing to obtain a cert, might then request a CIL, 
perhaps from some other entry;  but the Directory may still decline to 
supply one.

>=> The only problem looks: how to tell the users they will get a
>   CIL instead of a 'I don't have that cert' if they ask for a
>   non-existing cert.
>   I don't think you can put it in a private extension of the
>   certficate, because that's exactly what a nasty Directory
>   won't give...

Depends on what level you are viewing the 'user' from;  at the DAP or 
LDAP level, the user can request either or both of the cert and CIL, 
and the Directory may or may not decide to supply them;  but if 
supplied they are separate attributes.  The application may of course 
translate this into more 'user-friendly' information subsequently.

>> How is LDAP different than any other access to a certificate and CRL 
>> repository?  I do not see what makes the CIL important in the LDAP 
>> environment more than any other environment (like FTP or full DAP).
>
>Oops, mistake: LDAP isn't different. It's the same for the other
>protocols. Sorry for the confusion.

Indeed it is the same.

>> Also, does the use of distributed, replicated Directories help solve 
your 
>> concern? If not, how about the use of more than one distriution 
mechanism, 
>> say FTP and LDAP.
>
>You mean some independent directories with the same info? Sure, that 
would
>help, but isn't that expensive and impractical in most cases?

I think he means multiple Directory System Agents holding copies of the 
same information, which is part of the standard X.500 model.  

(This would mean that the same certificate in the same entry could be 
held on multiple servers.)

However, the issue at the heart of the question remains one of the user 
wanting to establish a legally-binding requirement of service on the 
Directory, which is quite a different matter.  I don't see that CILs 
solve this either - if the Directory refuses to provide certs, why 
should it provide CILs?

David.

-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

Date: Mon, 07 Apr 1997 08:04:45 -0600
From: Mike Smith <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: operational protocols

So, a directory needs to rely on the CAs to provide a CIL if the CAs don't provide them with all of the certificates they issue?  If the CA doesn't provide the certs, why would they provide a CIL?  Why would they provide a CIL if they issue 90% private certs, 10% public.

Lastly, why would someone wish to use a directory it can not trust?  Obviously, these directory services will be operating in a different trust model than the repository model defined in Utah. Possibly, they will be operating under different financial structures as well.

Michael

>>> Stef Hoeben <[email-masked]> 04/07/97 02:21AM >>>

Russ:

> I do not see how the CIL can be usefully used as a certificate
> extension.
> Please provide a more detailed explaination.

Normally, a CA gives its certs and CRL to a Directory, which is
normally no _Trusted_ Third Party. Because the certs and CRL are
signed by the CA, the Directory can't mess these up. But the
Directory can answer on a request for a certificate: 'I don't have
it, the CA never issued it'
So if a Directory really doesn't have a certificate, it must prove
it to the user. This can be done by the CIL: a list with the serial
numbers (or other ID's) of all certificates the CA has given to the
Directory, and this list must be signed by the CA.
So if a user requests a cert which the Directory didn't have, the
Directory _must_ give the CIL which the user can check so verify
the requested cert isn't in the CIL.
=> The only problem looks: how to tell the users they will get a
   CIL instead of a 'I don't have that cert' if they ask for a
   non-existing cert.
   I don't think you can put it in a private extension of the
   certficate, because that's exactly what a nasty Directory
   won't give...

> How is LDAP different than any other access to a certificate and CRL 
> repository?  I do not see what makes the CIL important in the LDAP 
> environment more than any other environment (like FTP or full DAP).

Oops, mistake: LDAP isn't different. It's the same for the other
protocols. Sorry for the confusion.

> Also, does the use of distributed, replicated Directories help solve your 
> concern? If not, how about the use of more than one distriution mechanism, 
> say FTP and LDAP.

You mean some independent directories with the same info? Sure, that would
help, but isn't that expensive and impractical in most cases?

Also, please allow me to ask my questions again ...

 - In the abstract, it looks like only the OCSP protocol 
 can be use for online checking. But this is also possible
 with the LDAP protocol, isn't it? Isn't the only difference 
 that LDAP gives the whole certificate or CRL, while the 
 OCSP only gives the status?
 
 - Do you put the OCSP protocol _in_ an HTML file? Do you 
 have to define new tags?  Are there examples avaiable 
 somewhere? Do Netscape and Microsoft have to put this 
 procotol in their browsers? (Sorry for the dumb questions.)

Stef

Organization: ESAT, K.U.Leuven, Belgium
Date: Mon, 7 Apr 1997 13:41:15 +0200 (MET DST)
From: Stef Hoeben <[email-masked]>
To: David Boyce <[email-masked]>
cc: [email-masked]
Subject: Re: operational protocols

On Mon, 7 Apr 1997, David Boyce wrote:
> 
> However, the issue at the heart of the question remains one of the user 
> wanting to establish a legally-binding requirement of service on the 
> Directory, which is quite a different matter.  I don't see that CILs 
> solve this either - if the Directory refuses to provide certs, why 
> should it provide CILs?

If you know a Directory refuses to provide certs, you can do something
about it (complain to the CA, ...). But the problem is to know whether 
a Directory refuses to provide certs or just doesn't have them. I think
the CIL helps you with this:

>From your mail, it looks that , receiving no response from a Directory
after a request can mean:
(1) Your request didn't receive the Directory
(2) The Directory refuses to give you the requested cert
(3) The Directory doesn't have the requested cert
	(are there other possibilities?)
If you have a CIL, (3) can't happen.
By trying again or asking the system admin what's
happing, you can exclude (1) (isn't it?)
So only (2) is left over: if you don't get an answer after
some requests, you know the Directory is tricking you.

Stef

To: Stef Hoeben <[email-masked]>
cc: "Housley, Russ" <[email-masked]>, [email-masked]
Subject: Re: operational protocols
Date: Mon, 07 Apr 1997 12:01:34 +0100
From: David Boyce <[email-masked]>

Stef Hoeben writes:
>
>Russ:
>
>> I do not see how the CIL can be usefully used as a certificate
>> extension.
>> Please provide a more detailed explaination.
>
>Normally, a CA gives its certs and CRL to a Directory, which is
>normally no _Trusted_ Third Party. Because the certs and CRL are
>signed by the CA, the Directory can't mess these up. But the
>Directory can answer on a request for a certificate: 'I don't have
>it, the CA never issued it'

[ My comments are being made from an X.500 point of view.  In order to 
understand where Stef is coming from, it is a good idea to read Silvio 
Micali's paper he referred to previously.  

An understated presumption is that the user has some kind of legal 
contract with the Directory to be supplied with certificate 
information, which places a duty on the Directory to justify its 
responses.  This seems dubious in the general case, although perhaps 
individual exceptions may be desirable. DJB]

There may be any number of reasons (insufficient access being just one 
of them) why a Directory might not return a certificate, and it doesn't 
even have to tell you why.  It doesn't have to be interpreted as a 
denial of service attack.

>So if a Directory really doesn't have a certificate, it must prove
>it to the user.

I don't see why, without some special contractual requirement.  This is 
an administrative issue.

> This can be done by the CIL: a list with the serial
>numbers (or other ID's) of all certificates the CA has given to the
>Directory, and this list must be signed by the CA.
>So if a user requests a cert which the Directory didn't have, the
>Directory _must_ give the CIL which the user can check so verify
>the requested cert isn't in the CIL.

This cannot be enforced.  Attribute substitution of this kind is not 
part of DAP or LDAP (the concept of attribute type hierarchy is an 
exception, although unlikely to apply in this case).

The user, on failing to obtain a cert, might then request a CIL, 
perhaps from some other entry;  but the Directory may still decline to 
supply one.

>=> The only problem looks: how to tell the users they will get a
>   CIL instead of a 'I don't have that cert' if they ask for a
>   non-existing cert.
>   I don't think you can put it in a private extension of the
>   certficate, because that's exactly what a nasty Directory
>   won't give...

Depends on what level you are viewing the 'user' from;  at the DAP or 
LDAP level, the user can request either or both of the cert and CIL, 
and the Directory may or may not decide to supply them;  but if 
supplied they are separate attributes.  The application may of course 
translate this into more 'user-friendly' information subsequently.

>> How is LDAP different than any other access to a certificate and CRL 
>> repository?  I do not see what makes the CIL important in the LDAP 
>> environment more than any other environment (like FTP or full DAP).
>
>Oops, mistake: LDAP isn't different. It's the same for the other
>protocols. Sorry for the confusion.

Indeed it is the same.

>> Also, does the use of distributed, replicated Directories help solve 
your 
>> concern? If not, how about the use of more than one distriution 
mechanism, 
>> say FTP and LDAP.
>
>You mean some independent directories with the same info? Sure, that 
would
>help, but isn't that expensive and impractical in most cases?

I think he means multiple Directory System Agents holding copies of the 
same information, which is part of the standard X.500 model.  

(This would mean that the same certificate in the same entry could be 
held on multiple servers.)

However, the issue at the heart of the question remains one of the user 
wanting to establish a legally-binding requirement of service on the 
Directory, which is quite a different matter.  I don't see that CILs 
solve this either - if the Directory refuses to provide certs, why 
should it provide CILs?

David.

-- 
David Boyce

Tel:	+44 181 332 9091		Richmond, Surrey, ENGLAND
I'net:	[email-masked]	Isode's WWW: http://www.isode.com/
X.400:	I=d;S=boyce;P=isode;A=mailnet;C=fi;

Organization: ESAT, K.U.Leuven, Belgium
Date: Mon, 7 Apr 1997 10:21:17 +0200 (MET DST)
From: Stef Hoeben <[email-masked]>
Reply-To: Stef Hoeben <[email-masked]>
To: "Housley, Russ" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: operational protocols

Russ:

> I do not see how the CIL can be usefully used as a certificate
> extension.
> Please provide a more detailed explaination.

Normally, a CA gives its certs and CRL to a Directory, which is
normally no _Trusted_ Third Party. Because the certs and CRL are
signed by the CA, the Directory can't mess these up. But the
Directory can answer on a request for a certificate: 'I don't have
it, the CA never issued it'
So if a Directory really doesn't have a certificate, it must prove
it to the user. This can be done by the CIL: a list with the serial
numbers (or other ID's) of all certificates the CA has given to the
Directory, and this list must be signed by the CA.
So if a user requests a cert which the Directory didn't have, the
Directory _must_ give the CIL which the user can check so verify
the requested cert isn't in the CIL.
=> The only problem looks: how to tell the users they will get a
   CIL instead of a 'I don't have that cert' if they ask for a
   non-existing cert.
   I don't think you can put it in a private extension of the
   certficate, because that's exactly what a nasty Directory
   won't give...

> How is LDAP different than any other access to a certificate and CRL 
> repository?  I do not see what makes the CIL important in the LDAP 
> environment more than any other environment (like FTP or full DAP).

Oops, mistake: LDAP isn't different. It's the same for the other
protocols. Sorry for the confusion.

> Also, does the use of distributed, replicated Directories help solve your 
> concern? If not, how about the use of more than one distriution mechanism, 
> say FTP and LDAP.

You mean some independent directories with the same info? Sure, that would
help, but isn't that expensive and impractical in most cases?

Also, please allow me to ask my questions again ...

 - In the abstract, it looks like only the OCSP protocol 
 can be use for online checking. But this is also possible
 with the LDAP protocol, isn't it? Isn't the only difference 
 that LDAP gives the whole certificate or CRL, while the 
 OCSP only gives the status?
 
 - Do you put the OCSP protocol _in_ an HTML file? Do you 
 have to define new tags?  Are there examples avaiable 
 somewhere? Do Netscape and Microsoft have to put this 
 procotol in their browsers? (Sorry for the dumb questions.)

Stef

Date: Sun, 06 Apr 97 19:42:52 
From: "Housley, Russ" <[email-masked]>
Encoding: 1401 Text
To: [email-masked], [email-masked], [email-masked]
Subject: Re: OOPS -- Correction.  RE: pkix part 1, draft 4:  UTCTim

Mort:

I think the text says that dates before 2050 should be encoded at UTCTime, and 
that dates after 2049 should be encodes as GeneralizedTime.  Thus, a UTCTime 
of 500101000000Z should be interpreted as midnight on January 1, 1950.

Agree?

Russ

>Tim,
>
>Reading throught the spec I ran into the following anomaly:  section >4.1.2.5 
specifies that dates in the year 2050 should be generated as >GeneralizedTime 
(not UTCTime), and section 4.1.2.5.1 specifies that UTCTime >dates encoded with
>the year set to 50 shall be interpreted as 2050.  Now, since there were 
>no CAs existing in the year 1950, then there should not exist any such 
>dates in certificates at all (OK, this could be argued with on strictly 
>technical grounds, but I think it is basically true).  Therefore the 
>anomaly in the spec should not really affect anything, but if someone 
>writing code to generate certificates read section 4.1.2.5.1 instead of 
>4.1.2.5, then he would be lead astray.
>
>I imagine all this traces back to the discussion in the X.509 arena on 
>the dates, but I deleted that mail and I don't know if the anomaly 
>existed there.  If it didn't then the fix would be to fully align to 
>what was agreed in X.509.  Otherwise, I guess I'd recommend that a 
>UTCTime encoded with 50 should be rejected, since it could not have been 
>legally generated.
>
>Mort 
>
>

Date: Sun, 06 Apr 97 19:42:36 
From: "Housley, Russ" <[email-masked]>
Encoding: 2014 Text
To: [email-masked], [email-masked]
Subject: Re: operational protocols

Stef:

How is LDAP different than any other access to a certificate and CRL 
repository?  I do not see what makes the CIL important in the LDAP 
environment more than any other environment (like FTP or full DAP).

Also, does the use of distributed, replicated Directories help solve your 
concern?  If not, ow about the use of more than one distriution mechanism, 
say FTP and LDAP.

Russ

______________________________ Reply Separator _________________________________
Subject: operational protocols
Author:  Stef Hoeben <[email-masked]>
Date:    4/3/97 6:21 AM

Hello,

Some questions about the ipki2opp-00 draft (by the way, 
nice work:)

- In the abstract, it looks like only the OCSP protocol 
can be use for online checking. But this is also possible
with the LDAP protocol, isn't it? Isn't the only difference 
that LDAP gives the whole certificate or CRL, while the 
OCSP only gives the status?

- Do you put the OCSP protocol _in_ an HTML file? Do you 
have to define new tags?  Are there examples avaiable 
somewhere? Do Netscape and Microsoft have to put this 
procotol in their browsers? (Sorry for the dumb questions.)

- A small remark about the security of LDAP: it is true 
that the messages don't need to be signed because the CA 
allready signed the certs ans CRL. BUT a nasty LDAPd could 
just answer on a request: 'I don't have that certificate 
or CRL' while he actually does have it. 
Perhaps a way to solve this is a CIL or Certficate Issue List 
(it's in a paper by Silvio Micali, you can find a copy at 
http://www.esat.kuleuven.ac.be/~hoeben/micali.ps). In that
list the CA just puts the serial numbers of the certs (eventually 
after removing some redundancy) and signs it. If there comes a 
request for a cert the CA didn't issue, the LDAPd just gives
the CIL to prove he hasn't got the cert.
I guess this CIL is allready possible in X.509 v3, with the 
aid of private extensions, isn't it?

   Greetings, Stef

Date: Sun, 06 Apr 97 19:42:41 
From: "Housley, Russ" <[email-masked]>
Encoding: 1376 Text
To: [email-masked], [email-masked]
Subject: Re: operational protocols

Stef:

I do not see how the CIL can be usefully used as a certificate extension.  
Please provide a more detailed explaination.

Also, the CIL provides proof that the Directory should have had the 
certificate available, but it cannot do anything to force the Directory to 
provde it to the user.

Russ

______________________________ Reply Separator _________________________________
Subject: operational protocols
Author:  Stef Hoeben <[email-masked]>
Date:    4/3/97 6:21 AM

Hello,

[some stuff deleted]

- A small remark about the security of LDAP: it is true 
that the messages don't need to be signed because the CA 
allready signed the certs ans CRL. BUT a nasty LDAPd could 
just answer on a request: 'I don't have that certificate 
or CRL' while he actually does have it. 
Perhaps a way to solve this is a CIL or Certficate Issue List 
(it's in a paper by Silvio Micali, you can find a copy at 
http://www.esat.kuleuven.ac.be/~hoeben/micali.ps). In that
list the CA just puts the serial numbers of the certs (eventually 
after removing some redundancy) and signs it. If there comes a 
request for a cert the CA didn't issue, the LDAPd just gives
the CIL to prove he hasn't got the cert.
I guess this CIL is allready possible in X.509 v3, with the 
aid of private extensions, isn't it?

   Greetings, Stef

From: Brian Korver <[email-masked]>
Subject: Re: ASN.1 types for Distinguished names (was: Re: Distinguished n
To: [email-masked] (Holger Reif)
Date: Thu, 3 Apr 1997 12:11:01 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Holger Reif writes:
> Where is BMPString defined? What are it's encoding rules? Does it mean a
> directoryString as defines in X.520 (selected Atrributes) Version 2 is
> now a choice of printableString, teletexString, universalString and 
> BMPString?

BMPString is exactly Unicode (ISO 10646-1 Annex A).  I'm pretty sure
it's an ASN.1:1994 type (just like UniversalString).  See X.680.

brian
[email-masked]

Date: Thu, 3 Apr 1997 12:45:35 -0500
From: John Lowry <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: ASN.1 types for Distinguished names (was: Re: Distinguished n ames and
Cc: [email-masked], [email-masked]

A couple of datapoints with NO assertion as to correctness:

BBN systems default to a method of "least inclusive" set when trying 
to determine which character encoding to use.  That means we try to 
encode as PrintableString first, then T61 and finally UniversalString.  
(This behavior can be configured and specified to be different is desired.)

We note that Microsoft IE seems to go from PrintableSting straight
to UniversalString encodings with the net result that many certificates
will have multi-byte encodings.

Are there any other datapoints ?

John Lowry

> From <@suntan.tandem.com:[email-masked]>  Wed Apr  2 21:28:08 1997
> From: Andrew Probert <[email-masked]>
> To: "'Brian Korver'" <[email-masked]>, [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: RE: ASN.1 types for Distinguished names (was: Re: Distinguished n
> 	ames and
> Date: Thu, 3 Apr 1997 12:13:46 +1000
> X-Priority: 3
> Mime-Version: 1.0
> 
> Further to my previous email, here is a comment from Microsoft:
> 
> <snip>
> We have UNICODE X.509 Name ASN.1 encode/decode routines. When converting
> UNICODE to a T61String we convert to UTF8. The UTF8 represents the
> characters 0 .. 0x7f as a single byte, 0x80 .. 0x7ff as two bytes, and
> 0x800 ..0xffff as three bytes. UTF8 is also being used by Java.
> 
> <snip>
> 
> > -----Original Message-----
> > From:	Brian Korver [SMTP:[email-masked]]
> > Sent:	Thursday, April 03, 1997 3:32 AM
> > To:	[email-masked]
> > Cc:	[email-masked]; [email-masked]
> > Subject:	Re: ASN.1 types for Distinguished names (was: Re:
> > Distinguished names and
> > 
> > 
> > Holger Reif writes:
> > > 
> > > Hi,
> > > 
> > > this seems to be a nice thread to jump in ;-)
> > > 
> > > I noticed that many of the X.520 Selected attributes are of type
> > DirectoryString
> > > which in turn is a choice of teletexString, printableString and
> > universalString.
> > > Does anybody know when which Form is to be used and wether a
> > transformation 
> > > between these types (if possible) is allowed and gives equal
> > meaning. 
> > 
> > BMPString has basically replaced UniversalString because, I have
> > been told, nobody used UniversalString.  I can be believe this.
> > 
> > Both TeletexString (T61String) and PrintableString have constraints as
> > to what can be placed in them.  So for instance if you need to use a
> > character such as '@', you cannot use PrintableString.
> > 
> > I'm unaware of any equality rules to use when comparing strings of 
> > unequal type.  I assume that most implementations assume that strings
> > of unequal type are by definition not equal.  IMHO this is the best
> > approach because of the lack of well-defined equality matching rules.
> > 
> > I'm also unaware of any rules for "which string do I use" when there
> > are multiple string types to choose from.
> > 
> > 
> > > Of course, if it's within a SIGNED context then the answer is clear:
> > 
> > > one can't change the types. But in other cases?
> > 
> > brian
> > [email-masked]
> 

Date: Thu, 03 Apr 1997 09:01:30 -0500
From: "Hoffman, Mort" <[email-masked]>
Subject: OOPS -- Correction.  RE: pkix part 1, draft 4:  UTCTime vs GeneralizedTime dates anomaly
To: "[email-masked]'" <[email-masked]>, "'Tim Polk'" <[email-masked]>, "'Hoffman, Mort'" <[email-masked]>

Sorry, one wrong word makes it all make no sense.  Correction below:

>----------
>From: 	Hoffman, Mort[SMTP:[email-masked]]
>Sent: 	Wednesday, April 02, 1997 4:55 PM
>To: 	[email-masked]'; 'Tim Polk'
>Subject: 	RE: pkix part 1, draft 4:  UTCTime vs GeneralizedTime dates anomaly
>
>Tim,
>
>Reading throught the spec I ran into the following anomaly:  section
>4.1.2.5 specifies that dates in the year 2050 should be generated as
>GeneralizedTime (not UTCTime), and section 4.1.2.5.1 specifies that UTCTime
>dates encoded with
>the year set to 50 shall be interpreted as 2050.  Now, since there were
>no CAs existing in the year 1950, then there should not exist any such
>dates in certificates at all (OK, this could be argued with on strictly
>technical grounds, but I think it is basically true).  Therefore the
>anomaly in the spec should not really affect anything, but if someone
>writing code to generate certificates read section 4.1.2.5.1 instead of
>4.1.2.5, then he would be lead astray.
>
>I imagine all this traces back to the discussion in the X.509 arena on
>the dates, but I deleted that mail and I don't know if the anomaly
>existed there.  If it didn't then the fix would be to fully align to
>what was agreed in X.509.  Otherwise, I guess I'd recommend that a
>UTCTime encoded with 50 should be rejected, since it could not have been
>legally generated.
>
>Mort 
>
>

Organization: ESAT, K.U.Leuven, Belgium
Date: Thu, 3 Apr 1997 15:18:30 +0200 (MET DST)
From: Stef Hoeben <[email-masked]>
Reply-To: Stef Hoeben <[email-masked]>
To: [email-masked]
Subject: operational protocols

Hello,

Some questions about the ipki2opp-00 draft (by the way,
nice work:)

- In the abstract, it looks like only the OCSP protocol
can be use for online checking. But this is also possible
with the LDAP protocol, isn't it? Isn't the only difference
that LDAP gives the whole certificate or CRL, while the
OCSP only gives the status?

- Do you put the OCSP protocol _in_ an HTML file? Do you
have to define new tags?  Are there examples avaiable 
somewhere? Do Netscape and Microsoft have to put this 
procotol in their browsers? (Sorry for the dumb questions.)

- A small remark about the security of LDAP: it is true
that the messages don't need to be signed because the CA
allready signed the certs ans CRL. BUT a nasty LDAPd could
just answer on a request: 'I don't have that certificate
or CRL' while he actually does have it. 
Perhaps a way to solve this is a CIL or Certficate Issue List 
(it's in a paper by Silvio Micali, you can find a copy at
http://www.esat.kuleuven.ac.be/~hoeben/micali.ps). In that
list the CA just puts the serial numbers of the certs (eventually
after removing some redundancy) and signs it. If there comes a 
request for a cert the CA didn't issue, the LDAPd just gives
the CIL to prove he hasn't got the cert.
I guess this CIL is allready possible in X.509 v3, with the
aid of private extensions, isn't it?

			Greetings, Stef

To: Brian Korver <[email-masked]>
cc: " (Holger Reif)" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ASN.1 types for Distinguished names (was: Re: Distinguished names  and 
Date: Thu, 03 Apr 1997 08:03:14 +0100
From: Julian Onions <[email-masked]>

When comparing DN's you should actually use the matching rules defined
in X.500 for each RDN component. This tells you whether two components are
equal. So to get it right in all cases is quite laborious.
However, for the majority of cases you can make it simple as there 
in practice only about two matching rules in common usage.

Most components are of syntax DirectoryString and are derived from the
name attribute (http://domen.uninett.no/~hta/ietf/oid/2.5.4.41.html).
These all mostly use caseIgnoreMatch for comparison 
(http://domen.uninett.no/~hta/ietf/oid/2.5.13.2.html) in which 
characters are considered equal if 'corresponding characters' match.
And as X.500 says...

"Where the strings being matched are of different ASN.1 syntax, the
comparison proceeds as normal so long as the corresponding characters
are in both character sets. Otherwise matching fails."

Which implies for implementation, mapping one syntax into another
before comparison.

As to what ASN.1 syntax you choose from the choice - given the above rules
it doesn't much matter providing it is representable. Therefore printable
string is the simplest if you've got the basic latin alphabet. If you need
to represent accents or odd punctuation characters, you need to use
one of the other alternatives, but you could always go for the most complex
encoding if required.

One thing not mentioned in the rules but is a general note, is
that for string syntaxes, space characters are handled specially. That is
- leading and trailing spaces are ignored.
- multiple consecutive spaces are considered to be one space
- a string consisting only of spaces is considered to be equal to a single
  space

Julian.

P.S. As to certificate and CRL extensions - there is a mostly complete
list of the X.500(97) ones at 
http://domen.uninett.no/~hta/ietf/oid/2.5.29.html

Date: Thu, 3 Apr 97 08:30:52 +0200
From: [email-masked] (Holger Reif)
To: [email-masked], [email-masked]
Subject: Re: ASN.1 types for Distinguished names (was: Re: Distinguished n
Cc: [email-masked], [email-masked], [email-masked]

Brian Korver wrote:
> Andrew Probert writes:
> > 
> > Further to my previous email, here is a comment from Microsoft:
> > 
> > <snip>
> > We have UNICODE X.509 Name ASN.1 encode/decode routines. When converting
> > UNICODE to a T61String we convert to UTF8. The UTF8 represents the
> > characters 0 .. 0x7f as a single byte, 0x80 .. 0x7ff as two bytes, and
> > 0x800 ..0xffff as three bytes. UTF8 is also being used by Java.
> > 
> > <snip>
> > 
> 
> The addition of BMPString is recent,

Where is BMPString defined? What are it's encoding rules? Does it mean a
directoryString as defines in X.520 (selected Atrributes) Version 2 is
now a choice of printableString, teletexString, universalString and 
BMPString?

> so it's not too surprising that they
> didn't use it, although it is a little strange to me that they didn't
> use UniversalString.

They use UniversalString! at least their ActiveX control certenr3.dll for
the MS Internet Explorer certificate enrollment and acceptance generates
an UniversalString if one leaves the allowed range for printableString
(eg. a "!").
 
> brian
> [email-masked]
> 

Date: Thu, 3 Apr 1997 14:10:43 +0900 (JST)
From: [email-masked] (Hiroaki Kikuchi)
To: "[email-masked]'" <[email-masked]>
Subject: I-D: draft-kikuchi-web-cert-repository-00.txt

Hi,

At the Memphis meeting, I will make a brief presentation of our proposal
"Web-based Certificate and CRL repository", the Internet draft
draft-kikuchi-web-cert-repository-00.txt. Any comment would be appreciated
for us.

-- 
%-------------------------------------------------------------------------
%	Hiroaki Kikuchi, Tokai Univ. Dept. of Electrical Engineering
%	Tel: +81-463-58-1211 Ext. 4164, Fax: +81-463-59-4014
%-------------------------------------------------------------------------

PKIX Working Group                               H. Kikuchi (Tokai Univ)
Internet Draft                                          M. Sakurai (NEC)
                                                 H. Hattori (Meiji Univ)
                                             Y. Sameshima (Hitachi Soft)
expires in six months                                         March 1997

                  Internet Public Key Infrastructure:

                Web-based Certificate and CRL Repository

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

   This document provides a specification how to publish and retrieve
   X.509 certificates and certificate revocation lists (CRLs).  In the
   proposed method, the World Wide Web (WWW) is used for securely
   distributing certificates across a firewall in both human and machine
   readable syntax. A various certificate concerning information that
   includes certificates, CRLs, and certification authority (CA) policy
   are retrieved from an integrated single authority access point
   specified in X.509 version 3 extensions. The information access point
   accepts certification and revocation requests in the uniform access
   method based on the standard WWW.

Kikuchi                                                         [Page 1]

Internet DRAFT                                                March 1997

1. Introduction

   The first attempt for security enhancement of the Internet
   applications was electrionic mail. The Privacy Enhanced Mail (PEM)
   defined in [RFC-1421, 1422, 1423 and 1424] proposed X.509 public key
   certificates and hierarchically structured certification authorities
   (CAs), which are then adopted in MOSS [MOSS] and S/MIME [S/MIME].
   These security protocols, however, require that a sender has to
   convey many certificates needed to certify its validity from a
   receiver because of the lack of certificates repository. Therefore, a
   big challenge to establish Public Key Infrastructure (PKI) is made by
   specifying profiles of the X.509 version 3 certificate and version 2
   CRL [PKIX-1]. The PKI working group also proposed certificate
   management protocols in [PKIX-3], in which wide range of CA
   information format called PKI messages are defined by ASN.1 [ASN.1]
   that makes processing easier for management software, and simple
   socket based transport protocols.

   However, in the practical point of view, the socket based transport
   protocol is problematic. First, most commercial organization have a
   firewall, which prevents intruder from gaining access to internal LAN
   and might reject PKI message transfer. For this reason, they shall
   provide a proxy service for each protocol. Second problem is
   confidentiality of PKI messages. Although most PKI message are public
   information, the initializing message such as certification or
   revocation requests require an extra capability of message encryption
   for achieving confidentiality. The third problem is the scaleability,
   which makes the service available in the wide scale networks.  The
   requirement involves reducing traffic cost by a certificates cashing
   or a distributed database. The last problem is ASN.1 based definition
   which forces Basic Encoding Rule (BER) to transfer a PKI messages.
   For easier implementation, human readable encoding rule is
   appropriate.

   To meet these requirements, this document defines World Wide Web
   (WWW) based certification and CRL repository. Since WWW is now one of
   the major application in the internet, almost all internet users can
   use it even if the site they belong has a firewall against intruders.
   The WWW provides some useful facilities for PKI; an information
   cashing by both a proxy server and client software, a secure
   transport layer service for confidentiality, a flexible request
   forwarding which can be used in CA and CA communication, and human
   readable and easier manipulating message format.

Kikuchi                                                         [Page 2]

Internet DRAFT                                                March 1997

2. Basic Definition, Requirements and Assumptions

2.1 Overview

   This document suppose simple restricted hierarchical certificate
   infrastructure rather than complicated CA web.  Figure 1 shows an
   example of hierarchy of Publishing Authority (PAs), where PA2 has two
   subordinary PAs, PA1 and PA2, and PA1 has two users having
   certificate Cert1 and Cert2, respectively.

   Every certificate has one information access point (IAP) from which
   any information with regards to users can be retrieved.  The PA is
   responsible for all information it publishes. Thus, it also provides
   on-line validation service with and without CRLs.  The PA
   certificate, which may be identical to the standard CA certificate,
   also has upper IAP entry. There is no different in IAP syntax among
   end entity, PA and CA. None of user and PAs publish certificate by
   theirselves, that is, subject information access extension is not
   necessary. The IAP specification is defined in Section 2.2.

   The communication between entities was based on Hyper Text Transfer
   Protocol (HTTP) and its variation. The Hyper Text Markup Language is
   used as message format. Note that a subordinate entity is subject to
   be message sender and the higher entity just response to the
   requester.  Thus, the coordinate entities never get direct
   communication with them.  This assumption is convenient for
   conformance.  The end entity and PA protocol is defined in Section 3.

                                                    +-----+
                                                    |     |
                                                PA3 V     |
                                             IAP3+---+    |
                                           +---->| *------+
                                   PA1     |     +---+
                              IAP1 +---+   |
                          +------->| *-----+
               Cert1      |        +---+   |
                   +---+  |                |
                   | *----+                |
                   +---+  |        PA2     |
               Cert2      |        +---+   |
                   +---+  |        | *-----+
                   | *----+        +---+
                   +---+

                     Figure 1: Example of PAs hierarchy

Kikuchi                                                         [Page 3]

Internet DRAFT                                                March 1997

2.2 Requirement for PKI Application

   The PKI application needs certificates and CRL repository in the
   following three cases;

   1. certificate retrieval.
      For example, a sender of secure message wants to retrieve
      the recipient's public key by which the message is to be
      encrypted.

   2. certificate verification.
      The recipient of secure message check if the sender's certificate
      is not revoked by examining the corresponding CRL or asking
      the CA directly.

   3. certificate and CRL publication.
      Soon after a certificate is issued by a CA, the new certificate
      shall be got access for anybody who wants it.

2.3 Requirement for X.509 Version 3 Certificate and Extensions

   This proposal supposes that subset of X.509 Version 3 is used to form
   public key certificates. According to [PKIX1], the subject and issuer
   names in X.509 (v1) may be an empty sequence and subjectAltName and
   issuerAltName extensions (v3) shall be specified instead of the
   field. Even if the subject and issuer names are specified, the
   subjectAltName shall be given as an identification of certificate
   retrieval.

   Most PKI applications require many kinds of information about
   certificate including policy information, CRL, and CA information. In
   [PKIX1], several access methods are defined for each kind of
   information.  However, it is not so often case that a certain
   application has multiple access methods to PKI. Therefore, this
   document assumes that PKI application has an uniform access method of
   HTTP for for the simplification of PKI protocol.

   As the same reason, the subjectInfoAccess, the authrotyInfoAccess and
   the caInfoAccess can be unified to the authorityInfoAccess.  The
   subjectInfoAccess may be meaningless because a PKI user needs the
   information access point in two cases; (1) when it wants to verify
   the sender's certificate after it receives a secure message, or (2)
   when it wants to retrieve its recipient's certificate before it
   sends.  In the first case, he/she cannot believe any information
   provided by the subjectInfoAccess, which the sender itself specify,
   and thus may be altered. Hence, he/she shall use the
   authrotyInfoAccess instead of the subjectInfoAccess.  The other case,

Kikuchi                                                         [Page 4]

Internet DRAFT                                                March 1997

   he/she has not yet known the subject information access point which
   is to be specified the recipient's certificate, which shall be
   retrieved from any authrotyInfoAccess point she/he knows.  Once PKI
   user gets the recipient's certificate, the subjectInfoAccess is no
   longer necessary for him/her.  Consequently, the subjectInfoAccess is
   useless.

   The AuthorityInfoAccess contains at least one AccessDescription in
   which the accessMethod and accessLocation shall specify httpID and
   appropriately URL that accepts "POST" method.

   If this proposal is used, a standard certificate must specify

      - authorityInfoAccess,

   shall specify

      - subjectAltName,
      - issuerAltName,

   may specify

      - authorityKeyIdentifier,
      - subjectKeyIdentifier,
      - keyUsage,
      - privateKeyUsagePeriod,
      - certificagtePolicies,
      - basicConstraints,
      - nameConstraints,
      - policyConstraints,

   must not specify for avoiding confusion

      - cRLDistributionPoints,
      - policyMappings,
      - subjectDirectoryAttributes,
      - subjectInfoAccess,
      - authorityInfoAccess,
      - caInfoAccess.

2.4 Requirement for Publishing Authority

   Since the number of PKI user increases step by step, the set of CAs
   always have to keep communicating with each other. Moreover, the
   number of CA also increases slightly, so, the hierarchical CAs
   structure is proposed in [RFC1422]. Where, the root CA is required to
   update all CAs and to manage the access path.

Kikuchi                                                         [Page 5]

Internet DRAFT                                                March 1997

   However, in practice, at the entrance to the Internet every
   organization has a firewall facility which restricts internet access
   to a particular application, service, and host in order for security
   consideration. Thus, generally, an CA runs within the firewall and
   only communicates with internal PKI users.  Therefore, we need a
   publishing authority (PA) that is set up for each CA and works as a
   certificate repository outside of the firewall.  Figure 2 shows this
   structure.

   The transaction between particular entities can be easily restricted
   by a firewall, thus, it does not spoil the security of CA.  An
   internal static information access point provides a simple and
   uniform access method for PKI users. Any information stored in
   external PA is not secret information and may be different to that of
   internal PA.

                                           [root PA]
                            The Internet       |
                           ---+------+---------+-
                              |      |
                         |    |      |   |
                   [CA]--+---[PA]  [PA]--+--[CA]
                   /|    |               |    |
             PKI users   |               |   PKI users
                        firewall    firewall

              Figure 2. Relationship between PA and CA

3. Transport Protocol

3.1 Information Access
   Information access point (IAP) is specified by the subjectInfoAccess
   field in certificate extension. The IAP is a point from which
   certificates are distributed and on-line verification service is
   provided.

   The PA server can be implemented as a standard HTTP server which
   enables CGI facility. The IAP server works as PA, CRL distribution
   point, policy repository, verification server, and certificate
   repository.  The PA server management certificates in a specific
   closed organization, and communicates with upper PA server which
   knows the all subordinate PA server's location.

   A PKI application points at least one IAP so as to retrieve locations
   of other IAPs.

Kikuchi                                                         [Page 6]

Internet DRAFT                                                March 1997

   An information transfer is based on HTTP with method POST.  Thus, the
   typical query is formated as follows;

           POST IAP/queryType HTTP/1.0
           name1=value1&name2=value2&...&namen=valuen

   where "queryType" is a type of query and a pair of "name" and "value"
   are used to send PKI message. All fields are subject to be formed in
   standard encoding rule defined in [HTTP].

           HTTP/1.0 200 OK
           Date: Wednesday
           MIME-version: 1.0
           Content-type: text/html

           <HEAD><TITLE>queryType</TITLE></HEAD>
           <BODY>
           <H3> statusCode </H3>
           <H1> statusMessage </H1>
                information
           </BODY>

   Where, "queryType" is the same as the type given in sending request.
   The "statusCode" contains a status with three digit codes.  With at
   least one space, the "statusMessage" and "information" are
   interpreted in corresponding semantics.  The syntax of "information"
   depends on the query type, and will be defined section 5.

3.2 Type of Query

   This document defines the followings query types.

           1. certreq         2. revokereq         3. lookupreq
           4. verifyreq

3.2.1 Initial Registration type "certreq"

   Type "certreq" is used for sending certification request to CA.  This
   query may be used only if the PA works as CA or has some means to
   relay the request to the corresponding CA.  The certreq request shall
   be sent with some of the following pairs of name and value.

           name            value
           ----            -----
           o               Organization
           ou1             Organizational unit

Kikuchi                                                         [Page 7]

Internet DRAFT                                                March 1997

           ou2             Organizational unit 2
           ou3             Organizational unit 3
           ou4             Organizational unit 4
           cn              Common name
           n               public component of RSA cryptosystem
           email           RFC822 style email address
           info            URL of user's home page
           key             public key encoded in corresponding BER
           acct            User identification
           pass            User password
           loginname       Manager identification
           password        Manager password

   The pair "o", "cn", "n", "email" are critical pairs.  The name "n"
   implicitly identifies a modulo value when public component of 0x10001
   is used in RSA cryptosystem. Otherwise, name "key" shall be used to
   convey public key information which is encoded in the corresponding
   BER rule. Either of "n" and "key" must be given.  The "acct" and
   "pass" may be used for user authentication.  If these pairs are
   missing, the response shall contain the other pairs as hidden
   attribute     and be used as confirmation of user information.
   Alternatively, the "loginname" and "password" may be used by the CA
   manage.

   The response consists of statusCode, statusMessage and information.

       statusCode  statusMessage           information
       ----------  -------------           -----------
           200     "accept your request"   the issued certificate
                                           encoded in Base64 encoding rule.
           301     "incomplete request"    the missing pair
                                           and the other information
           302     "duplicate request"     the certificate has already been
                                           issued.
           303     "reject your request"   any other reason why the request
                                           failed.
           304     "service not available" the PA does not accept this request.

3.2.2 Certificate Revocation "revokereq"

   The "revokereq" is a request to revoke a certificate.  To prevent
   malicious PKI user from revoking other's certificate, this request
   should be sent with a proof of possession of the secret key. The
   simplest way is to use conventical application that supports digital
   signature.

           name            value

Kikuchi                                                         [Page 8]

Internet DRAFT                                                March 1997

           ----            -----
           sig             digitally signed revocation message

       statusCode  statusMessage           information
       ----------  -------------           -----------
           200     "accept your request"   nothing (the certificate is revoked)
           301     "invalid signature"     nothing
           302     "duplicate request"     nothing (the certificate has already
                                           been revoked)
           303     "reject your request"   any other reason why the request
                                           failed.
           304     "service not available" the PA does not accept this request.

3.2.3 Certificate Distribution "lookupreq"

   The "lookupreq" type is used for retrieving and searching
   certificate, CRLs, and any other information.  The PA server may
   forward a request to other PA server when it does not has sufficient
   information to response to the request.

   Certificate is identified by either of the following names;

           a. email address         b. Distinguished Name

   Both identifiers must be fully specified because a substring matching
   rule might violate a privacy issue when the PA is the outside of
   firewall.  The lookup query is sent with the following pairs of names
   and value.

           name            value
           ----            -----
           o               Organization
           ou1             Organizational unit
           ou2             Organizational unit 2
           ou3             Organizational unit 3
           ou4             Organizational unit 4
           cn              Common name
           dn              subject/CA Distinguished Name.
           email           subject/CA email address
           object          "policy" (policy description and mapping)
                           "cert"  (CA or subject certificate)
                           "crl"   (CA CRL)

   The pairs of  "o", "ou1", "ou2", "ou3", "ou4", and "cn" specify
   intend distinguished name. Alternatively, the "dn" pair may be used
   to specify distinguished names. When the specification is incomplete,
   the PA may reject it for privacy issue or accept it as substring
   matching.  Whether the request is for subject or for CA can be

Kikuchi                                                         [Page 9]

Internet DRAFT                                                March 1997

   identified by the distinguished name. For example, a distinguished
   name containing "cn=Authority" is a request for CA, otherwise for
   subject.  The "object" specifies what information is required and
   takes "cert" in default.  For instance, a request with "object=crl"
   is equivalent to the request by crlDistributionPoint extension.

   The response consists of statusCode, statusMessage and information.

       statusCode  statusMessage           information
       ----------  -------------           -----------
           200     "accept your request"   the certificate, policy or CRL
                                           encoded in Base64 encoding rule.

           301     "revoked"               the reason of revoked
           302     "reject your request"   the reason why the request failed.
           303     "service not available" the PA does not accept this request.

3.2.4 Certificate Verification "verifyreq"

   Type "verifyreq" is used for validation check of certificate.  This
   document does not support path validation.  The verifyreq request
   shall be sent with the following pairs of name and value.

           name            value
           ----            -----
           cert            certificate embedded in CGI coding rule
           certsig         certificate embedded in CGI coding rule
           crl             DN of intended certificate
           sn              serial number of a certificate
           time            GENERALIZED TIME when certificate
                           should be checked to be valid.
           dn              request originator's distinguished name

   The "certsig" request has the PA digitally signed its response.  The
   PKI user specify a certificate by either sending the whole
   certificate with "cert" or just sending "sn" when the implicit PA
   server can be determined.  The "time" is optional pair, which means
   when the certificate to be examined. This option is used when one
   wants to verify if an old message was valid at that time.

   When "cert" is specified, the certificate to be verified is embedded
   into the value in CGI coding rule.  The "certsig" is same as the
   "cert" except but it responses with message integrity check code.

   When "crl" is specified, PA server only make sure if the intended
   certificate is already revoked.

Kikuchi                                                        [Page 10]

Internet DRAFT                                                March 1997

   The "dn" is used when the PA provides verification service only to
   restricted users.

   The response of "cert" request is as follows.

       statusCode  statusMessage           information
       ----------  -------------           -----------
           200     "valid"                 nothing (the certificate is valid)
           201     "not revoked"           nothing (the certificate is not revoked)

           301     "revoked"               the reason of revoked
           302     "hold"                  the reason of hold

           303     "reject your request"   any other reason why the request
                                           failed.
           304     "service not avialable" the PA does not accept this request.

   Some example of reason of revoked are such that the key was
   compromised, or the affiliation was changed.

3.3 Correspondence to preceding PKI draft

   This document corresponds to PKI management protocol defined in
   [PKIX3].  Table 1 shows the correspondence and side effect occurred
   by a request.

                   Table 1. Correspondence of methods

           PKI method              PA method       Side effect
           ------------            ----------      -----------
           certStatus              verify          no
           certRetrieval           lookup          no
           caPolicy                lookup          no
           caCert                  lookup          no

           CRLDistributionPoint    lookup          no

           certReq                 certreq         yes
           revokeReq               revokereq       yes

3.4 Inter-PA Protocol

   If a request to a PA concerns information not stored in the PA, the
   PA shall manage to obtain it by relying the request to an appropriate
   PA. This section define an inter-PA transaction.

Kikuchi                                                        [Page 11]

Internet DRAFT                                                March 1997

3.4.1 PA Model

   Suppose that there are PA1, PA2 and RootPA, and PA1 has a request for
   retrieving information from PA2. The PA1 and PA2 does not have their
   locations but the access point to RootCA.  There are two
   possibilities for PA1 to get access to PA2 (Figure 3).

    - Model 1. [referral] PA1 sends the request to Root PA (1), which
   then         replies to PA1 with the access point to PA2 (2).
           PA1 sends it to PA2 again (3), and finally PA1 gets
           the information from PA2.

    - Model 2. [chaining] PA1 sends the request to Root PA (1), which
           redirects it to PA2 on behalf of PA1 (2). PA2 answers
           to Root PA (3), which forwards it to PA1 (4).

              +---->[RootPA]                          +---->[RootPA](2)---+
              | +---(2)                               | +---(4)     <---+ |
              | |PA2                                  | |               | |
              | |                                     | |               | |
           (1)| V                                  (1)| V            (3)| V
             [PA1] (3)-----------> [PA2]             [PA1]             [PA2]
                   <-----------(4)

                   Referral                                Chaining

                           Figure 3. Inter-PA models

3.4.2 Referral Model

   To redirect a request to another PA server, the root PA responds to
   the requester with the following HTTP redirect message consisting
   HTTP header and HTTP body.

       HTTP/1.0 302 Found
       Date: Monday, 20-Jan-97 13:33:29 GMT
       Server: NCSA/1.1
       MIME-version: 1.0
       Location: http://xxx.yy:zz/method
       Content-type: text/html

       <HEAD><TITLE>Document moved</TITLE></HEAD>
       <BODY><H1>Document moved</H1>
       This document has moved <A HREF="http://xxx.yy:zz">here</A>.<P>
       </BODY>

Kikuchi                                                        [Page 12]

Internet DRAFT                                                March 1997

   Where the URL "http://xxx.yy:zz/method" specified by the Location
   HTTP header     provides information where the query to be sent next.
   This is a control message used in the standard HTTP transaction
   [HTTP].

   The root PA must respond with either correct PA location or error
   message to mean that there is no certificate.  To do this, all
   correspondences between identifiers and IAP locations should be
   notified by the root PA.

   In this model, PKI application or PA must support HTTP redirect
   message. Each round trip time is short, but PA has to send the same
   query to several servers.

3.4.3 CGI Chaining Model

   To implement CGI chaining model, the CGI script in root PA produces
   an extra CGI message before it responds to the request originator.

   The request originator, PA1 or PKI application, does not have to send
   request many times, but have to wait longer time than that of
   referral model. According to [Mine], the estimated total round trip
   time is less than that of the referral model.  Since PA communicates
   with a particular PA, the access control at firewall can be easily
   set up.

4. Security Consideration

4.1 Confidentiality of transaction

   To prevent message from being eavesdropped, secure communication
   channel such as SSL shall be used. Especially, initial registration
   process is critical to eavesdropping. Since user authentication is
   checked by "uid" and "passwd", a client software is not required to
   have its own certificate.  Under the assumption, PKI message
   protection proposed in [PKIX3] need not here.

4.2 Non-Repudiation

   The verify request supports the time to be checked and digitally
   signed response. This can avoid a message sender from denying the
   message. To enable this service, any PA must manage all certificates
   which it has already issued, including revoked certificates.

Kikuchi                                                        [Page 13]

Internet DRAFT                                                March 1997

4.3 Privacy

   In the lookup request, the support of substring matching facility may
   distribute private information to outsiders, and thereby may be used
   for sending an advertisement via email.

5. ASN.1 encoding rule in HTML

5.1 Definition

   A certificate management protocol is defined in ASN.1 syntax in
   [PKIX3].  The BER is not human readable but is better for security
   enhancements such as an integrity checking, whereas the ASCII text is
   human readable but not suitable for machine processing. Therefore,
   this document defines ASN.1 encoding rule in HTML, which can be both
   human and machine readable encoding.

   In the BER, any data type is formed with three elements, tag, length,
   and value. Instead of the length field, the HTML encoding identifies
   the value field by specifying the data start tag and the data end
   tag.  The printable string data type and UTC time type are specified
   by the <H3> and </H3> tag.  The other data type is defined by the
   <H5> and </H5> tag.  The structured types, SET and SEQUENCE, are
   defined by the <UL> tag and <OL> tag, respectively.  For the inverse
   function of the encoding, the corresponding data tag number follows
   the tag name in two octet hexadecimal numbers.

   The printable string data value is represented in ASCII.  The other
   data value is represented in hexadecimal octet string.  The document
   does not define a means to encode bit string data.  For easier
   implementation, this document define a set of data value encoded in
   Base64, which is identified by <Blockquote> and </Blockquote> tag.
   This notation is useful when PKI application transfers the whole
   certificate without interpreting the contents.

   The encoding rule allows no optional notation, no tagged type and no
   default value.  Every data type is specified explicitly in order to
   for uniquely distinguishing data types.

   Table 2 shows main data type and the encoding format.  Where, "n",
   "s" are examples of numbers and string, and "a" and "b" are of any
   ASN.1 data type.  For example, an integer 12 is coded by "<H5
   03>0C</H5>".

                   Table 2. HTML Encoding Rule

           ASN.1 Data Type         HTML Encoding

Kikuchi                                                        [Page 14]

Internet DRAFT                                                March 1997

           ---------------         --------------
           BOOLEAN                 <H5 01> n </H5>
           INTEGER                 <H5 02> n </H5>
           BIT STRING              <H5 03> n </H5>
           OCTET STRING            <H5 04> n </H5>
           NULL                    <H5 05> </H5>
           OBJECT IDENTIFIER       <H5 06> n </H5>

           PrintableString         <H3 13> s </H3>
           IA5String               <H3 16> s </H3>
           UTCTime                 <H3 17> s </H3>
           GeneralizedTime         <H3 18> s </H3>

           SEQUENCE {a, b}         <OL 30> <LI> a <LI> b </OL>
           SET {a, b}              <UL 31> <LI> a <LI> b </UL>

           xxx (Base64 format)     <BlockQuote> xxx </BlockQuote>

5.2 Example

   A PKI message format and the corresponding encoding are as follows.
   Note that the tagged data protection and extraCerts are not omitted.
       PKIMessage ::= SEQUENCE {
         header           PKIHeader,
         body             PKIBody,
         protection   [0] PKIProtection OPTIONAL,
         extraCerts   [1] SEQUENCE OF Certificate OPTIONAL
       }

       <OL 30>
         <LI> PKIHeader
         <LI> PKIBody
         <LI> PKIProtection
         <LI> <OL 30>
                   <LI> Certificate 1
                   <LI> Certificate 2
              </OL>
       </OL>

   A distinguished name consisting of countryName="JP",
   organizationName="ICAT", and organizationalUnitName="Certification
   Authority" is encoded as follows.
       <OL 30><LI>
            <UL 31><LI>
               <OL 30><LI>
                  <H5 06>550406</H5><LI>
                  <H3 13>JP</H3>

Kikuchi                                                        [Page 15]

Internet DRAFT                                                March 1997

               </OL>
            </UL><LI>
            <UL 31><LI>
               <OL 30><LI>
                  <H5 06>55040a</H5><LI>
                  <H3 13>ICAT</H3>
               </OL>
            </UL><LI>
            <UL 31><LI>
               <OL 30><LI>
                  <H5 06>55040b</H5><LI>
                  <H3 13>Certification Authority</H3>
               </OL>
            </UL>
         </OL>

Acknowledgement

   The authors thank Mr. Ohbayashi, Mr. Kobayashi, Mr. Kuroda, Mr.
   Fujimoto, and Mr. Wada for their comments to this proposal.  The
   authors also thank the other researchers joining the Initiative
   Computer Authentication Technology (ICAT), and the Interauth working
   group of WIDE project.

Reference

           [PKIX-1] R. Housley, et. al., "Internet Public Key Infrastructure
                   Part I: X.509 Certificate and CRL Profile,"
                   <draft-ietf-pkix-ipki-part1-03.txt>, December 1996

           [PKIX-3] S. Farrell and C. Adams, "Internet Public Key Infrastructure
                   Part III: Certificate Management Protocols,"
                   <draft-ietf-pkix-ipki3cmp-02.txt>, December 1996

           [RFC1422] Kent, S.,  "Privacy Enhancement for Internet Electronic
                   Mail: Part II: Certificate-Based Key Management,"
                   RFC 1422, February 1993.

           [S/MIME] S. Dusse, "S/MIME Message Specification: PKCS Security
                   Services for MIME",  <draft-dusse-mime-msg-spec-00.txt>
                   September 1996

           [MOSS] S. Crocker, et. al., MIME Object Security Services,
                   RFC 1848, October 1995

           [HTTP] T. Berners-Lee, R. Fielding, H. Nielsen, "Hypertext Transfer

Kikuchi                                                        [Page 16]

Internet DRAFT                                                March 1997

                   Protocol -- HTTP/1.0", RFC 1945, May 1996

           [ASN.1] B. Kaliski, "A Layman's Guide to a Subset of ASN.1, BER,
                     and DER", ftp://ftp.rsa.com (layman.ps), June 1991

           [Mine]  M. Sakurai, et.al., A Design of Certificate or CRL
                   Distribution Architecture between Certification Authorities,
                   The 1997 Symp. on Cryptography and Information Security
                   (SCIS'97), 8D, January 1997

Security Considerations

   This entire memo is about security mechanisms.

Author Addresses:

   Hiroaki Kikuchi
   Dept. of Electrical Engineering
   Tokai University
   1117 Kitakaname, Hiratsuka, Kanagawa 259-12, Japan
   [email-masked]

   Mine Sakurai
   NEC Corporation
   garashi bldg., 2-11-5 Shibaura, Minato-ku, Tokyo 108, Japan
   [email-masked]

   Hiroyuki Hattori
   Meiji University
   1-1-1, Higashi-mita, Tama-ku, Kawasaki, Kanagawa 214, Japan
   [email-masked]

   Yoshiki Sameshima
   Hitachi Software Engineering Co., Ltd.
   6-81 Onoe-cho Naka-ku, Yokohama, Kanagawa 231, Japan
   [email-masked]

Kikuchi                                                        [Page 17]


From: Brian Korver <[email-masked]>
Subject: Re: ASN.1 types for Distinguished names (was: Re: Distinguished n
To: [email-masked] (Andrew Probert)
Date: Wed, 2 Apr 1997 18:24:25 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]

Andrew Probert writes:
> 
> Further to my previous email, here is a comment from Microsoft:
> 
> <snip>
> We have UNICODE X.509 Name ASN.1 encode/decode routines. When converting
> UNICODE to a T61String we convert to UTF8. The UTF8 represents the
> characters 0 .. 0x7f as a single byte, 0x80 .. 0x7ff as two bytes, and
> 0x800 ..0xffff as three bytes. UTF8 is also being used by Java.
> 
> <snip>
> 
> > -----Original Message-----

The addition of BMPString is recent, so it's not too surprising that they
didn't use it, although it is a little strange to me that they didn't
use UniversalString.

brian
[email-masked]

From: Andrew Probert <[email-masked]>
To: "'Brian Korver'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: ASN.1 types for Distinguished names (was: Re: Distinguished n ames and
Date: Thu, 3 Apr 1997 12:13:46 +1000

Further to my previous email, here is a comment from Microsoft:

<snip>
We have UNICODE X.509 Name ASN.1 encode/decode routines. When converting
UNICODE to a T61String we convert to UTF8. The UTF8 represents the
characters 0 .. 0x7f as a single byte, 0x80 .. 0x7ff as two bytes, and
0x800 ..0xffff as three bytes. UTF8 is also being used by Java.

<snip>

> -----Original Message-----
> From:	Brian Korver [SMTP:[email-masked]]
> Sent:	Thursday, April 03, 1997 3:32 AM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: ASN.1 types for Distinguished names (was: Re:
> Distinguished names and
> 
> 
> Holger Reif writes:
> > 
> > Hi,
> > 
> > this seems to be a nice thread to jump in ;-)
> > 
> > I noticed that many of the X.520 Selected attributes are of type
> DirectoryString
> > which in turn is a choice of teletexString, printableString and
> universalString.
> > Does anybody know when which Form is to be used and wether a
> transformation 
> > between these types (if possible) is allowed and gives equal
> meaning. 
> 
> BMPString has basically replaced UniversalString because, I have
> been told, nobody used UniversalString.  I can be believe this.
> 
> Both TeletexString (T61String) and PrintableString have constraints as
> to what can be placed in them.  So for instance if you need to use a
> character such as '@', you cannot use PrintableString.
> 
> I'm unaware of any equality rules to use when comparing strings of 
> unequal type.  I assume that most implementations assume that strings
> of unequal type are by definition not equal.  IMHO this is the best
> approach because of the lack of well-defined equality matching rules.
> 
> I'm also unaware of any rules for "which string do I use" when there
> are multiple string types to choose from.
> 
> 
> > Of course, if it's within a SIGNED context then the answer is clear:
> 
> > one can't change the types. But in other cases?
> 
> brian
> [email-masked]

From: Andrew Probert <[email-masked]>
To: "'Warwick Heath'" <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Distinguished names and X509v3 extension OIDs (fwd)
Date: Thu, 3 Apr 1997 11:56:14 +1000

There's lots of references all over the place to this, but I think there
is some fundamental
cleaving of the use of Certificates occurring in the marketplace into
two factions:

1.  Attribute Certificates, which carry the authorisation / authority /
permissions of the user, but 
    are related to a specific service contract.  SET is an example of
this, where a financial institution
    effectively cares nothing about your 'true' identity, as long as
they can be comfortable about your
    credit worthiness which they check in their own way.

2.  Identity Certificates, which prove you are who you are to a high
level of assurance e.g. equivalent to
    'passport' level issuance.  In this case if you sign anything, there
will be some recourse at law (when
    Governments get legislation into place).

The two are actually orthoganal as regards usage.  The former relates to
authorities to operate on a *service contract*
the latter relates to your *signature* which could be used to sign
anything, or even establish a service contract!

SET cetificates could be considered an attribute certificate because
they carry details of your service contract,
and probably will only stand up in court for that specific purpose.
Likewise a corporation may issue its own 
certificate which ties to employment contract / authorities and
permissions to operate the corporations resources i.e.
a user certificate to the LAN / server system is an attribute
certificiate.

Interestingly, also, is that SET certificates are anonymous i.e. the
true account number is encrypted and only the
Acquirer can decode it and relate it to your account.  

Likewise, I can see a place for anonymous Identity Certificates e.g. you
use them to sign and recourse at law
has to go back via the CA.  It would certainly help with Privacy!

Although it can't be allowed to be a primary key to correlate
information from many sources, this is the fundamental
primary concern of our Government.  For example Tax File Numbers and
Health Care Numbers are strictly protected
by Privacy legislation and we dont have the equivalent of a USA Social
Security number that is available to all.

Use of an Identity Certificate could be proactive i.e. by registering it
against a service contract or alternatively it could 
be remedial i.e. just like a written signature with recourse at law for
fraud.

This opions are totally my own and may be totally misguided, but I would
certainly like to hear opinions on the topic.

> -----Original Message-----
> From:	Warwick Heath [SMTP:[email-masked]]
> Sent:	Wednesday, April 02, 1997 6:38 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	Re: Distinguished names and X509v3 extension OIDs (fwd)
> 
> 
> >
> >I read that to mean that in the absense of a specific profile, *any*
> >attribute (not just any under 2.5.4) is a legal component of a DN
> >according to X.501.
> >
> >That said, it is good practice for a certificate to contain the
> >absolute minimum of information required to accomplish it's purpose,
> >which is to provide a secure binding between a public key and an
> >entity.  If your definition of an "entity" does not include a street
> >address as a fundamental, essential element of it's identity, then
> >the street address should not be included in the DN in a certificate,
> >or for that matter, in an extension.
> 
> OK, then street names etc. are out. I suppose I was looking at the
> certificate containing all the info that I would like to have (seeing
> as the directory itself is not available).
> 
> 
> >> >One person mailed to me the location of a copy of X500v3 online. 
> >> >Another emailed the location of a database of lots of OIDs.
> >
> >Could you forward me, or better, post the location of the OID
> database?
> 
> Andrew Probert <[email-masked]> provided me with the following
> URL
> 
> http://domen.uninett.no/~hta/ietf/oid/top.html
> 
> 
> Thanks to the people who have answered to this thread - the technical
> questions are now clearer, now I just have to wrestle with the
> social/privacy implications of sensitive data in high assurance 
> certificates (i.e. a single cert containing a unique national
> identifier
> verses multiple certs each with application specific identifier). 
> Any references anyone :-)
> 
> Warwick
> 
> /****** PGPfingerprint 88 18 A5 E6 9A B2 C2 24  80 1D BD 84 57 CB 73
> AB ******/
> Warwick Allan Heath, Unix & Comms	RCC IRC d.o.o., Ulica XIV.
> divizije 14,
> Mail: [email-masked]		3000 Celje, SLOVENIJA
> 1Web: http://www.rcc-irc.si/		Tel: +386 63 441 144 x251 Fax:
> 442 036

Date: Wed, 02 Apr 1997 16:55:34 -0500
From: "Hoffman, Mort" <[email-masked]>
Subject: RE: pkix part 1, draft 4:  UTCTime vs GeneralizedTime dates anomaly
To: "[email-masked]'" <[email-masked]>, "'Tim Polk'" <[email-masked]>

Tim,

Reading throught the spec I ran into the following anomaly:  section
4.1.2.5 specifies that dates in the year 2050 should be generated as
UTCTime, and section 4.1.2.5.1 specifies that UTCTime dates encoded with
the year set to 50 shall be interpreted as 2050.  Now, since there were
no CAs existing in the year 1950, then there should not exist any such
dates in certificates at all (OK, this could be argued with on strictly
technical grounds, but I think it is basically true).  Therefore the
anomaly in the spec should not really affect anything, but if someone
writing code to generate certificates read section 4.1.2.5.1 instead of
4.1.2.5, then he would be lead astray.

I imagine all this traces back to the discussion in the X.509 arena on
the dates, but I deleted that mail and I don't know if the anomaly
existed there.  If it didn't then the fix would be to fully align to
what was agreed in X.509.  Otherwise, I guess I'd recommend that a
UTCTime encoded with 50 should be rejected, since it could not have been
legally generated.

Mort 

From: Peter Whittaker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Brian Korver'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: ASN.1 types for Distinguished names (was: Re: Distinguished names and
Date: Wed, 2 Apr 1997 13:14:28 -0500
Encoding: 23 TEXT

>I'm unaware of any equality rules to use when comparing strings of 
>unequal type.  I assume that most implementations assume that strings
>of unequal type are by definition not equal.  IMHO this is the best
>approach because of the lack of well-defined equality matching rules.

My understanding of the DN comparison rules is that one must compare the
actual characters in a string as opposed to the particular datum from a
particular character set.  That is, if I am comparing a distinguished
value that uses PrintableString with a distinguished value that uses
BMPString, I must compare the characters in question one by one, rather
than the bits used to represent them in each of those strings:  I map
each octet from the PrintableString and each pair of octets from the
BMPString to a canonical character table;  if these map to the same
character, I move to the next character in the value to continue my
comparison, and so on, to the end of the strings.  If one string is
shorter - in characters, not octets or bits - than the other or if a
given set of bits maps to different characters, the comparison fails and
the values are different;  otherwise, the values are the same

Or something along those lines.  At least that's my understanding.

pww

From: Brian Korver <[email-masked]>
Subject: Re: ASN.1 types for Distinguished names (was: Re: Distinguished names and
To: [email-masked] (Holger Reif)
Date: Wed, 2 Apr 1997 09:32:05 -0800 (PST)
Cc: [email-masked], [email-masked]

Holger Reif writes:
> 
> Hi,
> 
> this seems to be a nice thread to jump in ;-)
> 
> I noticed that many of the X.520 Selected attributes are of type DirectoryString
> which in turn is a choice of teletexString, printableString and universalString.
> Does anybody know when which Form is to be used and wether a transformation 
> between these types (if possible) is allowed and gives equal meaning. 

BMPString has basically replaced UniversalString because, I have
been told, nobody used UniversalString.  I can be believe this.

Both TeletexString (T61String) and PrintableString have constraints as
to what can be placed in them.  So for instance if you need to use a
character such as '@', you cannot use PrintableString.

I'm unaware of any equality rules to use when comparing strings of 
unequal type.  I assume that most implementations assume that strings
of unequal type are by definition not equal.  IMHO this is the best
approach because of the lack of well-defined equality matching rules.

I'm also unaware of any rules for "which string do I use" when there
are multiple string types to choose from.

> Of course, if it's within a SIGNED context then the answer is clear: 
> one can't change the types. But in other cases?

brian
[email-masked]

To: [email-masked] (David P. Kemp)
cc: [email-masked], [email-masked]
Subject: Re: Distinguished names and X509v3 extension OIDs (fwd) 
Date: Wed, 02 Apr 1997 10:18:53 -0500
From: "Charles W. Gardiner" <[email-masked]>

    Since tagging is implicit in extensions, wouldn't it be possible to have a
BIT STRING with named bits that has a context-specific tag which hides the BIT
STRING tag?  If one didn't know the ASN.1, one wouldn't be able to tell which
bits were named.  This affects the encoding, I believe.  Or a context=specific-
tagged BOOLEAN would also be concealed.

Charlie Gardiner

From: Warwick Heath <[email-masked]>
Subject: Re: Distinguished names and X509v3 extension OIDs (fwd)
To: [email-masked] (David P. Kemp)
Date: Wed, 2 Apr 1997 10:37:55 +0200 (METDST)
Cc: [email-masked], [email-masked]

>
>I read that to mean that in the absense of a specific profile, *any*
>attribute (not just any under 2.5.4) is a legal component of a DN
>according to X.501.
>
>That said, it is good practice for a certificate to contain the
>absolute minimum of information required to accomplish it's purpose,
>which is to provide a secure binding between a public key and an
>entity.  If your definition of an "entity" does not include a street
>address as a fundamental, essential element of it's identity, then
>the street address should not be included in the DN in a certificate,
>or for that matter, in an extension.

OK, then street names etc. are out. I suppose I was looking at the
certificate containing all the info that I would like to have (seeing
as the directory itself is not available).

>> >One person mailed to me the location of a copy of X500v3 online. 
>> >Another emailed the location of a database of lots of OIDs.
>
>Could you forward me, or better, post the location of the OID database?

Andrew Probert <[email-masked]> provided me with the following URL

http://domen.uninett.no/~hta/ietf/oid/top.html

Thanks to the people who have answered to this thread - the technical
questions are now clearer, now I just have to wrestle with the
social/privacy implications of sensitive data in high assurance 
certificates (i.e. a single cert containing a unique national identifier
verses multiple certs each with application specific identifier). 
Any references anyone :-)

Warwick

/****** PGPfingerprint 88 18 A5 E6 9A B2 C2 24  80 1D BD 84 57 CB 73 AB ******/
Warwick Allan Heath, Unix & Comms	RCC IRC d.o.o., Ulica XIV. divizije 14,
Mail: [email-masked]		3000 Celje, SLOVENIJA
Web: http://www.rcc-irc.si/		Tel: +386 63 441 144 x251 Fax: 442 036

Date: Wed, 2 Apr 97 08:11:12 +0200
From: [email-masked] (Holger Reif)
To: [email-masked], [email-masked]
Subject: ASN.1 types for Distinguished names (was: Re: Distinguished names and  X509v3 extension OIDs (fwd))

Hi,

this seems to be a nice thread to jump in ;-)

I noticed that many of the X.520 Selected attributes are of type DirectoryString
which in turn is a choice of teletexString, printableString and universalString.
Does anybody know when which Form is to be used and wether a transformation 
between these types (if possible) is allowed and gives equal meaning. 

Of course, if it's within a SIGNED context then the answer is clear: 
one can't change the types. But in other cases?

read you later  -  Holger Reif
----------------------------------------  Signaturprojekt Deutsche Einheit
TU Ilmenau - Informatik - Telematik                      (Verdamp lang her)
[email-masked]         Alt wie ein Baum werden, um ueber
http://Remus.PrakInf.TU-Ilmenau.DE/Reif/  alle 7 Bruecken gehen zu koennen

From: Carlisle Adams <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: PKIX Part 3...
Date: Tue, 1 Apr 1997 12:33:01 -0500
Encoding: 43 TEXT

Hi,

Well it turns out that with IETF's new automated process, missing the
submission deadline by half an hour was significant.  Maybe next time I
won't lose half a day from computer troubles at a critical time...   Ha.

In any case, there is a revised version of PKIX-3 and I have posted it
on our website so that people have access to it prior to Memphis.  It
can be found at  http://www.entrust.com/library.htm  (just keep
scrolling down until you get to the PKIX section).

On the list, the main topics debated were:

   - PKCS #10 versus the original certification request message;
   - PKCS #7 (or any other external mechanism) versus the original
message protection scheme;
   - POP of private key being optional or mandatory.

Other issues that came up (either publicly or privately) included making
POP for decryption keys an extended exchange (i.e., longer than 3
messages) in order to accommodate the presence of an RA, and
generalizing the information request/response messages to accommodate
future needs/extensions.

I would strongly encourage all who were involved in those debates (and
all who were interested observers) to take a look (especially at pages
10-11, 17-18, 25-27, 31, 44, 46-47, 53-55) in preparation for Memphis.
Is the new draft something we can all live with?  My hope is that this
draft will satisfy enough people to generate the obligatory "rough
consensus" on these issues so that we can progress to other things
(i.e., any other issues, or Last Call).

Let me know if you have any trouble downloading the document; I would be
happy to e-mail copies if necessary.

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

>

Date: Tue, 1 Apr 1997 10:32:02 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Distinguished names and X509v3 extension OIDs (fwd)

> From: Ben Laurie <[email-masked]>
> 
> David P. Kemp wrote:
> > If anyone has a counterexample - a BER transfer string that cannot
> > be converted to DER without knowledge of the ASN.1 definition, I'd
> > like to see it.
> 
> >From memory, if a field has its default value, in DER it must be omitted, but
> in BER it is optional. I could be completely wrong, though.

Touche'.   I was considering definite/indefinite length encoding, but
failed to consider DEFAULT.  There are probably other reasons to need
the ASN.1 as well.

(Reference for DEFAULT encoding: X.690 sections 8.11.3 and 11.5)

It's a shame that the entire signed portion of a certificate can't be
treated as an opaque blob in transit, instead of each individual extnValue.

Subject: Re: Distinguished names and X509v3 extension OIDs (fwd)
To: "David P. Kemp" <[email-masked]>
Date: Tue, 1 Apr 1997 14:19:37 +0000 (GMT)
From: Ben Laurie <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Content-Length: 647       

David P. Kemp wrote:
> If anyone has a counterexample - a BER transfer string that cannot
> be converted to DER without knowledge of the ASN.1 definition, I'd
> like to see it.

>From memory, if a field has its default value, in DER it must be omitted, but
in BER it is optional. I could be completely wrong, though.

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: [email-masked]
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Date: Tue, 1 Apr 1997 09:12:42 -0500
From: [email-masked] (David P. Kemp)
To: [email-masked]
Subject: Re: Distinguished names and X509v3 extension OIDs (fwd)
Cc: [email-masked]

> From [email-masked] Mon Mar 31 16:45:05 1997
>
> We certainly looked first at the more obvious options such as ANY DEFINED
> BY and EXTERNAL but were forced to reject them.  I think what you are
> saying you would prefer is essentially the ANY DEFINED BY option, i.e., (in
> shorthand) SEQUENCE { oid, boolean, ANY DEFINED BY oid }.

Yes.

> 
> >From recollection, the problem with the ANY DEFINED BY approach is as
> follows.  Recall that a certificate is not necessarily transmitted
> everywhere encoded in DER.  Some certificate-carrying protocols use
> BER-encoding.  This is why a cert using system may need to regenerate the
> DER encoding of the cert when verifying the signature.  Recall also that
> intermediate systems through which a cert traverses may decode and recode
> certs differently (e.g., if BER is in use, a system may re-encode a cert
> with a different BER encoding than that in which it was received).  In the
> case of an extension, such a change of encoding might occur in any system
> that recognizes the extension OID and the corresponding ASN.1 type for the
> extension value.
> 
> Now, when it comes to validating a cert, note that certs that contain
> unrecognized extensions may still be perfectly valid and usable (provided
> every unrecognized extension is flagged noncritical).  But, if it is
> possible for the bit-representation of an unrecognized extension to have
> changed in transit, how can the cert-using system generate the required
> canonical encoding to verify the cert's signature?
> 
> The level of indirection gained through the OCTET STRING overcomes this
> problem.  Intermediate systems are not permitted to change the encoding of
> an extension at the inner level, since it is mandated to always be DER.
> And changing the encoding of the octet string itself is not a problem as
> you can always regenerate the DER encoding of an OCTET STRING.
> 
> Hope this helps,
> Warwick (Ford)

Warwick,
  Thanks for the cogent explanation - it helps to understand the rationale.
I'll have to think some more about the conclusion though.

I believe that it is always possible for BER/CER/DER software, having
no knowledge of specific extensions, or even of the X.509 certificate
structure itself, to take an arbitrarily-coded BER structure and recode
it in DER.  It certainly seems to be true for the elements commonly
found in certificates (UNIVERSAL and CONTEXT elements).  It should also
be true for APPLICATION and PRIVATE elements, because the DER
restriction rules are not specified for them: if an APPLICATION element
has two different BER encodings (not counting differences in UNIVERSAL
subelements) then it also has two different DER encodings, therefore
that particular APPLICATION element cannot be used in the signed
portion of a certificate.

If anyone has a counterexample - a BER transfer string that cannot
be converted to DER without knowledge of the ASN.1 definition, I'd
like to see it.

Thanks,

   Dave Kemp