From owner-ietf-pkix Tue Jan 2 02:46:23 2001 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA08556 for ; Tue, 2 Jan 2001 02:46:21 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA21862; Tue, 2 Jan 2001 11:57:25 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA19920; Tue, 2 Jan 2001 11:50:01 +0100 Message-ID: <3A51B25D.A449FC37@bull.net> Date: Tue, 02 Jan 2001 11:50:05 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Stephen Kent CC: PKIX-List Subject: Re: DPD & DPV requirements References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> <004401c06739$f7b9f550$0201a8c0@vincent.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id CAA08558 Steve, First of all, many thanks for posting this long document. I will not respond using directly your text, since my arguments are fairly different. I will however re-use some of your arguments. Let us use the concept of "validation policy", that you introduce, which is all the set of rules to be followed when validating a certificate. It will usually not simply be the rules mentioned in RFC 2459, but these rules with additional conditions. Note that in the context of electronic signatures, a "signature policy" is a specific example of a "validation policy". DPV === Let us start with DPV first. A DPV client will not necessarily be either PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol: 1) one not using ASN.1 (e.g. using XML), 2) one using ASN.1. In both cases the client only supplies an unambiguous reference of the certificate (CA name, serial number and a hash of the certificate) or the certificate itself and specifies the rules to be followed to validate the certificate: an identification of a pre-defined "validation policy" (e.g. an OID and/or a URL to find the policy and a hash of that validation policy). As a result, the client expects a signed response which reproduces the requested parameters and includes a status. The status is not simply: "passed validation", "failed validation", or "don't' know" but can also be "incomplete validation", meaning that some revocation status information is not yet available at the time of processing and a later attempt might succeed. The response must include the time at which the validation has been performed. Allowing to test a certificate "in the past", would place some requirements that cannot always be accomplished by a standard PKI: currently we do not mandate CAs to maintain revocation information beyond the end of the validity period of a certificate. We should not change that rule. So I am very reluctant to autorise validation in the past, e.g. 10 years later. If a client is interested in a later proof, then it should obtain that information from the server at the time the information is still available. This means that a client should have the possibility to ask the server to optionally return an opaque blob that contains all what has been used to validate the certificate (i.e. a certification path and all the CRLs or OCSPs needed for each certificate from the path). A question arises from the requirements 1.5 and 1.6 that you listed: should that opaque blob be time-stamped ? If there is a fear that some of the issuing keys used in the certification path might later on be compromised, then this can be useful. This case should be very seldom and hence this service would not always be required. In addition, why should that service be embedded in this protocol ? This could be obtained using directly the TSP, leaving more possibilities: free choice of the TSAs, time stamp of the full blob, time stamp of the certification chain only, time stamp on both the certification chain and the revocation information. Thus I do not favor to piggy-back the two services. In order to simplify the protocol and allow for PKI-ignorant clients, the client should NOT be allowed to provide any other element than the certificate, that might help to construct the path or the revocation information. This means that, not only I do not agree with a common list of requirements for both DPV and DPD, but also that I do not agree with many of the requirements that you listed: For a DPV client: 1.1. Only a single certificate should be allowed. 1.2. No revocation items should be allowed. 1.3. No request in the past should be allowed. 1.4. Imposing constraints for CRLs or OCSP responses should be hidden under the "validation policy" that is selected. 1.5. and 1.6. Time stamped responses, if needed, should not be part of the service. 1.7. Validation policies are not necessarily "configured at the server", but can simply be pre-defined, outside the server. I any case, the rules that has been followed - i.e. "validation policy" - must be indicated in the response. 1.8. For DPV, responses must be signed. 1.9. The policy ID format can/will be specified in the protocol. For a DPV server: 2.1. A DPV server, will have to do more than RFC 2459, hence why the use of a validation policy is needed. 2.2. An opaque blob MAY be returned. 2.3. Time stamping is not needed. 2.4. The concept of policy overriding is too complex: a reference to a validation policy is sufficient. 2.5. No comment. 2.6. A server must support LDAP for certificate fetching, and EITHER CRL fetching OR OSCP (OCSP should not be mandatory). 2.7. No comment. DPD === Let us continue with DPD. I agree in general with many of the requirements that you listed in that case. In particular, since a DPD client must be both PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1. The major difference with the previous protocol is that no evaluation of the returned chain needs to be done, since the client is supposed to be able to perform all the checks himself. Therefor no validation status is returned by the server. The service is more a single place for shopping all (?) the needed certificates and revocation status information. In the request, the client could either specify a validation policy or the trusted points with, for each level of the chain, the indication whether CRLs or OCSP responses are requested. One or more chains, corresponding to the request may be obtained. The response does not need to be signed, but only protected by a combined integrity and data origin authentication service. CONCLUSION ========== We could support three protocols: 1° DPV in XML, 2° DPV in ASN.1, 3° DPD in ASN.1. ADDITIONAL QUESTION =================== For the two protocols in ASN.1, should these two protocols be piggy-back on OCSP ? Before going at the technical details, it is important to raise the following question: which combination(s) of the three basic requests (OCSP, DPV and DPD) could make sense ? If a client requests DPV, then it does not care about OCSP and neither on DPD (multiple certification chains to be tested). For a PKI-aware client, only OCSP + DPD makes sense. This means that : 1) DPV does not need to be supported by OCSP. 2) The only protocol to be piggy-backed to OCSP would be DPD. Denis > As promised, here is the strawman requirements specification for DPV and DPD. Questions that the WG needs to address as part of deciding on the scope of these requirements are in boldface. > > Happy Holidays, > > Steve > -------- > > The WG has already decided to purse standardization of a protocol (or protocols) for delegated path discovery (DPD) and delegated path validation (DPV). This memo revisits and expands on the rationale for offering these services, notes the overlap in server functionality required for each, and proposes requirements for candidate protocols that will be considered for standardization by PKIX. The goal of the memo is to provide a strawman set of requirements and evaluation criteria that will be used to select PKIX standards. > > A DPD or a DPV server may operate in either a public or private context. In the former case, clients are assumed to be from a broad community with no common organizational affiliation and the service may be offered for a fee. In the latter case, the service may be offered to a closed community under a common organizational structure, where there is an expectation that the server falls under the same administrative control as the clients and no explicit fee may be involved. Intermediate or hybrid models also may exist, but are not specifically identified here nor required as part of proposed solutions. > > DPD allows a client to offload the communications and processing associated with retrieval of certificates and CRLs (or OCSP responses) to create a certification path terminating in a target certificate. The client supplies this target certificate, or it may supply a partial path, or a complete path (the latter two may have been acquired as part of a protocol exchange). In the last case, the DPD server assists the client by acquiring relevant revocation status information. The client might also supply some revocation status data, to aid the path discovery process, just as it may provide a partial or complete certification path. This might make sense if this revocation status data was supplied to the client as part of a protocol exchange, e.g., IKE and S/MIME make provisions for send such data. > > The client may be bandwidth constrained and thus would benefit from having a server interact with repositories and other servers to acquire the requisite certification path and/or revocation status data. The client may be storage constrained, and thus can benefit from a server that caches certificates, CRLs and OCSP responses. Because multiple protocols may have to be employed in communicating with various servers (e.g., OCSP, LDAP, etc.) in performing path discovery, the size and complexity of client code may be reduced by reliance on a DPD server. Because the server can have more storage, a faster processor, and higher speed communications paths to these servers, the client may gain a performance advantage by delegating the task of path discovery. > > DPV offloads all aspects of path validation to a server, which returns to the client, at a minimum, an indication of status of the target certificate. This status may be relative to the current time, or it might be a request to verify status at some previous time, e.g., as an aid to checking non-repudiation evidence. As above, the client may provide a partial or complete candidate path for validation, or may provide just the target certificate, and the client may provide some or all of the associated revocation status data. Also, the parameters for path validation must be provided, either explicitly in the request or via server configuration. As well as the benefits noted above (reduced bandwidth, storage and processing requirements and reduced client code size and complexity), DPV allows an administrator to centrally manage (via server configuration) some or all of the path validation parameters. Similar controls on path discovery could be present in a DPD server. Central > management controls are viewed as especially attractive in closed, organizational environments as they mitigate configuration management problems for individual clients. For a public DPV service this is not an issue because there is no single, central authority responsible for configuration management of all clients. > > A DPD client is assumed capable of performing path validation on the returned certificate chain(s), which implies that the client embodies validation software consistent with RFC 2459 (which is non-trivial in size and complexity) and thus is capable of parsing certificates, CRLs, and OCSP responses. Such a client may be termed "PKI-aware," i.e., it can parse ASN.1, verify digital signatures, perform path validation, and is cognizant of validation parameters. Thus, no apparent, significant benefit accrues from using a syntax other than ASN.1 for DPD queries and responses. > > Because a DPD client is PKI-aware, it is capable of specifying the validation parameters used by a DPD server in constructing a candidate path. The goal of DPD is to return one or more chains that will be acceptable to the client, so it is important that the client be able to specify, e.g., via a DPD request, the set of validation processing parameters that it will use for local validation. Only by making the DPD server aware of these parameters can the server return a path (and supporting revocation status data) that will have a very high likelihood of being acceptable to the client. It may be desirable, especially in a closed environment, to assert centralized control over the validation processing parameters used by the server, even though such control is less stringent than that imposed in a DPV context. This suggests there should be provisions for configuring validation processing parameters into the server, and for allowing a client to select from among several possible > parameter sets. See the discussion immediately below for a further examination of this issue. > > DPV also requires a means to control the validation parameters defined in RFC 2459. If we assume that a DPV protocol will operate in both open and closed environments, and if we wish to accommodate PKI-aware clients, then there must be a means for a client to specify all of these parameters, or to specify a subset of them. The former requirement arises in the simplest, open server contexts; the latter may arise in such contexts if there is some other way to signal a default set of parameters for validation control, e.g., via reference to one of several validation policies configured in a server, as a basis for these parameter values. In a closed environment, it is still important that a client be able to specify validation parameters, e.g., as a means of selecting from among a set of parameters allowed by administrative controls managed at the server. For example, a server in an organizational environment may have a configured set of trust points, but a client may be permitted to > select from a subset of these when requesting validation for a specific certificate. Such flexibility is needed because the validation parameters are a function of several variables that are context specific. > > It seems reasonable to require a DPV or DPD client to be able to control validation via two means: specification of a validation policy configured at a server, or via client-specified parameters. These means are not mutually exclusive, and a server should support combinations of them, e.g., client-specified parameters constrained by reference to a server-configured validation policy. We need to refine the semantics here, e.g., can the server be configured with path validation parameters that CANNOT be overridden by a client, and if so, does the server have to inform the client when its explicitly-specified parameters were ignored, as part of response, or does the server just reject the request, note the offending parameters, and let the client try again? > > It is tempting to suggest support for multiple policies specified in a request, but I'm not sure how one would make use of this. For example, is the server required to try to construct paths based on each of the policies, in succession, and to return all successful results, or is the server free to choose any one of the policies? Does the order in which the policies are specified indicative of preference? To keep life simple, for now, I suggest that we allow specifying only one policy in a request, but I am open to suggestions. > > At a minimum, the parameters for server-configured policies must be those specified by the certificate path validation algorithm in RFC 2459. It is tempting to suggest that a vendor may elect to augment this set and provide a means by which a client can specify additional controls. The motivation here is that, over time, we may identify additional controls to provide "fuzzier" evaluation. For example, a client might be willing to accept a certificate if the server asserts that although the current CRL for the target certificate is not available, the certificate is not on the most recent CRL available to the server at the time of the request. This area is quite complex and does not yet appear suitable for standardization. The WG must decide if we wish to require (or discourage) such extensibility. Note that extensibility usually leads to added complexity, and possible non-interoperabilty, e.g., if private extensions are supported. Personally, I would recommend against such extensions > at this time. > > It has been suggested that a DPV server also should be capable of returning time-stamped certification path(s) and revocation data, for later use as evidence in a non-repudiation dispute. If so, then the data returned by a DPV server is potentially quite close to that provided by a DPD server. One could argue that a DPD server could provide an option for return of time-stamped path and revocation status data, also in support of non-repudiation, for the same reasons, which would make the responses for both types of servers even more similar. > > It is important to ask to what extent should we assume that a DPV client is PKI aware? At one extreme one can imagine that the client is PKI-aware and that it should be able to specify all of the path validation parameters required in 2459. For such a client, returning a certificate and an indication of its validity seems appropriate. Alternatively, a DPV client may not be PKI-aware, but may still be ASN.1-capable. The client could parse a certificate returned to it, but it does not implement nor understand path validation. For such a client, it seems appropriate to control path validation only via reference to a policy, not by specifying individual path validation parameters. In the extreme case, a DPV client may not even be ASN.1-capable. > > For a non-PKI aware, non-ASN.1-capable client, the results returned by the DPV protocol should not be merely a certificate and a status indication. Rather, the contents of a certificate that are relevant to the client application should be returned as distinct values, in a syntax appropriate for the client. For example, the public key and associated algorithm, the subject name (and/or alternate names) and the issuer name (and alternate names), the key usage bits, and the extended key usage field are all candidate values to be returned as distinct objects to the client. An argument could be made for using XML to represent some of these values, and to represent the syntax of the protocol messages. But, some of the certificate contents, specifically the issuer name and subject name, are intrinsically ASN.1 objects themselves, so these values would have to be decoded even further for use by a non-ASN.1-aware client. (There are scenarios that motivate return of ASN.1-encoded data, e.g., > certification paths and revocation data, as an opaque blob, e.g., for later use in a non-repudiation dispute. But this does not imply that the client is ASN.1-aware.) > > If we wish to support DPV clients that are not ASN.1-capable, the WG is faced with a question; Shall we mandate support for another syntax in addition to (or in lieu of) ASN.1, for a DPV protocol? This question must be resolved soon, as it becomes an important input to DPV protocol requirements. In informal discussions at the IETF meeting, some folks suggested that the scope of issues associated with supporting non-ASN.1-capable clients (in the DPV context) is potentially very broad and that we should defer such support for now. But, the WG needs to weigh in on this question. > > Finally, this analysis suggests that there are relatively few differences between a DPD and a DPV server. Both must be capable of constructing and returning certification paths and supporting revocation data, under the control of parameters that are either explicitly specified by a client or referenced via a server-configured policy. Both accept a range of inputs in the form of certificates or certificate chains, and revocation data "hints." Thus, the WG must decide if two distinct protocol formats, with different syntax are warranted, of if a single (slightly more complex) format for requests and responses is appropriate. > > Based on the preceding analysis, I propose the following requirements for DPD and DVP protocols, based on the assumption of ASN.1 aware clients. Remember that the protocol specs will encompass not only the syntax of the bits on the wire, but also the processing that will be performed by clients and servers. > > Unless otherwise qualified, he following requirements are proposed for both DPD and DPV protocols: > > Client requirements: > > 1.1 A client request can contain a single certificate or a certificate chain terminating in the "target" certificate, to assist the server in path construction. > > 1.2 A client request can contain one or more revocation data items, to assist the server in path validation. > > 1.3 A client request to a DPV server can specify the time relative to which the validation is to be performed. If omitted, the current time is assumed. > > 1.4 A DPD client request must be able to specify whether only CRLs, only OCSP responses, or either, are acceptable forms of revocation status data to be returned. (We could apply this requirement to DPV requests as well, if the content of returned, substantiating evidence for non-repudiation needs to be similarly constrained.) [Shall we also allow the request to also impose constraints on the forms of OCSP responses that are acceptable, by type, and if the basic type is specified shall we require an ability to specify a time before which a pre-produced OCSP response is considered too old?] > > 1.5 A DPV client request must be able to specify whether a certification path and revocation status data, plus a TSP response (for each returned certification path and revocation data set) should be returned by a server, in support of non-repudiation. > > 1.6 A DPD client request must be able to specify whether a TSP response should be returned by a server (for each returned certification path and revocation data set), in support of non-repudiation. > > 1.7 A client request must be able to specify validation processing parameter values both via reference to policies configured at a server and via specification of values for individual parameters. If no policy is specified and no parameters are specified, a default parameter value set, configured at the server, will be employed. If a policy is specified but no parameter values are specified by the client, then the parameter values associated with that policy are employed. If only client-supplied parameter values are present in the request, then they are employed. Any parameters not specified by the client will be supplied by the default set configured in the server. Also, if any of these default parameters are marked as not capable of being overridden by user-specified parameter values, then the default parameter values shall be employed. If a policy is specified and there are client-supplied parameter values, the policy is employed to select parameter values, and then the > user-supplied parameter values are applied, overriding the policy-specified parameter values, except for any policy-specified parameters that are marked as not subject to user override. [whew!] > > 1.8 Either the request/response protocol itself, or a specified lower layer protocol to be employed for requests and responses, there must be a provision for data origin authentication and connectionless integrity for requests and responses, and responses must be matched to requests. Request authentication & integrity is needed to support access control to the server, a requirement for public servers. Responses must be authenticated and integrity-protected to ensure that they are from the indicated server, and matched to the request in question. Additional security services may be offered optionally. > > 1.9 The client must be able to query a server and request path validation policy parameter values for any policy configured on the server. The client must be able to specify policies by an ID (e.g., an OID) or to refer to the default policy. [A standard will have to specify the policy ID format.] > > Server Requirements: > > 2.1 A server must be able to process client requests invoking any of the features defined above for clients. Thus it must implement RFC 2459-compliant certificate validation procedures in support of both DPD and DPV. The path discovery process implemented by a DPD server operates under the same set of controls as path validation, and thus a DPD server returns paths only if they are valid with respect to the specified path validation parameter values. > > 2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation. Each set shall consist of an ordered list of certificates and associated CRLs and/or OCSP responses. > > 2.3 A server must be capable of returning a time stamp response (consistent with the TSP RFC that will soon be issued) covering each returned certification path and revocation data set. (See 1.4 & 1.5 above) > > 2.4 A server must be configurable to support multiple sets of path validation parameters, each identified by a policy identifier. One such set, which must include values for all validation parameters, must be designated as the default policy. Each parameter in any policy must be capable of being marked as not subject to override by corresponding, client-specified parameters. (It is TBD whether the default policy supercedes other configured policies if there are conflicts in parameters that are marked as not being subject to override.) > > 2.5 The means by which validation policy parameter values are configured will not be part of the standard. > > 2.6 A server must be able to access both LDAP servers and OCSP servers in support of path discovery and revocation data acquisition. > > 2.7 A server must be able to respond to a request from a client for the path validation policy parameters for the default policy, or for any identified policy. However, a server may impose access controls with regard to such requests so that it may reject a query if the client is not authorized to invoke the path validation policy in question. > ------------------------------------------------------------------------------------------------------------------ > > My examination of both SCVP and the proposed OCSPv2 extensions suggests that neither meet the strawman requirements I set forth above. Of course, the WG also has to review these requirements and determine if there is consensus on them, or if they need to be modified (pruned or extended). The time table in my pre-Christmas message says that we have the next moth to reach closure on this. > > Finally, one criteria for selecting a standard which seems important to many WG participants is the complexity of the client and server implementations. Arguments about simplicity based on extending an existing protocol are not objective in the absence of substantiating data. Thus, to create a level playing field, all proposed protocols must be accompanied by algorithmic descriptions of the processing by both client and server. Remember that a protocol is not just the syntax of the bits on the wire, but also encompasses the processing and semantics associated with the protocol. I have tried to allude to aspects of such processing in the requirements above, but more work remains. IETF standards have often failed to do a good job in this regard. Our recent experience with varying interpretations of OCSP (v1) responses demonstrate the importance of such specification. The level of detail required here is open for discussion, but it must be sufficient to allow WG members to create > independent, interoperable implementations, and to allow prospective evaluation of the relative complexity of each candidate. From owner-ietf-pkix Tue Jan 2 03:20:51 2001 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA13547 for ; Tue, 2 Jan 2001 03:20:51 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA30054 for ; Tue, 2 Jan 2001 12:31:58 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA20058 for ; Tue, 2 Jan 2001 12:24:39 +0100 Message-ID: <3A51BA7B.B24ACE62@bull.net> Date: Tue, 02 Jan 2001 12:24:43 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: IETF-PXIX Subject: Two questions on delta-CRL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: The delta CRL indicator is a critical CRL extension that identifies a delta-CRL. The use of delta-CRLs can significantly improve processing time for applications which store revocation information in a format other than the CRL structure. This allows changes to be added to the local database while ignoring unchanged information that is already in the local database. When a delta-CRL is issued, the CAs MUST also issue a complete CRL. (...) Again, a delta-CRL MUST NOT be issued without a corresponding complete CRL. The two questions are the following: 1) What is the rational for mandating the issuance of a complete CRL each time a delta-CRL is issued ? 2) Under which conditions could this requirement be relaxed ? Denis From owner-ietf-pkix Tue Jan 2 06:12:41 2001 Received: from smtpproxy1.mitre.org (mb-20-100.mitre.org [129.83.20.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25302 for ; Tue, 2 Jan 2001 06:12:39 -0800 (PST) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id JAA24507; Tue, 2 Jan 2001 09:15:38 -0500 (EST) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id JAA12445; Tue, 2 Jan 2001 09:15:37 -0500 (EST) Received: from schaen-pc.mitre.org (128.29.162.49) by mailhub1.mitre.org with SMTP id 5216119; Tue, 02 Jan 2001 09:14:43 -0500 Message-ID: <3A51E2CF.85A784F4@mitre.org> Date: Tue, 02 Jan 2001 09:16:47 -0500 From: Sam Schaen Organization: The MITRE Corporation X-Mailer: Mozilla 4.75 [en]C-20000818M (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Denis Pinkas CC: IETF-PXIX Subject: Re: Two questions on delta-CRL References: <3A51BA7B.B24ACE62@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I believe the requirement for issuing a complete CRL when a delta CRL is released makes sense. It permits applications that don't understand delta CRLs to obtain the most recent information. Overall network bandwidth usage is still reduced to the extent that other delta-CRL-capable applications do make use of the delta CRL rather than retrieving a full CRL. The availability of a current full CRL also allows an application to resynchronize at any point. Denis Pinkas wrote: > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: > > The delta CRL indicator is a critical CRL extension that identifies a > delta-CRL. The use of delta-CRLs can significantly improve > processing time for applications which store revocation information > in a format other than the CRL structure. This allows changes to be > added to the local database while ignoring unchanged information that > is already in the local database. > > When a delta-CRL is issued, the CAs MUST also issue a complete CRL. > > (...) Again, a delta-CRL MUST NOT be issued without a corresponding > complete CRL. > > The two questions are the following: > > 1) What is the rational for mandating the issuance of a complete CRL each > time a delta-CRL is issued ? > 2) Under which conditions could this requirement be relaxed ? > > Denis From owner-ietf-pkix Tue Jan 2 06:32:41 2001 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA25920 for ; Tue, 2 Jan 2001 06:32:40 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA43056; Tue, 2 Jan 2001 15:43:47 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA16934; Tue, 2 Jan 2001 15:36:28 +0100 Message-ID: <3A51E76F.AEFCE2EC@bull.net> Date: Tue, 02 Jan 2001 15:36:31 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Sam Schaen CC: IETF-PXIX Subject: Re: Two questions on delta-CRL References: <3A51BA7B.B24ACE62@bull.net> <3A51E2CF.85A784F4@mitre.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sam, Thanks for attempting to answer the question. One possible answer would be to prevent people using delta-CRLs to get an advantage over people using regular CRLs. The text used to write RFC 2459 was written at a time where OCSP servers did not existed. However, clients now using OCSP servers may get such an advantage, i.e. fresher information about revocation status. Would the following scenario (currently forbidden by RFC 2459) makes sense ? The full CRL is issued every day, and a delta CRL is issued every hour. I was wondering whether it would be possible to relax this rule, and thus have e.g.: When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL. However, before doing so, we must understand the original rational and all the implications. To understand the original rational I would expect a response from one of the authors of RFC 2459. However, for the second part of the question (i.e. all the implications) the discussion is open. Denis > I believe the requirement for issuing a complete CRL when a delta CRL is > released makes sense. It permits applications that don't understand delta > CRLs to obtain the most recent information. Overall network bandwidth usage > is still reduced to the extent that other delta-CRL-capable applications do > make use of the delta CRL rather than retrieving a full CRL. The > availability of a current full CRL also allows an application to > resynchronize at any point. > > Denis Pinkas wrote: > > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: > > > > The delta CRL indicator is a critical CRL extension that identifies a > > delta-CRL. The use of delta-CRLs can significantly improve > > processing time for applications which store revocation information > > in a format other than the CRL structure. This allows changes to be > > added to the local database while ignoring unchanged information that > > is already in the local database. > > > > When a delta-CRL is issued, the CAs MUST also issue a complete CRL. > > > > (...) Again, a delta-CRL MUST NOT be issued without a corresponding > > complete CRL. > > > > The two questions are the following: > > > > 1) What is the rational for mandating the issuance of a complete CRL each > > time a delta-CRL is issued ? > > 2) Under which conditions could this requirement be relaxed ? > > > > Denis From owner-ietf-pkix Tue Jan 2 08:31:55 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA07595 for ; Tue, 2 Jan 2001 08:31:55 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jan 2001 08:35:47 -0800 (Pacific Standard Time) Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 2 Jan 2001 08:35:34 -0800 Message-ID: <24A715275661C8428C00432EFCA5CB7C01094F4A@red-msg-02.redmond.corp.microsoft.com> From: David Cross To: "'Denis Pinkas'" , Sam Schaen Cc: IETF-PXIX Subject: RE: Two questions on delta-CRL Date: Tue, 2 Jan 2001 08:35:37 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) I think the important distinction is to ensure that a valid base CRL always exists. A client 1) may not understand a dCRL or 2) a client may not already have the base CRL that the dCRL is derived from. The way I read the RFC is that a valid base CRL must exist when the dCRL is published. This does not necessarily mean that the base CRL must be re-published every time a dCRL is published. If a base CRL is re-published at the same interval as the dCRL, the value of dCRLs diminishes as the cost and latency of base CRL publication is much higher for the network. David B. Cross -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Tuesday, January 02, 2001 6:37 AM To: Sam Schaen Cc: IETF-PXIX Subject: Re: Two questions on delta-CRL Sam, Thanks for attempting to answer the question. One possible answer would be to prevent people using delta-CRLs to get an advantage over people using regular CRLs. The text used to write RFC 2459 was written at a time where OCSP servers did not existed. However, clients now using OCSP servers may get such an advantage, i.e. fresher information about revocation status. Would the following scenario (currently forbidden by RFC 2459) makes sense ? The full CRL is issued every day, and a delta CRL is issued every hour. I was wondering whether it would be possible to relax this rule, and thus have e.g.: When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL. However, before doing so, we must understand the original rational and all the implications. To understand the original rational I would expect a response from one of the authors of RFC 2459. However, for the second part of the question (i.e. all the implications) the discussion is open. Denis > I believe the requirement for issuing a complete CRL when a delta CRL is > released makes sense. It permits applications that don't understand delta > CRLs to obtain the most recent information. Overall network bandwidth usage > is still reduced to the extent that other delta-CRL-capable applications do > make use of the delta CRL rather than retrieving a full CRL. The > availability of a current full CRL also allows an application to > resynchronize at any point. > > Denis Pinkas wrote: > > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: > > > > The delta CRL indicator is a critical CRL extension that identifies a > > delta-CRL. The use of delta-CRLs can significantly improve > > processing time for applications which store revocation information > > in a format other than the CRL structure. This allows changes to be > > added to the local database while ignoring unchanged information that > > is already in the local database. > > > > When a delta-CRL is issued, the CAs MUST also issue a complete CRL. > > > > (...) Again, a delta-CRL MUST NOT be issued without a corresponding > > complete CRL. > > > > The two questions are the following: > > > > 1) What is the rational for mandating the issuance of a complete CRL each > > time a delta-CRL is issued ? > > 2) Under which conditions could this requirement be relaxed ? > > > > Denis From owner-ietf-pkix Tue Jan 2 09:02:50 2001 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09343 for ; Tue, 2 Jan 2001 09:02:49 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA43712; Tue, 2 Jan 2001 18:13:57 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA18212; Tue, 2 Jan 2001 18:06:39 +0100 Message-ID: <3A520A9F.64BDA226@bull.net> Date: Tue, 02 Jan 2001 18:06:39 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: David Cross CC: IETF-PXIX Subject: Re: Two questions on delta-CRL References: <24A715275661C8428C00432EFCA5CB7C01094F4A@red-msg-02.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David, Thanks for paying interest to this topic. > I think the important distinction is to ensure that a valid base CRL always > exists. A client 1) may not understand a dCRL or 2) a client may not > already have the base CRL that the dCRL is derived from. > > The way I read the RFC is that a valid base CRL must exist when the dCRL is > published. This does not necessarily mean that the base CRL must be > re-published every time a dCRL is published. I have difficulties to understand your last sentence, since the text says: "When a delta-CRL is issued, the CAs MUST also issue a complete CRL". > If a base CRL is re-published at the same interval as the dCRL, the value of > dCRLs diminishes Agreed. > as the cost and latency of base CRL publication is much > higher for the network. Denis > David B. Cross > > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Tuesday, January 02, 2001 6:37 AM > To: Sam Schaen > Cc: IETF-PXIX > Subject: Re: Two questions on delta-CRL > > Sam, > > Thanks for attempting to answer the question. One possible answer would be > to prevent people using delta-CRLs to get an advantage over people using > regular CRLs. The text used to write RFC 2459 was written at a time where > OCSP servers did not existed. However, clients now using OCSP servers may > get such an advantage, i.e. fresher information about revocation status. > > Would the following scenario (currently forbidden by RFC 2459) makes sense ? > > The full CRL is issued every day, and a delta CRL is issued every hour. > > I was wondering whether it would be possible to relax this rule, and thus > have e.g.: > > When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL. > > However, before doing so, we must understand the original rational and all > the implications. To understand the original rational I would expect a > response from one of the authors of RFC 2459. However, for the second part > of the question (i.e. all the implications) the discussion is open. > > Denis > > > > I believe the requirement for issuing a complete CRL when a delta CRL is > > released makes sense. It permits applications that don't understand delta > > CRLs to obtain the most recent information. Overall network bandwidth > usage > > is still reduced to the extent that other delta-CRL-capable applications > do > > make use of the delta CRL rather than retrieving a full CRL. The > > availability of a current full CRL also allows an application to > > resynchronize at any point. > > > > Denis Pinkas wrote: > > > > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: > > > > > > The delta CRL indicator is a critical CRL extension that identifies a > > > delta-CRL. The use of delta-CRLs can significantly improve > > > processing time for applications which store revocation information > > > in a format other than the CRL structure. This allows changes to be > > > added to the local database while ignoring unchanged information that > > > is already in the local database. > > > > > > When a delta-CRL is issued, the CAs MUST also issue a complete CRL. > > > > > > (...) Again, a delta-CRL MUST NOT be issued without a corresponding > > > complete CRL. > > > > > > The two questions are the following: > > > > > > 1) What is the rational for mandating the issuance of a complete CRL > each > > > time a delta-CRL is issued ? > > > 2) Under which conditions could this requirement be relaxed ? > > > > > > Denis From owner-ietf-pkix Tue Jan 2 09:55:02 2001 Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA11232 for ; Tue, 2 Jan 2001 09:54:57 -0800 (PST) Received: from [192.168.7.5] by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Jan 2001 17:58:32 UT Received: from exrsa01.rsa.com (exrsa01.securitydynamics.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA14863; Tue, 2 Jan 2001 12:59:11 -0500 (EST) Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 09:59:10 -0800 Message-ID: From: "Mione, Tony" To: "'David Cross'" , "'Denis Pinkas'" , Sam Schaen Cc: IETF-PXIX Subject: RE: Two questions on delta-CRL Date: Tue, 2 Jan 2001 09:59:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I am not sure what the concern is over needing to publish a new base crl with each delta. This makes perfect sense to me. I think the point of publishing both is so that clients that only process full CRLs can always come up with the same results as a client that can process deltaCRLs. Otherwise, the results of a revocation check will be non-trivial to predict and will vary depending on the client capability and what the CA is willing to support in terms of baseCRL availability. Consider the following: Time CA Publishes t1 baseCRL1 t2 baseCRL1a, deltaCRL1a (baseCRL1a = baseCRL1+deltaCRL1a) t3 baseCRL1b, deltaCRL1b (baseCRL1b = baseCRL1+deltaCRL1b) t4 baseCRL1c, deltaCRL1c (baseCRL1c = baseCRL1+deltaCRL1c) t5 baseCRL2, deltaCRL2 (baseCRL2 = baseCRL1+deltaCRL2) t6 baseCRL2a, deltaCRL2a (baseCRL2a = baseCRL2+deltaCRL2a) etc. Now client1 that needs the latest crl at time t3 <= t <= t4 retrieves baseCRL1b (since they can't handle deltaCRLs). client2 fetches deltaCRL1b and adds its contents to baseCRL1 (since it CAN handle deltaCRLs). This saves bandwidth when client2 needs a crl. However, both clients come up with the same answer. > -----Original Message----- > From: David Cross [mailto:dcross@microsoft.com] > Sent: Tuesday, January 02, 2001 8:36 AM > To: 'Denis Pinkas'; Sam Schaen > Cc: IETF-PXIX > Subject: RE: Two questions on delta-CRL > > > I think the important distinction is to ensure that a valid > base CRL always > exists. A client 1) may not understand a dCRL or 2) a client may not > already have the base CRL that the dCRL is derived from. > > The way I read the RFC is that a valid base CRL must exist > when the dCRL is > published. This does not necessarily mean that the base CRL must be > re-published every time a dCRL is published. > Actually, I think it means a revised baseCRL (which consists of the contents of the deltaCRL added to the original baseCRL) should be published. The baseCRL on which the delta is based should also be available from the CA but does not get republished. My understanding of publishing CRLs is that the CA makes them available in a directory. > If a base CRL is re-published at the same interval as the > dCRL, the value of > dCRLs diminishes as the cost and latency of base CRL > publication is much > higher for the network. > I don't quite follow this. Little network bandwidth is consumed moving a new baseCRL to a CAs directory. I believe that is all that is involved in publication of the CRLs. > David B. Cross > Take care. Tony Mione Senior Software Engineer RSA Security, Inc, 2955 Campus Dr. Suite 400, San Mateo, Ca. +1 650/295-7585 tmione@rsasecurity.com From owner-ietf-pkix Tue Jan 2 11:28:41 2001 Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19310 for ; Tue, 2 Jan 2001 11:28:41 -0800 (PST) Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 11:25:34 -0800 Message-ID: <1BE57AA01A5ED411866500B0D049657B42A5B4@exchange.cylink.com> From: "Covey, Carlin" To: "'Stephen Kent'" , PKIX-List Subject: RE: DPD & DPV requirements - return one or more sets of certifica tion paths Date: Tue, 2 Jan 2001 11:25:26 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C074F1.C24D9AA0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C074F1.C24D9AA0 Content-Type: text/plain; charset="iso-8859-1" Steve and PKIX working group, I think Steve has done an excellent job is setting forth a proposed set of requirements for evaluating DPD and DPV standards. Thank you Steve. This should help us on the way to reaching closure on this important set of standards. That said, I'd like to weigh in with some suggested revisions to Steve's proposal. I'll make each suggestion in a separate posting, with a view to generating more, but shorter and more focused discussion threads. >From Steve's email sent Friday, December 29, 2000 11:25 AM : "2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation.. .." This requirement is a bit ambiguous. It probably is intended to mean that the server must be able to return one or more sets of certification paths and associated revocation data related to a single target certificate. However, the wording could be interpreted as meaning that the server must be able to return this information for a set of (possibly unrelated) target certificates. My preference is for the former. I suggest the following revision: "2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation related to a single target certificate." .Regards to all, and Happy New Year! - Carlin Covey ------_=_NextPart_001_01C074F1.C24D9AA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Steve=20 and PKIX working group,

I think=20 Steve has done an excellent job is setting forth a proposed set of = requirements=20 for evaluating DPD and DPV standards.

Thank=20 you Steve.  This should help us on the way to reaching closure on = this=20 important set of standards.

 

That=20 said, I'd like to weigh in with some suggested revisions to Steve's=20 proposal.  I'll make each suggestion in a separate = posting,
with a view=20 to generating more, but shorter and more focused discussion=20 threads.

From=20 Steve's email sent Friday, December 29, 2000 11:25 AM = :
       &nb= sp; =20 "2.2 A server must be able to return one or more sets of = certification=20 paths and associated revocation data as a result of path 
       &nb= sp;  =20 discovery/validation..     .."

This requirement is a bit ambiguous. It = probably is=20 intended to mean that the server must be able to return one or more = sets of=20
certification paths and associated revocation data related to a = single=20 target certificate. However, the wording
could be interpreted as = meaning=20 that the server must be able to return this information for a set of = (possibly=20 unrelated) target
certificates. My preference is for the former. I = suggest=20 the following revision:

       &nb= sp;           &nb= sp;          =20 "2.2 A server must be able to return one or more sets of = certification=20 paths and associated 
       &nb= sp;           &nb= sp;           &nb= sp; revocation=20 data as a result of path discovery/validation related to a single = target=20 certificate."

.Regards to = all, and Happy=20 New Year!

 

- Carlin=20 Covey

------_=_NextPart_001_01C074F1.C24D9AA0-- From owner-ietf-pkix Tue Jan 2 12:16:35 2001 Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA22014 for ; Tue, 2 Jan 2001 12:16:35 -0800 (PST) Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Jan 2001 12:13:28 -0800 Message-ID: <1BE57AA01A5ED411866500B0D049657B42A5B6@exchange.cylink.com> From: "Covey, Carlin" To: PKIX-List Subject: RE: DPD & DPV requirements Date: Tue, 2 Jan 2001 12:13:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C074F8.755F1190" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C074F8.755F1190 Content-Type: text/plain; charset="iso-8859-1" >From Steve's email sent Friday, December 29, 2000 11:25 AM : 2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation. Each set shall consist of an ordered list of certificates and associated CRLs and/or OCSP responses. The wording concerning an ordered list could use some more specifics. Is the response to be an ordered list of certificates, followed by an ordered list of revocation information (presumably in the same order), or is it to be an ordered list of certificate/revocation-information pairs? My preference is for the pairs. Although the sort order is intuitive, it should probably be declared more explicitly. My preference is for certificate-path order, beginning with the target certificate. I propose the following revised wording: " ... Each set shall consist of a list of pairs of certificates and CRLs and/or OCSP responses, in certificate path order. ------_=_NextPart_001_01C074F8.755F1190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From = Steve's email=20 sent Friday, December 29, 2000 11:25 AM :
       &nb= sp;    

          = ;            = ;    =20  2.2     A server must be able to return one = or more=20 sets of certification paths and associated revocation data=20
           &n= bsp;           &n= bsp;  =20 as a result of path discovery/validation. Each=20 set shall consist of an ordered list of certificates = and=20 associated  
         = ;            = ;     =20  CRLs and/or OCSP responses.

The wording concerning = an ordered=20 list could use some more = specifics.=20 Is the response to be an ordered list of certificates, followed by an = ordered=20
list of revocation information (presumably in the same order), or = is it to=20 be an ordered list of certificate/revocation-information pairs?
My = preference=20 is for the pairs.
 

Although  the sort order  is intuitive, = it should probably be declared more = explicitly. My=20 preference is for certificate-path order, beginning with the target=20 certificate. 

=

I propose the following=20 revised wording:

       &nb= sp;           &nb= sp;  =20 " ...  Each set shall consist of a list of = pairs of=20 certificates and CRLs and/or OCSP responses, in certificate path=20 order.

------_=_NextPart_001_01C074F8.755F1190-- From owner-ietf-pkix Tue Jan 2 15:44:38 2001 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01976 for ; Tue, 2 Jan 2001 15:44:37 -0800 (PST) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id WAA31514; Tue, 2 Jan 2001 22:49:55 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20010102185120.00bd7330@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 02 Jan 2001 18:59:43 -0500 To: ietf-pkix@imc.org From: Ari Kermaier Subject: CRMF/CMP question Cc: dcarru@phaos.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed There are several places in CMP/CRMF where a definition such as the following appears: CertReqMsg ::= SEQUENCE { (...) regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL } In such a field, is it permissible for more than one AttributeTypeAndValue having the same type OID to be present? If yes, how should the multiple entries be processed? If no, shouldn't there be a comment to that effect, or perhaps a new production defined (such as AttrTypeAndValueSequence ::= SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue)) with a comment included? Ari Kermaier Phaos Technology From owner-ietf-pkix Tue Jan 2 15:56:43 2001 Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02535 for ; Tue, 2 Jan 2001 15:56:42 -0800 (PST) Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id f02Nv7j08015; Wed, 3 Jan 2001 08:57:07 +0900 (KST) From: "Kwon, YongChul" To: "'Ari Kermaier'" Cc: Subject: RE: CRMF/CMP question Date: Wed, 3 Jan 2001 09:02:07 +0900 Message-ID: <006901c07518$69de11c0$8525eecb@initech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <4.2.0.58.20010102185120.00bd7330@mail.phaos.com> Hi. > There are several places in CMP/CRMF where a definition such as the > following appears: > CertReqMsg ::= SEQUENCE { > (...) > regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue > OPTIONAL } > In such a field, is it permissible for more than one > AttributeTypeAndValue > having the same type OID to be present? I think SEQUENCE OF implicitly requires no duplicated occurrence of same oid. If it permits, then I think that it should be SET OF. Same concept applied to the X.509 Extension and X.500 Name structure. From owner-ietf-pkix Tue Jan 2 16:03:00 2001 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02968 for ; Tue, 2 Jan 2001 16:02:59 -0800 (PST) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id XAA31554; Tue, 2 Jan 2001 23:07:55 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20010102191514.00a223c0@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 02 Jan 2001 19:17:43 -0500 To: "Kwon, YongChul" From: Ari Kermaier Subject: RE: CRMF/CMP question Cc: , dcarru@phaos.com In-Reply-To: <006901c07518$69de11c0$8525eecb@initech.com> References: <4.2.0.58.20010102185120.00bd7330@mail.phaos.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed >Hi. > > > There are several places in CMP/CRMF where a definition such as the > > following appears: > > CertReqMsg ::= SEQUENCE { > > (...) > > regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue > > OPTIONAL } > > In such a field, is it permissible for more than one > > AttributeTypeAndValue > > having the same type OID to be present? > > I think SEQUENCE OF implicitly requires no duplicated > occurrence of same oid. > > If it permits, then I think that it should be SET OF. > > Same concept applied to the X.509 Extension and X.500 Name > structure. I'm pretty sure the ASN.1 notation "SEQUENCE OF" implies no requirements concerning duplicate elements. Also, for purposes of CMP, using "SET OF" would be problematic because the order of elements must be determinable in order to verify signatures and MACs. From owner-ietf-pkix Tue Jan 2 16:38:20 2001 Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03946 for ; Tue, 2 Jan 2001 16:38:19 -0800 (PST) Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id f030cqj08574; Wed, 3 Jan 2001 09:38:52 +0900 (KST) From: "Kwon, YongChul" To: "'Ari Kermaier'" Cc: Subject: RE: CRMF/CMP question Date: Wed, 3 Jan 2001 09:43:51 +0900 Message-ID: <006a01c0751e$3ee1ada0$8525eecb@initech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <4.2.0.58.20010102191514.00a223c0@mail.phaos.com> > I'm pretty sure the ASN.1 notation "SEQUENCE OF" implies no > requirements yes. you're right. I mean that I think the concept of X.509 Extension structure would be applied. sorry for ambiguous expression. :-) > concerning duplicate elements. Also, for purposes of CMP, > using "SET OF" > would be problematic because the order of elements must be > determinable in > order to verify signatures and MACs. it's true. but in this case, RFC-2511 and it's son defines 2 possiblities - one is utf8Pairs and CertReq. in case of utf8Pairs, I think the informations should not be spread to 2 or more regInfo-utf8Pairs(because utf8Pairs already express all informations in one reginfo) - same as IssureAltNames. so I think it can't be a problem. then let's think about the CertRequest conveyed in regInfo. yes... I agree with you. I think It could be a problem. RFC-2511bis said Information directly related to certificate content SHOULD be included in the certReq content. However, inclusion of additional certReq content by RAs may invalidate the pop field. Data therefore intended for certificate content MAY be provided in regInfo. Hmm... it sounds the case when RAVerified POP used, right? at that time, RFC-2510(Appendix B4) requires 1-2 CertReqMessages in CertReqMessages. and if 2 requests exists, the second one have no proof of possession so in this case, the CertRequest in regInfo implies the first one - POP invalidated by RA. Hmm.. so I think it's not a problem neither. I can't be quite sure. but What do you think about my opinion? If there are any missing points, please let me know them. From owner-ietf-pkix Tue Jan 2 17:52:44 2001 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA06049 for ; Tue, 2 Jan 2001 17:52:44 -0800 (PST) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id AAA31713; Wed, 3 Jan 2001 00:57:56 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20010102202313.00be0ed0@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 02 Jan 2001 21:07:43 -0500 To: "Kwon, YongChul" From: Ari Kermaier Subject: RE: CRMF/CMP question Cc: In-Reply-To: <006a01c0751e$3ee1ada0$8525eecb@initech.com> References: <4.2.0.58.20010102191514.00a223c0@mail.phaos.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed > > concerning duplicate elements. Also, for purposes of CMP, > > using "SET OF" > > would be problematic because the order of elements must be > > determinable in > > order to verify signatures and MACs. > > it's true. > > but in this case, RFC-2511 and it's son defines 2 possiblities > - one is utf8Pairs and CertReq. Does this mean that other AttributeTypeAndValue pairs (i.e., ones not specified in rfc2511 as registration controls) are prohibited? I assumed not, though I could be wrong. > in case of utf8Pairs, I think the informations should not be > spread to 2 or more regInfo-utf8Pairs(because utf8Pairs already > express all informations in one reginfo) - same as IssureAltNames. > so I think it can't be a problem. UTF8Pairs is different, because a method is specified for concatenating multiple UTF8String values for the one OID. The same cannot be said for AttributeTypeAndValue in general. As far as IssuerAltName goes, the syntax is a SEQUENCE of GeneralName, where one of the choices is otherName which is defined as a sequence of OID and value (similar to AttributeTypeAndValue). The description for SubjectAltName (draft-ietf-pkix-new-part1-03) explicitly allows multiple GeneralName entries of the same name form; presumably this includes multiple otherName instances with the same OIDs. These semantics make sense in the context of a sequence of GeneralName, but not necessarily for AttributeTypeAndValue in general. Witness son-of-rfc2459's explicit instruction that "Only one instance of a particular extension may appear in a particular certificate"; but no similar language appears in rfc2510bis or rfc2511bis.) > then let's think about the CertRequest conveyed in regInfo. > yes... I agree with you. I think It could be a problem. There's a lot more to this question than regInfo. For example, registration Controls (in CRMF CertRequest) includes such defined types as id-regCtrl-oldCertID and id-regCtrl-pkiPublicationInfo. For oldCertID, clearly it makes no sense to have more than one such control in a singe CertRequest, but nothing in the spec prohibits it or says what to do if you encounter such a situation (e.g, take the first one, or the last one, or ignore both, or reject the whole thing). For pkiPublicationInfo, there is no logical contradiction in having more than one such control, but the syntax for the control explicitly provides a mechanism to include multiple pubInfos in a single control. This would seem to imply that multiple controls with the same OID are discouraged. But are they illegal? Other places where this question arises incude, in CMP (rfc2510bis): PKIHeader.generalInfo (section 3.1.1), the GenMsgContent PKIBody type (3.3.19) and GenRepContent (3.3.20). From owner-ietf-pkix Tue Jan 2 18:04:19 2001 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA06522 for ; Tue, 2 Jan 2001 18:04:19 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G6K00701DYJI2@ext-mail.valicert.com> for ietf-pkix@imc.org; Tue, 2 Jan 2001 18:08:43 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G6K0034LDYIK7@ext-mail.valicert.com>; Tue, 02 Jan 2001 18:08:42 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Tue, 02 Jan 2001 18:04:58 -0800 Content-return: allowed Date: Tue, 02 Jan 2001 18:04:57 -0800 From: Ambarish Malpani Subject: RE: Two questions on delta-CRL To: "'Denis Pinkas'" , Sam Schaen Cc: IETF-PXIX Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E6EBD5F@exchange.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" I, too, would like to see the requirement relaxed to a full CRL SHOULD be published when a delta CRL is issued. If I remember correctly, this was discussed on the list. I believe PKIX has it because X.509 had it. Also, in the past, the discussion indicated that a CA might publish a new full CRL and then send it to /dev/null, so the full CRL was only published in principal. It would be good to get a definitive answer to how real the requirement for the full CRL is. Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Tuesday, January 02, 2001 6:37 AM > To: Sam Schaen > Cc: IETF-PXIX > Subject: Re: Two questions on delta-CRL > > > Sam, > > Thanks for attempting to answer the question. One possible > answer would be > to prevent people using delta-CRLs to get an advantage over > people using > regular CRLs. The text used to write RFC 2459 was written at > a time where > OCSP servers did not existed. However, clients now using OCSP > servers may > get such an advantage, i.e. fresher information about > revocation status. > > Would the following scenario (currently forbidden by RFC > 2459) makes sense ? > > The full CRL is issued every day, and a delta CRL is issued > every hour. > > I was wondering whether it would be possible to relax this > rule, and thus > have e.g.: > > When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL. > > However, before doing so, we must understand the original > rational and all > the implications. To understand the original rational I would expect a > response from one of the authors of RFC 2459. However, for > the second part > of the question (i.e. all the implications) the discussion is open. > > Denis > > > > I believe the requirement for issuing a complete CRL when a > delta CRL is > > released makes sense. It permits applications that don't > understand delta > > CRLs to obtain the most recent information. Overall > network bandwidth usage > > is still reduced to the extent that other delta-CRL-capable > applications do > > make use of the delta CRL rather than retrieving a full CRL. The > > availability of a current full CRL also allows an application to > > resynchronize at any point. > > > > Denis Pinkas wrote: > > > > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: > > > > > > The delta CRL indicator is a critical CRL extension > that identifies a > > > delta-CRL. The use of delta-CRLs can significantly improve > > > processing time for applications which store revocation > information > > > in a format other than the CRL structure. This allows > changes to be > > > added to the local database while ignoring unchanged > information that > > > is already in the local database. > > > > > > When a delta-CRL is issued, the CAs MUST also issue a > complete CRL. > > > > > > (...) Again, a delta-CRL MUST NOT be issued without a > corresponding > > > complete CRL. > > > > > > The two questions are the following: > > > > > > 1) What is the rational for mandating the issuance of a > complete CRL each > > > time a delta-CRL is issued ? > > > 2) Under which conditions could this requirement be relaxed ? > > > > > > Denis > From owner-ietf-pkix Tue Jan 2 18:18:22 2001 Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07042 for ; Tue, 2 Jan 2001 18:18:21 -0800 (PST) Received: from sigma (sigma.initech.com [203.238.37.133]) by venus.initech.com (8.11.0/8.11.0) with SMTP id f032Isj09873; Wed, 3 Jan 2001 11:18:54 +0900 (KST) From: "Kwon, YongChul" To: "'Ari Kermaier'" Cc: Subject: RE: CRMF/CMP question Date: Wed, 3 Jan 2001 11:23:54 +0900 Message-ID: <006c01c0752c$3878b720$8525eecb@initech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <4.2.0.58.20010102202313.00be0ed0@mail.phaos.com> > As far as IssuerAltName goes, the syntax is a SEQUENCE of > GeneralName, > where one of the choices is otherName which is defined as a > sequence of OID > and value (similar to AttributeTypeAndValue). The description for > SubjectAltName (draft-ietf-pkix-new-part1-03) explicitly > allows multiple > GeneralName entries of the same name form; presumably this includes > multiple otherName instances with the same OIDs. These > semantics make sense > in the context of a sequence of GeneralName, but not necessarily for > AttributeTypeAndValue in general. Witness son-of-rfc2459's explicit > instruction that "Only one instance of a particular extension > may appear in > a particular certificate"; but no similar language appears in > rfc2510bis or rfc2511bis.) you're right. :-) > There's a lot more to this question than regInfo. For > example, registration > Controls (in CRMF CertRequest) includes such defined types as > id-regCtrl-oldCertID and id-regCtrl-pkiPublicationInfo. For > oldCertID, > clearly it makes no sense to have more than one such control > in a singe > CertRequest, but nothing in the spec prohibits it or says > what to do if you > encounter such a situation (e.g, take the first one, or the > last one, or > ignore both, or reject the whole thing). For > pkiPublicationInfo, there is > no logical contradiction in having more than one such > control, but the > syntax for the control explicitly provides a mechanism to > include multiple > pubInfos in a single control. This would seem to imply that multiple > controls with the same OID are discouraged. But are they illegal? > Other places where this question arises incude, in CMP (rfc2510bis): > PKIHeader.generalInfo (section 3.1.1), the GenMsgContent PKIBody type > (3.3.19) and GenRepContent (3.3.20). I agree. yeah, they're not illegal. but, I think if a control(or extension) structure can include all related informations, then that informations should exist in one control(extension). It makes things more clearer and better, doesn't it? :-) and it is a kind of canonicalization. What I exampled - IssureAltName was not good example. :-( What I said was that it could be ... not about the clearity of RFC and draft. at this point I missed the track. I agree with you. RFC-2511 and bis and RFC-2510 will be better if they have verbose comments(that's what I always want!) From owner-ietf-pkix Tue Jan 2 18:22:32 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA07364 for ; Tue, 2 Jan 2001 18:22:32 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jan 2001 18:26:27 -0800 (Pacific Standard Time) Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 2 Jan 2001 18:26:14 -0800 Message-ID: <24A715275661C8428C00432EFCA5CB7C01094F88@red-msg-02.redmond.corp.microsoft.com> From: David Cross To: IETF-PXIX Subject: RE: Two questions on delta-CRL Date: Tue, 2 Jan 2001 18:26:17 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) If a full CRL MUST be published every time a delta CRL is published, it diminishes the value of publishing delta CRLs. Replicating full CRLs can be an expensive process depending on the size of the CRL and delta CRLs were a solution to alleviate that. Saying that both the delta aware and non-delta aware clients should have the same information is an invalid argument. That would mean that OCSP and non-OCSP aware clients should have the same info which is simply not true. The requirement should be relaxed. David B. Cross -----Original Message----- From: Ambarish Malpani [mailto:ambarish@valicert.com] Sent: Tuesday, January 02, 2001 6:05 PM To: 'Denis Pinkas'; Sam Schaen Cc: IETF-PXIX Subject: RE: Two questions on delta-CRL I, too, would like to see the requirement relaxed to a full CRL SHOULD be published when a delta CRL is issued. If I remember correctly, this was discussed on the list. I believe PKIX has it because X.509 had it. Also, in the past, the discussion indicated that a CA might publish a new full CRL and then send it to /dev/null, so the full CRL was only published in principal. It would be good to get a definitive answer to how real the requirement for the full CRL is. Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: Tuesday, January 02, 2001 6:37 AM > To: Sam Schaen > Cc: IETF-PXIX > Subject: Re: Two questions on delta-CRL > > > Sam, > > Thanks for attempting to answer the question. One possible > answer would be > to prevent people using delta-CRLs to get an advantage over > people using > regular CRLs. The text used to write RFC 2459 was written at > a time where > OCSP servers did not existed. However, clients now using OCSP > servers may > get such an advantage, i.e. fresher information about > revocation status. > > Would the following scenario (currently forbidden by RFC > 2459) makes sense ? > > The full CRL is issued every day, and a delta CRL is issued > every hour. > > I was wondering whether it would be possible to relax this > rule, and thus > have e.g.: > > When a delta-CRL is issued, the CAs SHOULD also issue a complete CRL. > > However, before doing so, we must understand the original > rational and all > the implications. To understand the original rational I would expect a > response from one of the authors of RFC 2459. However, for > the second part > of the question (i.e. all the implications) the discussion is open. > > Denis > > > > I believe the requirement for issuing a complete CRL when a > delta CRL is > > released makes sense. It permits applications that don't > understand delta > > CRLs to obtain the most recent information. Overall > network bandwidth usage > > is still reduced to the extent that other delta-CRL-capable > applications do > > make use of the delta CRL rather than retrieving a full CRL. The > > availability of a current full CRL also allows an application to > > resynchronize at any point. > > > > Denis Pinkas wrote: > > > > > In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: > > > > > > The delta CRL indicator is a critical CRL extension > that identifies a > > > delta-CRL. The use of delta-CRLs can significantly improve > > > processing time for applications which store revocation > information > > > in a format other than the CRL structure. This allows > changes to be > > > added to the local database while ignoring unchanged > information that > > > is already in the local database. > > > > > > When a delta-CRL is issued, the CAs MUST also issue a > complete CRL. > > > > > > (...) Again, a delta-CRL MUST NOT be issued without a > corresponding > > > complete CRL. > > > > > > The two questions are the following: > > > > > > 1) What is the rational for mandating the issuance of a > complete CRL each > > > time a delta-CRL is issued ? > > > 2) Under which conditions could this requirement be relaxed ? > > > > > > Denis > From owner-ietf-pkix Tue Jan 2 19:32:09 2001 Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08920 for ; Tue, 2 Jan 2001 19:32:09 -0800 (PST) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 018833676; Tue, 2 Jan 2001 22:37:15 -0500 (EST) Received: from caveosystems.com (adsl-141-154-118-176.bostma.adsl.bellatlantic.net [141.154.118.176]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id WAA12759; Tue, 2 Jan 2001 22:37:17 -0500 Message-ID: <3A529F49.6C571895@caveosystems.com> Date: Tue, 02 Jan 2001 22:40:57 -0500 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Ambarish Malpani CC: IETF-PXIX Subject: Re: Two questions on delta-CRL References: <613B3C619C9AD4118C4E00B0D03E7C3E6EBD5F@exchange.valicert.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > I, too, would like to see the requirement relaxed to a full CRL > SHOULD be published when a delta CRL is issued. This would essentially force everyone to understand deltaCRL's. I do not think the world is ready for that yet. /r$ From owner-ietf-pkix Tue Jan 2 19:37:59 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA09318 for ; Tue, 2 Jan 2001 19:37:59 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Jan 2001 19:41:53 -0800 (Pacific Standard Time) Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Tue, 2 Jan 2001 19:41:40 -0800 Message-ID: <24A715275661C8428C00432EFCA5CB7C01094F8A@red-msg-02.redmond.corp.microsoft.com> From: David Cross To: "'Rich Salz'" , Ambarish Malpani Cc: IETF-PXIX Subject: RE: Two questions on delta-CRL Date: Tue, 2 Jan 2001 19:41:47 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) I have to disagree. Everyone should continue to publish base CRLs as often as they do today. If you have the capability and clients that understand delta CRLs, then you can take advantage of the technology and publish delta CRLs much more frequently. Even if a base CRL were published every time a delta CRL was published, many clients will not retrieve a new base because many clients cache a base CRL locally until it expires. The benefit goes away and the issues with frequent publication of a base CRL increase. David B. Cross -----Original Message----- From: Rich Salz [mailto:rsalz@caveosystems.com] Sent: Tuesday, January 02, 2001 7:41 PM To: Ambarish Malpani Cc: IETF-PXIX Subject: Re: Two questions on delta-CRL > I, too, would like to see the requirement relaxed to a full CRL SHOULD > be published when a delta CRL is issued. This would essentially force everyone to understand deltaCRL's. I do not think the world is ready for that yet. /r$ From owner-ietf-pkix Tue Jan 2 20:02:16 2001 Received: from fs3.ece.ubc.ca (fs3.ece.ubc.ca [137.82.52.241]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA10075 for ; Tue, 2 Jan 2001 20:02:16 -0800 (PST) Received: from rwd6.ece.ubc.ca (rwd6.ece.ubc.ca [137.82.57.203]) by fs3.ece.ubc.ca (8.9.0/8.9.0) with SMTP id UAA04947; Tue, 2 Jan 2001 20:04:08 -0800 (PST) Received: from localhost by rwd6.ece.ubc.ca (5.61/SMI-4.0) id AA18999; Tue, 2 Jan 01 20:00:35 -0800 Date: Tue, 2 Jan 2001 20:00:34 -0800 (PST) From: hansen wang To: David Cross Cc: "'Rich Salz'" , Ambarish Malpani , IETF-PXIX Subject: RE: Two questions on delta-CRL In-Reply-To: <24A715275661C8428C00432EFCA5CB7C01094F8A@red-msg-02.redmond.corp.microsoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 2 Jan 2001, David Cross wrote: > I have to disagree. Everyone should continue to publish base CRLs as often > as they do today. If you have the capability and clients that understand > delta CRLs, then you can take advantage of the technology and publish delta > CRLs much more frequently. Agree. Seems to me that some are mistaking "publishing" for "need to download". When the CA issues both a Base CRL and a Delta CRL, the clients have an option _at_all_times_ to download either: 1. the current Base if they cannot handle Deltas or if the Base (or Full) CRL that they're holding cannot be updated by the current Delta CRL because it is too old, 2. the current Delta if the Base (or Full) CRL that they're hold _CAN_ be updated by the current Delta CRL. There's no need for each client to download both just because they're published. Both can bring the client upto the Current CRL. > Even if a base CRL were published every time a delta CRL was published, many > clients will not retrieve a new base because many clients cache a base CRL > locally until it expires. The benefit goes away and the issues with > frequent publication of a base CRL increase. Agree here too. Most clients can make use of the Delta but there will always be some small percentage of clients that will have to suffer the penalty of needing to download a Base CRL for reason listed above. Publishing both a Current Base and Delta CRL does not require an out-of-date client to have to download both an older Base CRL and an additional Current Delta CRL to bring it up to the Current Full CRL. Optionally, the Delta CRL may also include the hash signature of the Current Full CRL to use as an integrity check to see that it has an exact copy of the Current Full CRL that was published by the CA. -- *************************************************************** Hansen Wang Office: CICSR381 M.A.Sc Candidate Room: MCLD 458/CICSR388 Communications Group Tel: (604)822-4985 (Lab) ECE, UBC (604)822-5084 (Lab) 2356 Main Mall Fax: (604)822-5949 Vancouver, BC email: hansenw@ece.ubc.ca V6T 1Z4 ************* http://www.ee.ubc.ca/~hansenw ***************** From owner-ietf-pkix Wed Jan 3 00:58:21 2001 Received: from popmail2.inbox.se (root@popmail2.inbox.se [212.28.208.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06453 for ; Wed, 3 Jan 2001 00:58:20 -0800 (PST) Received: from santesson.accurata.se (slip-202-135-193-215.sg.sg.prserv.net [202.135.193.215]) by popmail2.inbox.se (8.10.1/8.10.1) with ESMTP id f0390Mi23319; Wed, 3 Jan 2001 10:00:51 +0100 Message-Id: <5.0.0.25.2.20010103094454.029b40c8@mail.accurata.se> X-Sender: mb517@mail.accurata.se X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 03 Jan 2001 10:01:40 +0100 To: , "Ietf-Pkix" From: Stefan Santesson Subject: Re: Why don't using Permanent Identifier on QC certificates? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA06458 Juan Carlos, After reading the trailing answers to your mail I choose to answer yours directly since I don't want to get involved in the best identifier system for US. The QC standard (approved 5 Nov 2000) gives you a set of attributes to express an identity in the form of a DN. You can choose to include another attribute at your selection but then this attribute must NOT be necessary to identify the person. So if you choose to follow the QC RFC, you should definitely use the SN attribute to store a national registration code (such as SSN), IF you have made the decision that you want to include this code at all. The PI draft defines another attribute/mechanism to create a complete new way of assigning a unique identifier for a person. I.e. to my knowledge you can't use it to store an existing code (such as SSN). So if you have an existing code structure, use SN and if you want to use the PI concept then use that but only as a complement to a complete DN. I would though be careful before I start using PI in a wide scale because I fear that it may not scale as well as we would like. In Sweden you have to go to the national standards body to get an OID. Since OID is only designed to define objects in standards, the current schema in Sweden are to my knowledge just dimensioned to register more than just above 16000 organizations under the Swedish root. They have just used up about 500 + so that is not a problem right now. But imagine what would happen if every organization asks for its own OID structure to register peoples/employees, then the standards body would have to create a new sub structure for this. I have not made my homework to well so I can be wrong here but I think this should be overlooked more carefully before we jump to fast into approving the PI concept. /Stefan At 16:25 2000-12-19 -0400, Juan Carlos Pérez Aguayo wrote: >In the QC draft is stated: > >"...The serialNumber attribute type SHALL, when present, be used to > differentiate between names where the subject field would otherwise > be identical. This attribute has no defined semantics beyond > ensuring uniqueness of subject names. It MAY contain a number or > code assigned by the CA or an identifier assigned by a government or > civil authority. It is the CA's responsibility to ensure that the > serialNumber is sufficient to resolve any subject name collisions..." > >and on the Permanet Identifier drfat; >Sorry if this discussion has happened before, but I don't know if there are >some final statement: > >"... A serialNumber attribute may be used for two > different purposes in the DN of a person: > > 1) In a DN or a SubjectAltName to differentiate between > two names (for two different individuals) that otherwise > would not be different. > > 2) In the identifier field from a permanent identifier. > This is the recommended use for national ID's and > employee ID's, for example. ..." > >Now, consider this: > >a person has a unique identifier, assigned by a goverment authority, wich is >guaranteed to be unique on a national scope (country domain) > >How to incorporate this identifier into a certificate?. > >SerialNumber or SubjevctAltname field? When I read the QC profile >"..identifier assigned by a goverment o civil authority...", and then the PI >draft say "... This is recommended use for national ID's...", I am confused. > >Why the QC does not use Permanent Identifier? > >Thera are some application wich need incorporate this class of personal >identifier. By example, in my country (CHILE) each people ha an unique ID >stamped in a card (this card has the photography and handwritting too), and >this is broadly recognized for identification. One can to do many >transactions wich need this ID for proceed. > >Thanks in advance > >Juan Carlos Pérez A. >Acepta.com From owner-ietf-pkix Wed Jan 3 01:39:30 2001 Received: from mailf.telia.com (root@mailf.telia.com [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA11399 for ; Wed, 3 Jan 2001 01:39:29 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id KAA19048; Wed, 3 Jan 2001 10:43:44 +0100 (CET) Received: from mega (t6o69p90.telia.com [213.64.110.210]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f039hhl12269; Wed, 3 Jan 2001 10:43:43 +0100 (CET) Message-ID: <004401c07569$7163b6b0$0201a8c0@vincent.se> From: "Anders Rundgren" To: , "Ietf-Pkix" , "Stefan Santesson" References: <5.0.0.25.2.20010103094454.029b40c8@mail.accurata.se> Subject: Re: Why don't using Permanent Identifier on QC certificates? Date: Wed, 3 Jan 2001 10:42:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id BAA11403 Stefan, > The PI draft defines another attribute/mechanism to create a complete new > way of assigning a unique identifier for a person. I.e. to my knowledge you > can't use it to store an existing code (such as SSN). The PI draft does as you say introduce a a completely new way of assigning a unique identifier to an entity (although the current draft mention individuals, I consider that just a typo...), but does not prohibit (or recommend) this identifier in any way. I.e. PI should work with any existing UID scheme. > I would though be careful before I start using PI in a wide scale because I > fear that it may not scale as well as we would like. In Sweden you have to > go to the national standards body to get an OID. Since OID is only designed > to define objects in standards, the current schema in Sweden are to my > knowledge just dimensioned to register more than just above 16000 > organizations under the Swedish root. They have just used up about 500 + so > that is not a problem right now. But imagine what would happen if every > organization asks for its own OID structure to register peoples/employees, > then the standards body would have to create a new sub structure for this. I think this is slightly wrong. The OID you mention refer to a registered naming authority which is essentially only applicable to a few useful external schemes that exists today. Like DUNS, the Swedish citizen registry etc. Organizations acting as CAs would typically not specify this optional element as their naming domain = CA. > I have not made my homework to well so I can be wrong here but I think this > should be overlooked more carefully before we jump to fast into approving > the PI concept. I believe that the PI concept has some problems like competing with DN and maybe worse: If the PI-thing is going to automate the mapping processes we use today I have some serious doubts on the current semantics like: - Is a single CA (cert) supposed to support an arbitrary set of naming domains? - What happens if a CA generates some certs with and some without PI? Syntax error? IMO it had been better if PI had supported DN mapping and was a part of a CA cert only. That would restrict PI naming domains to one / CA but that is IMO a much more practical solution. /anders From owner-ietf-pkix Wed Jan 3 03:31:19 2001 Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA23971 for ; Wed, 3 Jan 2001 03:31:18 -0800 (PST) Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id DAC292FD2 for ; Wed, 03 Jan 2001 12:35:43 +0100 (CET) Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id 9B05C108003; Wed, 3 Jan 2001 12:35:43 +0100 (CET) Message-ID: <3A530E89.187037FA@celocom.de> Date: Wed, 03 Jan 2001 12:35:37 +0100 From: Bernd Matthes Reply-To: mainbug@celocom.de Organization: Celo Communications GmbH http://www.celocom.de X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: de,en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: RFC2630: Need clarification Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0F6717299EE167242E6870E4" This is a cryptographically signed message in MIME format. --------------ms0F6717299EE167242E6870E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! At first a happy new year to all! I need a clarification to following sentence from RFC 2630, section 11.4, Countersignature: "The countersignature attribute must be an unsigned attribute; it cannot be a signed attribute, an authenticated attribute, or an unauthenticated attribute." What is the difference between: a) signed attribute <-> authenticated attribute b) unsigned attribute <-> unauthenticated attribute to relate to CMS? Where is located a (un)authenticated attribute in an signed-data CMS? I thought, it exist as (un)signed attribute in the SignerInfo, or is this complete beside them? Thanks in advance with kind regards -- Mors certa, hora incerta. In dubio pro mille. -------------------------------------------------------------------- Bernd Matthes Celo Communications GmbH Senior Software Engineer Weissenfelser Strasse 46a Nachrichtentechniker D 06217 Merseburg Dipl.-Ing.(FH) http://www.celocom.com f. technische Informatik mailto:mainbug@celocom.de http://www.worldbug.de Tel.: +49 3461/3318-0 mailto:mainbug@worldbug.de Fax: +49 3461/415072 -------------------------------------------------------------------- "When in doubt, use brute force." (Ken Thompson) --------------ms0F6717299EE167242E6870E4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG 9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw 6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2 YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2 uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7 vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG 5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG 3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTAzMTEzNTQzWjAjBgkq hkiG9w0BCQQxFgQU340tlzmcw3r0o9Hv6rQe4B0wqlUwUgYJKoZIhvcNAQkPMUUwQzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDJQYcEBWa957+6bszKR0wnrEMy/SreRy5SD/Pl V2IkNiK37jCtYNU7hkmNpp2gB3qua2NQWNZelaa2KRj8ZRWq1bgcO3chcESv3xc2ts5LoHRi iwvty+ci0MqWus5JURQsTifod8wa9WUTq1QBsr7Lcu3nvxI4pSL22RUGHntDUw== --------------ms0F6717299EE167242E6870E4-- From owner-ietf-pkix Wed Jan 3 03:37:05 2001 Received: from femail5.sdc1.sfba.home.com (femail5.sdc1.sfba.home.com [24.0.95.85]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24439 for ; Wed, 3 Jan 2001 03:37:05 -0800 (PST) Received: from revelation ([65.4.166.11]) by femail5.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20010103114131.UENM29808.femail5.sdc1.sfba.home.com@revelation>; Wed, 3 Jan 2001 03:41:31 -0800 Reply-To: From: "Jim Schaad" To: , Subject: RE: RFC2630: Need clarification Date: Wed, 3 Jan 2001 03:40:22 -0800 Message-ID: <000c01c07579$f5b81b30$1500a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3A530E89.187037FA@celocom.de> First - Questions on CMS should be directed to the S/MIME mailing list not the PKIX mailing list. Authenticated and Unauthenticated attributes occur in the AuthenticatedData structure (section 9). The statement is just being made that a counter signature is not present in the AuthenticatedData structure. jim schaad -----Original Message----- From: Bernd Matthes [mailto:mainbug@celocom.de] Sent: Wednesday, January 03, 2001 3:36 AM To: ietf-pkix@imc.org Subject: RFC2630: Need clarification Hi! At first a happy new year to all! I need a clarification to following sentence from RFC 2630, section 11.4, Countersignature: "The countersignature attribute must be an unsigned attribute; it cannot be a signed attribute, an authenticated attribute, or an unauthenticated attribute." What is the difference between: a) signed attribute <-> authenticated attribute b) unsigned attribute <-> unauthenticated attribute to relate to CMS? Where is located a (un)authenticated attribute in an signed-data CMS? I thought, it exist as (un)signed attribute in the SignerInfo, or is this complete beside them? Thanks in advance with kind regards -- Mors certa, hora incerta. In dubio pro mille. -------------------------------------------------------------------- Bernd Matthes Celo Communications GmbH Senior Software Engineer Weissenfelser Strasse 46a Nachrichtentechniker D 06217 Merseburg Dipl.-Ing.(FH) http://www.celocom.com f. technische Informatik mailto:mainbug@celocom.de http://www.worldbug.de Tel.: +49 3461/3318-0 mailto:mainbug@worldbug.de Fax: +49 3461/415072 -------------------------------------------------------------------- "When in doubt, use brute force." (Ken Thompson) From owner-ietf-pkix Wed Jan 3 04:15:17 2001 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26531 for ; Wed, 3 Jan 2001 04:15:17 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18634; Wed, 3 Jan 2001 07:19:42 -0500 (EST) Message-Id: <200101031219.HAA18634@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-technr-03.txt Date: Wed, 03 Jan 2001 07:19:41 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Technical Requirements for a non-Repudiation Service Author(s) : T. Gindin Filename : draft-ietf-pkix-technr-03.txt Pages : 8 Date : 02-Jan-01 This document describes those features of a service which processes signed documents which must be present in order for that service to constitute a 'technical non-repudiation' service. A technical non-repudiation service must permit an independent verifier to determine whether a given signature was applied to a given data object by the private key associated with a given valid certificate, at a time later than the signature. The features of a technical non- repudiation service are expected to be necessary for a full non- repudiation service, although they may not be sufficient. This document is intended to clarify the definition of the 'non-repudiation' service in RFC 2459. It should thus serve as a guide to when the nonRepudiation bit of the keyUsage extension should be set and to when a Certificate Authority is required to archive CRL's. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-technr-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-technr-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-technr-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010102133951.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-technr-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-technr-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010102133951.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix Wed Jan 3 06:30:26 2001 Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05871 for ; Wed, 3 Jan 2001 06:30:25 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailc.telia.com (8.11.0/8.11.0) with ESMTP id f03EYp628919 for ; Wed, 3 Jan 2001 15:34:51 +0100 (CET) Received: from mega (t4o69p77.telia.com [62.20.145.197]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f03EYol20528 for ; Wed, 3 Jan 2001 15:34:50 +0100 (CET) Message-ID: <010001c07592$1c87c9f0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "PKIX-List" Subject: Very Basic DN question Date: Wed, 3 Jan 2001 15:33:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id GAA05872 Sorry for bringing a very basic question to the table but I could not find this information anywhere. DN1 CN=John Doe, C=US, SN=6767 DN2 CN=John Doe + C=US + SN=6767 The latter is what *some* (not all!) certificate viewers show when the SET contains multiple items. Q: Does the former indicate a tree (with CN at the top?) , while the latter indicate that all elements belong to the same level? We RDBMS-oriented developers do seldom utilize this information but it is always nice to know. :-) /anders From owner-ietf-pkix Wed Jan 3 06:50:58 2001 Received: from dymwsm05.mailwatch.com (dymwsm05.mailwatch.com [204.253.83.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06471 for ; Wed, 3 Jan 2001 06:50:57 -0800 (PST) Received: from dymw0125.mailwatch.com (dymw0125.allegro.net [204.253.83.81]) by dymwsm05.mailwatch.com (8.11.0/8.11.0) with SMTP id f03Ess713936 for ; Wed, 3 Jan 2001 09:54:54 -0500 Received: from 204.253.83.26 by dymw0125.mailwatch.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 03 Jan 01 09:54:51 -0500 X-Server-Uuid: 8014d96c-8cb5-11d4-814d-00508bd934cf Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by dymwsm11.mailwatch.com (8.11.0/8.11.0) with ESMTP id f03Esof10885; Wed, 3 Jan 2001 09:54:50 -0500 Received: from dharter (213-123-72-112.btconnect.com [213.123.72.112]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZWLNKC1Q; Wed, 3 Jan 2001 06:52:09 -0800 From: "Darren Harter" To: "'Anders Rundgren'" , "'PKIX-List'" Subject: RE: Very Basic DN question Date: Wed, 3 Jan 2001 14:52:30 -0000 Message-ID: <000101c07594$ccecbb50$017fa8c0@entegrity.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <010001c07592$1c87c9f0$0201a8c0@vincent.se> X-WSS-ID: 164DE2B12243-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Anders, The simple answer is yes. In the first case you have one Distinguished Name (DN) that contains three Relative Distinguished Names (RDNs) where each RDN has one Attribute Type and Value (ATV). If the order of the RDNs in your string representaion is the same as the order in the RDN's in the ASN.1 encoding, then yes the CN is the top of the tree. If they are shown reverse of the ASN.1 encoding (and some applications do show DNs the other way around), then SN is the top of the tree. It all depends on the directory schema used by your application. In the second case, you have one DN that has one RDN, where the RDN has three ATVs; all at the same level in the tree - the top. Hope this helps, Darren -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@telia.com] Sent: 03 January 2001 14:33 To: PKIX-List Subject: Very Basic DN question Sorry for bringing a very basic question to the table but I could not find this information anywhere. DN1 CN=John Doe, C=US, SN=6767 DN2 CN=John Doe + C=US + SN=6767 The latter is what *some* (not all!) certificate viewers show when the SET contains multiple items. Q: Does the former indicate a tree (with CN at the top?) , while the latter indicate that all elements belong to the same level? We RDBMS-oriented developers do seldom utilize this information but it is always nice to know. :-) /anders From owner-ietf-pkix Wed Jan 3 07:04:36 2001 Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07911 for ; Wed, 3 Jan 2001 07:04:35 -0800 (PST) Received: from frolic.celocom.de (frolic.celocom.de [212.78.104.90]) by brot.celocom.de (Postfix) with ESMTP id E54072FD2 for ; Wed, 03 Jan 2001 16:09:01 +0100 (CET) Received: from celocom.de (bernd.celocom.de [212.78.104.41]) by frolic.celocom.de (Postfix) with ESMTP id D637C108003 for ; Wed, 3 Jan 2001 16:09:01 +0100 (CET) Message-ID: <3A53408B.9BB1ECE@celocom.de> Date: Wed, 03 Jan 2001 16:08:59 +0100 From: Bernd Matthes Reply-To: mainbug@celocom.de Organization: Celo Communications -- http://www.celocom.com X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: de,en MIME-Version: 1.0 To: ietf pkix Subject: Question to Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msD6F76CBCE8ECFF095FFD13A4" This is a cryptographically signed message in MIME format. --------------msD6F76CBCE8ECFF095FFD13A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi! I have a question to the following sentence from section 2.4.1. Request Format: "The messageImprint field SHOULD contain the hash of the datum to be time stamped." What is the meaning of 'datum'? Should it be 'data' instead of 'datum'? Thanks for any comments. with kind regards -- Mors certa, hora incerta. In dubio pro mille. -------------------------------------------------------------------- Bernd Matthes Celo Communications GmbH Senior Software Engineer Weissenfelser Strasse 46a Nachrichtentechniker D 06217 Merseburg Dipl.-Ing.(FH) http://www.celocom.com f. technische Informatik mailto:mainbug@celocom.de http://www.worldbug.de Tel.: +49 3461/3318-0 mailto:mainbug@worldbug.de Fax: +49 3461/415072 -------------------------------------------------------------------- "When in doubt, use brute force." (Ken Thompson) --------------msD6F76CBCE8ECFF095FFD13A4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKSgYJKoZIhvcNAQcCoIIKOzCCCjcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B9YwggSgMIIECaADAgECAhBsOnTzXfzOOQkJistWSC3oMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDEyNzAwMDAw MFoXDTAxMDIwOTIzNTk1OVowggESMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFjAUBgNVBAMUDUJlcm5kIE1hdHRoZXMxITAfBgkqhkiG 9w0BCQEWEm1haW5idWdAY2Vsb2NvbS5kZTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA 5XDGxWjDOe+gHZygtVsNACVkbiY27ug06wI9DGzn4+ibdyEoqNnMlqe7dHSHsLG5f9Fl8gBa ZgwOUnNClgnjCbqoByj4In82wWwUG97DndueKQhN78pYDRBWhGXKo/YSGI2l5rw7fjYnlTlw 6QQF0OGpFNBXzkNCBC4muSaI2YUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASB pDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJp U2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlT aWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhFAQYHBCIWIDFjNzhjMGNiYWZjMzg2 YzQzYzFmMWFjYTY5NzY4Nzk3MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAsvJl1q8TirOQUfjbbyZKmVdi k+2YQmQr64uvnEGf0Vp/laotPE49SR5Vu9GwGA2cPY/CPrb9v/bc3mOnCBlJ2m/xQIITJRxv A66enfch2KSRLjl+VyU5BeIkq3UZekTAy76DPozOEwd6Azf4fLJy6AIh/DRS0GS9w/l2sLYQ FAAwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAw WhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVw b3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1Zl cmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZh bGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2 uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7 vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG 5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEH AQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNV HRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCt qp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG 3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGN Azzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWdu LmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYG A1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29u YSBOb3QgVmFsaWRhdGVkAhBsOnTzXfzOOQkJistWSC3oMAkGBSsOAwIaBQCggbEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwMTAzMTUwOTAxWjAjBgkq hkiG9w0BCQQxFgQUyimHrQxEZTeSEHUdHzmMbDA2CBgwUgYJKoZIhvcNAQkPMUUwQzAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZI hvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBQAxQBP5d5P7bV4UcAMlb3bWIukUBl7UIoN2lb H/HZX7Dl3xkDnEGVS63ZJ00QeH7E+KSQCmZgfUH1gofHeaSvJzbe8M1srjMovf1KYwE/1hhn 6vBVSJgRBcV0QswCFzVo/3WezfAboTGqdajBqf1V9P8LdEmeH7shL6ZhGyYUFA== --------------msD6F76CBCE8ECFF095FFD13A4-- From owner-ietf-pkix Wed Jan 3 07:07:40 2001 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08203 for ; Wed, 3 Jan 2001 07:07:40 -0800 (PST) Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id KAA09240 for ; Wed, 3 Jan 2001 10:12:06 -0500 (EST) Message-Id: <4.2.2.20010103100053.00acf4c0@email.nist.gov> X-Sender: cooper@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 03 Jan 2001 10:11:54 -0500 To: "'PKIX-List'" From: "David A. Cooper" Subject: RE: Very Basic DN question In-Reply-To: <000101c07594$ccecbb50$017fa8c0@entegrity.com> References: <010001c07592$1c87c9f0$0201a8c0@vincent.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Darren, I would differ with your interpretation slightly. RFC 2253 (UTF-8 String Representation of Distinguished Names) states that "the output consists of the string encodings of each RelativeDistinguishedName ... starting with the last element of the sequence and moving backwards toward the first." Thus, if DN1 were properly encoded according to RFC 2253, it should be interpreted as a SEQUENCE of 3 RDNs with SN being the first element in the SEQUENCE(i.e., the top of the tree) and CN being the last element (i.e., the the bottom of the tree). In the case of DN2, the plus sign as a separator indicates that DN2 consists of one multi-valued RDN. Since an RDN is a SET of attribute type and value pairs (as opposed to a SEQUENCE), the elements are unordered (i.e., they are all at the same level). Dave At 02:52 PM 1/3/01 +0000, Darren Harter wrote: >Anders, > >The simple answer is yes. > >In the first case you have one Distinguished Name (DN) that contains three >Relative Distinguished Names (RDNs) where each RDN has one Attribute Type >and Value (ATV). If the order of the RDNs in your string representaion is >the same as the order in the RDN's in the ASN.1 encoding, then yes the CN is >the top of the tree. If they are shown reverse of the ASN.1 encoding (and >some applications do show DNs the other way around), then SN is the top of >the tree. It all depends on the directory schema used by your application. > >In the second case, you have one DN that has one RDN, where the RDN has >three ATVs; all at the same level in the tree - the top. > >Hope this helps, > >Darren > >-----Original Message----- >From: Anders Rundgren [mailto:anders.rundgren@telia.com] >Sent: 03 January 2001 14:33 >To: PKIX-List >Subject: Very Basic DN question > > >Sorry for bringing a very basic question to the table but I could not find >this information anywhere. > >DN1 CN=John Doe, C=US, SN=6767 >DN2 CN=John Doe + C=US + SN=6767 > >The latter is what *some* (not all!) certificate viewers show when the SET >contains >multiple items. > >Q: Does the former indicate a tree (with CN at the top?) , while the latter >indicate >that all elements belong to the same level? We RDBMS-oriented developers >do seldom utilize this information but it is always nice to know. :-) > >/anders > From owner-ietf-pkix Wed Jan 3 07:15:42 2001 Received: from euryale.inf.ufsc.br (euryale.inf.ufsc.br [150.162.60.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA08638 for ; Wed, 3 Jan 2001 07:15:41 -0800 (PST) Received: from safeweb (inf242.inf.ufsc.br [150.162.60.242]) by euryale.inf.ufsc.br (8.11.1/8.11.1) with SMTP id f03GL1Q31420 for ; Wed, 3 Jan 2001 13:21:01 -0300 Message-ID: <030401c07598$c2253130$f23ca296@safeweb.com.br> From: "Augusto Jun Devegili" To: "ietf pkix" References: <3A53408B.9BB1ECE@celocom.de> Subject: Re: Question to Date: Wed, 3 Jan 2001 13:20:51 -0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Datum is single, data is plural. ----- Original Message ----- From: "Bernd Matthes" To: "ietf pkix" Sent: Wednesday, January 03, 2001 1:08 PM Subject: Question to > What is the meaning of 'datum'? > Should it be 'data' instead of 'datum'? From owner-ietf-pkix Wed Jan 3 07:17:39 2001 Received: from ntserver2.chrysalis-its.com ([209.47.245.163]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09150 for ; Wed, 3 Jan 2001 07:17:38 -0800 (PST) From: FRousseau@chrysalis-its.com Received: by NTSERVER2 with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 10:22:38 -0500 Message-ID: <918C70B01822D411A87400B0D0204DFF72F58C@panda.chrysalis-its.com> To: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: RE: Two questions on delta-CRL Date: Wed, 3 Jan 2001 10:22:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07599.015074F0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C07599.015074F0 Content-Type: text/plain; charset="iso-8859-1" Hi Denis, If you look at Annex C of X.509 (2000) on Examples of Delta CRL Issuance, you will see that a full CRL does NOT need to be issued with each Delta CRL. Cheers, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 -----Original Message----- From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] Sent: Tuesday, January 02, 2001 6:25 AM To: IETF-PXIX Subject: Two questions on delta-CRL In section 5.2.4 (Delta CRL Indicator), RFC 2459 states: The delta CRL indicator is a critical CRL extension that identifies a delta-CRL. The use of delta-CRLs can significantly improve processing time for applications which store revocation information in a format other than the CRL structure. This allows changes to be added to the local database while ignoring unchanged information that is already in the local database. When a delta-CRL is issued, the CAs MUST also issue a complete CRL. (...) Again, a delta-CRL MUST NOT be issued without a corresponding complete CRL. The two questions are the following: 1) What is the rational for mandating the issuance of a complete CRL each time a delta-CRL is issued ? 2) Under which conditions could this requirement be relaxed ? Denis ------_=_NextPart_001_01C07599.015074F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Two questions on delta-CRL

Hi Denis,

If you look at Annex C of X.509 (2000) on Examples of = Delta CRL Issuance, you will see that a full CRL does NOT need to be = issued with each Delta CRL.

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078



-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]<= /FONT>
Sent: Tuesday, January 02, 2001 6:25 AM
To: IETF-PXIX
Subject: Two questions on delta-CRL



In section 5.2.4 (Delta CRL Indicator), RFC 2459 = states:

  The delta CRL indicator is a critical CRL = extension that identifies a
  delta-CRL.  The use of delta-CRLs can = significantly improve
  processing time for applications which store = revocation information
  in a format other than the CRL = structure.  This allows changes to be
  added to the local database while ignoring = unchanged information that
  is already in the local database.

  When a delta-CRL is issued, the CAs MUST also = issue a complete CRL.

  (...) Again, a delta-CRL MUST NOT be issued = without a corresponding
  complete CRL.

The two questions are the following:

1) What is the rational for mandating the issuance of = a complete CRL each
time a delta-CRL is issued ?
2) Under which conditions could this requirement be = relaxed ?

Denis

------_=_NextPart_001_01C07599.015074F0-- From owner-ietf-pkix Wed Jan 3 07:19:56 2001 Received: from internet.across ([213.212.5.232]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA09900 for ; Wed, 3 Jan 2001 07:19:55 -0800 (PST) Received: FROM acrossw01.across BY internet.across ; Wed Jan 03 16:26:48 2001 +0100 Received: by acrossw01.acrosswireless.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 16:21:14 +0100 Message-ID: From: Simon Tardell To: "'Mione, Tony'" , "'David Cross'" , "'Denis Pinkas'" , Sam Schaen Cc: IETF-PXIX Subject: RE: Two questions on delta-CRL Date: Wed, 3 Jan 2001 16:21:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" > I don't quite follow this. Little network bandwidth is consumed > moving a new baseCRL to a CAs directory. I believe that is all that > is involved in publication of the CRLs. Some directories we've tried become very tired when you write large objects to them (megabyte and up) and to some extent when reading the same large objects. It is not a question of bandwidth, but rather of how the directory vendors tune their apps (then again, maybe there was a knob to tweak that I didn't see). Simon. Simon Tardell, Software Architect, SmartTrust voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@smarttrust.com Work smarter! http://www.smarttrust.com/career From owner-ietf-pkix Wed Jan 3 07:24:49 2001 Received: from dymwsm08.mailwatch.com (dymwsm08.mailwatch.com [204.253.83.44]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA11317 for ; Wed, 3 Jan 2001 07:24:48 -0800 (PST) Received: from dymw0119.mailwatch.com (dymw0119.allegro.net [204.253.83.139]) by dymwsm08.mailwatch.com (8.11.0/8.11.0) with SMTP id f03FSjU25608 for ; Wed, 3 Jan 2001 10:28:45 -0500 Received: from 204.253.83.34 by dymw0119.mailwatch.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Wed, 03 Jan 01 10:28:44 -0500 X-Server-Uuid: a8a70c28-5efd-11d4-a0eb-00508bd30591 Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by dymwsm12.mailwatch.com (8.11.0/8.11.0) with ESMTP id f03FSis12938; Wed, 3 Jan 2001 10:28:44 -0500 Received: from dharter (213-123-72-112.btconnect.com [213.123.72.112]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZWLNKCKH; Wed, 3 Jan 2001 07:26:03 -0800 From: "Darren Harter" To: "'David A. Cooper'" , "'PKIX-List'" Subject: RE: Very Basic DN question Date: Wed, 3 Jan 2001 15:26:24 -0000 Message-ID: <000501c07599$892a9810$017fa8c0@entegrity.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <4.2.2.20010103100053.00acf4c0@email.nist.gov> X-WSS-ID: 164D9AA617248-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Thanks for the RFC2253 quote Dave. I agree completely. Unfortunately, in my experience not all applications conform to it - hence me describing both orderings. Darren -----Original Message----- From: David A. Cooper [mailto:david.cooper@nist.gov] Sent: 03 January 2001 15:12 To: 'PKIX-List' Subject: RE: Very Basic DN question Darren, I would differ with your interpretation slightly. RFC 2253 (UTF-8 String Representation of Distinguished Names) states that "the output consists of the string encodings of each RelativeDistinguishedName ... starting with the last element of the sequence and moving backwards toward the first." Thus, if DN1 were properly encoded according to RFC 2253, it should be interpreted as a SEQUENCE of 3 RDNs with SN being the first element in the SEQUENCE(i.e., the top of the tree) and CN being the last element (i.e., the the bottom of the tree). In the case of DN2, the plus sign as a separator indicates that DN2 consists of one multi-valued RDN. Since an RDN is a SET of attribute type and value pairs (as opposed to a SEQUENCE), the elements are unordered (i.e., they are all at the same level). Dave At 02:52 PM 1/3/01 +0000, Darren Harter wrote: >Anders, > >The simple answer is yes. > >In the first case you have one Distinguished Name (DN) that contains three >Relative Distinguished Names (RDNs) where each RDN has one Attribute Type >and Value (ATV). If the order of the RDNs in your string representaion is >the same as the order in the RDN's in the ASN.1 encoding, then yes the CN is >the top of the tree. If they are shown reverse of the ASN.1 encoding (and >some applications do show DNs the other way around), then SN is the top of >the tree. It all depends on the directory schema used by your application. > >In the second case, you have one DN that has one RDN, where the RDN has >three ATVs; all at the same level in the tree - the top. > >Hope this helps, > >Darren > >-----Original Message----- >From: Anders Rundgren [mailto:anders.rundgren@telia.com] >Sent: 03 January 2001 14:33 >To: PKIX-List >Subject: Very Basic DN question > > >Sorry for bringing a very basic question to the table but I could not find >this information anywhere. > >DN1 CN=John Doe, C=US, SN=6767 >DN2 CN=John Doe + C=US + SN=6767 > >The latter is what *some* (not all!) certificate viewers show when the SET >contains >multiple items. > >Q: Does the former indicate a tree (with CN at the top?) , while the latter >indicate >that all elements belong to the same level? We RDBMS-oriented developers >do seldom utilize this information but it is always nice to know. :-) > >/anders > From owner-ietf-pkix Wed Jan 3 08:16:08 2001 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16762 for ; Wed, 3 Jan 2001 08:16:07 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Jan 2001 09:19:54 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 03 Jan 2001 09:19:52 -0700 From: "Bob Jueneman" To: Cc: Subject: RE: Two questions on delta-CRL Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16763 Simon, Without intending to set off any vendor bashing, it might be nice to know the directory you were using, so others could help determine whether that is a common problem or not. By "tired" I assume you mean there was a lot of grinding caused by garbage collection or moving files around when writing the data. In the best of all worlds that would be undesirable, of course, but I suppose it could happen. II it also made retrievals considerably more "painful" (since we are anthropomorphizing,) that would be worse, of course. But some data, rather than generalizations, would be helpful. Of course a different issue would be why, given the CRLDistributionPoint facility which could be use to segment a CRL into a set of more reasonable size sub-CRLs, you needed to have a megabyte CRL in the first place? Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software >>> Simon Tardell 01/03/01 08:21AM >>> > I don't quite follow this. Little network bandwidth is consumed > moving a new baseCRL to a CAs directory. I believe that is all that > is involved in publication of the CRLs. Some directories we've tried become very tired when you write large objects to them (megabyte and up) and to some extent when reading the same large objects. It is not a question of bandwidth, but rather of how the directory vendors tune their apps (then again, maybe there was a knob to tweak that I didn't see). Simon. Simon Tardell, Software Architect, SmartTrust voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@smarttrust.com Work smarter! http://www.smarttrust.com/career From owner-ietf-pkix Wed Jan 3 11:32:53 2001 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA00278 for ; Wed, 3 Jan 2001 11:32:53 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Jan 2001 11:36:49 -0800 (Pacific Standard Time) Received: by inet-imc-02.redmond.corp.microsoft.com with Internet Mail Service (5.5.2651.58) id ; Wed, 3 Jan 2001 08:26:30 -0800 Message-ID: <24A715275661C8428C00432EFCA5CB7C01094FA2@red-msg-02.redmond.corp.microsoft.com> From: David Cross To: ietf-pkix@imc.org Subject: RE: Two questions on delta-CRL Date: Wed, 3 Jan 2001 08:26:24 -0800 X-Mailer: Internet Mail Service (5.5.2651.58) It is a problem in any large distributed directory, web farm, or complex CDP infrastructure. It is more of an issue of the infrastructure design and not a particular product(s). It is easy to get multi-MB CRLs if you have large numbers of revocations (corporate layoffs, etc) that occur from a single CA. David B. Cross -----Original Message----- From: Bob Jueneman [mailto:bjueneman@novell.com] Sent: Wednesday, January 03, 2001 8:20 AM To: simon.tardell@smarttrust.com Cc: ietf-pkix@imc.org Subject: RE: Two questions on delta-CRL Simon, Without intending to set off any vendor bashing, it might be nice to know the directory you were using, so others could help determine whether that is a common problem or not. By "tired" I assume you mean there was a lot of grinding caused by garbage collection or moving files around when writing the data. In the best of all worlds that would be undesirable, of course, but I suppose it could happen. II it also made retrievals considerably more "painful" (since we are anthropomorphizing,) that would be worse, of course. But some data, rather than generalizations, would be helpful. Of course a different issue would be why, given the CRLDistributionPoint facility which could be use to segment a CRL into a set of more reasonable size sub-CRLs, you needed to have a megabyte CRL in the first place? Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software >>> Simon Tardell 01/03/01 08:21AM >>> > I don't quite follow this. Little network bandwidth is consumed > moving a new baseCRL to a CAs directory. I believe that is all that > is involved in publication of the CRLs. Some directories we've tried become very tired when you write large objects to them (megabyte and up) and to some extent when reading the same large objects. It is not a question of bandwidth, but rather of how the directory vendors tune their apps (then again, maybe there was a knob to tweak that I didn't see). Simon. Simon Tardell, Software Architect, SmartTrust voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319 simon.tardell@smarttrust.com Work smarter! http://www.smarttrust.com/career From owner-ietf-pkix Wed Jan 3 14:51:00 2001 Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA09887 for ; Wed, 3 Jan 2001 14:50:59 -0800 (PST) Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 14:47:39 -0800 Message-ID: <1BE57AA01A5ED411866500B0D049657B42A5B8@exchange.cylink.com> From: "Covey, Carlin" To: "'Stephen Kent'" , PKIX-List Subject: RE: DPD & DPV requirements - server usage of data proffered by cl ient Date: Wed, 3 Jan 2001 14:47:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075D7.2AAD1AE0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C075D7.2AAD1AE0 Content-Type: text/plain; charset="iso-8859-1" Steve, I have some questions concerning requirements 1.1 and 1.2 from your proposed DPD and DPV requirements. "1.1 A client request can contain a single certificate or a certificate chain terminating in the "target" certificate, to assist the server in path construction. " "1.2 A client request can contain one or more revocation data items, to assist the server in path validation." In requirement 1.1, the phrase "...to assist the server in path construction. " implies that the client's intent is simply to aid the server, rather than to impose constraints on the server. This interpretation is supported by the absence of a requirement that would obligate the server to construct a path using the certificate chain proffered by the client. Have I made the correct interpretation? Requirement 1.2 contains the similar phrase "to assist the server in path validation." and again there is no requirement on the server to make use of this revocation data. But in this case, it doesn't seem quite right for the server to ignore the proffered revocation data, nor to accept it as verity. For example, if the proffered data is an OCSP response that indicates that a certificate is revoked**, it does not seem safe for the server to ignore this data in favor of a somewhat dated CRL that indicates that the certificate is not revoked. On the other hand, if the proffered data is an OCSP response that indicates that the certificate is not revoked, is the server under no obligation to perform any further checks on the revocation status? Note that the server may not be able to determine the freshness of the proffered OCSP response with any exactitude. (** Of course, it would be silly for the client to proffer an OCSP response or CRL that indicates that the target certificate is revoked. However, the proffered revocation data may be for some other certificate that the client thinks that the server might use for constructing a certification path. Another possibility is that an XML-literate but ASN.1-illiterate client is incapable of parsing the OCSP response or CRL, but wishes the server to make use of this revocation data.) I realize that such issues will eventually be clarified in the finite state models for the server actions, but I think these points are important, and ought to be captured in the requirements that will drive the development of the state models. I propose the addition of the following clarifications and requirements for the server: "The server may use a certificate chain proffered by the client, but is not obligated to do so. " "If revocation data proffered by the client indicates that a certificate is revoked, the server must reject as invalid any certificate paths containing this certificate." "If revocation data proffered by the client indicates that a certificate is not revoked, the server must independently verify this data before accepting as valid any certificate paths containing this certificate." Regards, Carlin Covey Cylink Corp. ------_=_NextPart_001_01C075D7.2AAD1AE0 Content-Type: text/html; charset="iso-8859-1"
Steve, I have some questions concerning requirements 1.1 and 1.2 from your proposed DPD and DPV requirements. 
 

           "1.1 A client request can contain a single certificate or a certificate chain terminating 
             in the "target" certificate, to assist the server in path construction. " 

             "1.2 A client request can contain one or more revocation data items, to assist the server 
              in path validation."

In requirement 1.1, the phrase "...to assist the server in path construction. " implies that the client's intent is
simply to aid the server, rather than to impose constraints on the server.  This interpretation is supported by
the absence of a requirement that would obligate the server to construct a path using the certificate chain proffered
by the client.  Have I made the correct interpretation? 
 
Requirement 1.2 contains the similar phrase "to assist the server in path validation."  and again there is no requirement
on the server to make use of this revocation data.  But in this case, it doesn't seem quite right for the server to ignore
the proffered revocation data, nor to accept it as verity.  For example, if the proffered data is an OCSP response that
indicates that a certificate is revoked**, it does not seem safe for the server to ignore this data in favor of a somewhat
dated CRL that indicates that the certificate is not revoked.  On the other hand, if the proffered data is an OCSP response
that indicates that the certificate is not revoked, is the server under no obligation to perform any further checks on the
revocation status?  Note that the server may not be able to determine the freshness of the proffered OCSP response
with any exactitude.
 
 
(** Of course, it would be silly for the client to proffer an OCSP response or CRL that indicates that the target certificate
is revoked.  However, the proffered revocation data may be for some other certificate that the client thinks that the server
might use for constructing a certification path.  Another possibility is that an XML-literate but ASN.1-illiterate client is
incapable of parsing the OCSP response or CRL, but wishes the server to make use of this revocation data.)
 
 
I realize that such issues will eventually be clarified in the finite state models for the server actions, but I think these
points are important, and ought to be captured in the requirements that will drive the development of the state models.
 
I propose the addition of the following clarifications and requirements for the server:
 

           "The server may use a certificate chain proffered by the client, but is not obligated to do so. " 

            "If revocation data proffered by the client indicates that a certificate is revoked, the server must
              reject as invalid any certificate paths containing this certificate."

            "If revocation data proffered by the client indicates that a certificate is not revoked, the server must
              independently verify this data before accepting as valid any certificate paths containing this certificate."
 
 
Regards,
 
Carlin Covey
Cylink Corp.
 
 
 
------_=_NextPart_001_01C075D7.2AAD1AE0-- From owner-ietf-pkix Wed Jan 3 17:24:28 2001 Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA12980 for ; Wed, 3 Jan 2001 17:24:28 -0800 (PST) Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 Jan 2001 17:21:24 -0800 Message-ID: <1BE57AA01A5ED411866500B0D049657B42A5BA@exchange.cylink.com> From: "Covey, Carlin" To: PKIX-List Subject: RE: DPD & DPV requirements - to nonce or not to nonce? Date: Wed, 3 Jan 2001 17:21:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C075EC.A6A5F6C0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C075EC.A6A5F6C0 Content-Type: text/plain; charset="iso-8859-1" To thwart replay attacks, both OCSP and SCVP have provisions for the optional inclusion of nonces in requests and responses . The premise of this is that the requester picks a nonce that it hasn't used before, and includes it in its request. The server is obligated to return this same nonce, ensuring that the response was prepared after the request. I don't see a provision in the proposed DPD and DPV requirements for the optional inclusion of a nonce. Is this an intentional omission, or inadvertent? Do we want/need nonces in the new DPD/DPV standards? I won't venture an opinion, but I will make some observations. Since nonces are permitted in OCSP v1 responses, nonces may appear in OCSP responses embedded in the requests sent to the DPD or DPV server. "1.2 A client request can contain one or more revocation data items, to assist the server in path validation." - from proposed DPD & DPV requirements The nonces in the OCSP responses will be of no use to the server, because the server did not generate the OCSP requests with the matching nonces. Likewise, the responses that a DPD server returns may contain OCSP responses with nonces. (To thwart replay attacks, the DPD server may have put nonces in the requests that it made to OCSP servers.) "2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation. Each set shall consist of an ordered list of certificates and associated CRLs and/or OCSP responses." - from proposed DPD & DPV requirements These nonces will be useful to the DPD server, but not to the DPD client, since the client did not generate the matching OCSP requests. UNLESS ....... the DPD server chooses the same nonce that it received from the DPD client. (Contemplating this makes me queasy.) Recall that the protection against replay attacks was based upon the requester not using the same nonce it had used before. This can be done cheaply by generating the nonces as a sequence, or as a sizable random number. But if the DPD server doesn't generate the nonce, then it must keep a record of all the nonces that it has seen (well, perhaps only those it has seen within some global time-ambiguity interval). Failing to keep track of past nonces renders the DPD server vulnerable to conspiracies between the DPD client and another agent replaying older OCSP responses to the DPD server. But why would a DPD client conspire against itself? It might undertake such a conspiracy in order to fool the DPD server into attesting to incorrect (or at least out-of-date) certificate status, with a view toward later presenting this incorrect attestation to someone else. (If the DPD response is timestamped, then all the response data, including the incorrect revocation data, will have been signed as part of the timestamp.) An alternative would be for the DPD server to generate its own nonces, and then simply attest to the DPD client that all the OCSP responses returned in the DPD response are fresh. But this calls for some amount of trust in the DPD server, and part of the premise for DPD (as opposed to DPV) was that the client might not trust the server. So, to nonce or not to nonce? That is the question. - Regards, Carlin Covey Cylink Corp. ------_=_NextPart_001_01C075EC.A6A5F6C0 Content-Type: text/html; charset="iso-8859-1"
To thwart replay attacks, both OCSP and SCVP have provisions for the optional inclusion of nonces in requests and responses .
 
The premise of this is that the requester picks a nonce that it hasn't used before, and includes it in its request.
The server is obligated to return this same nonce, ensuring that the response was prepared after the request.
 
I don't see a provision in the proposed DPD and DPV requirements for the optional inclusion of a nonce.
Is this an intentional omission, or inadvertent?  Do we want/need nonces in the new DPD/DPV standards?
 
I won't venture an opinion, but I will make some observations.  Since nonces are permitted in OCSP v1 responses,
nonces may appear in OCSP responses embedded in the requests sent to the DPD or DPV server. 

              "1.2 A client request can contain one or more revocation data items, 
                 to assist the server in path validation."   -  from proposed DPD & DPV requirements

The nonces in the OCSP responses will be of no use to the server, because the server did not generate the OCSP
requests with the matching nonces.

 

 

Likewise, the responses that a DPD server returns may contain OCSP responses with nonces.  (To thwart replay attacks,
the DPD server may have put nonces in the requests that it made to OCSP servers.) 

                "2.2 A server must be able to return one or more sets of certification paths and associated 
                  revocation data as a result of path discovery/validation. Each set shall consist of an ordered 
                  list of certificates and associated CRLs and/or OCSP responses."   -  from proposed DPD &
                  DPV requirements

These nonces will be useful to the DPD server, but not to the DPD client, since the client did not generate the matching
OCSP requests.    UNLESS .......  the DPD server chooses the same nonce that it received from the DPD client.  (Contemplating
this makes me queasy.)   Recall that the protection against replay attacks was based upon the requester not using the same
nonce it had used before.  This can be done cheaply by generating the nonces as a sequence, or as a sizable random number.
But if the DPD server doesn't generate the nonce, then it must keep a record of all the nonces that it has seen (well, perhaps
only those it has seen within some global time-ambiguity interval).  Failing to keep track of past nonces renders the DPD
server vulnerable to conspiracies between the DPD client and another agent replaying older OCSP responses to the DPD server.
But why would a DPD client conspire against itself?  It might undertake such a conspiracy in order to fool the DPD server
into attesting to incorrect (or at least out-of-date) certificate status, with a view toward later presenting this incorrect
attestation to someone else.  (If the DPD response is timestamped, then all the response data, including the incorrect revocation
data, will have been signed as part of the timestamp.)

An alternative would be for the DPD server to generate its own nonces, and then simply attest to the DPD client that all the OCSP
responses returned in the DPD response are fresh.  But this calls for some amount of trust in the DPD server, and part of the
premise for DPD (as opposed to DPV) was that the client might not trust the server.

 

So, to nonce or not to nonce?  That is the question.

- Regards,
Carlin Covey
Cylink Corp.

 

------_=_NextPart_001_01C075EC.A6A5F6C0-- From owner-ietf-pkix Wed Jan 3 21:50:08 2001 Received: from rmail7.hanmir.com ([128.134.130.167]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA18206 for ; Wed, 3 Jan 2001 21:50:07 -0800 (PST) Received: (from nobody@localhost) by rmail7.hanmir.com (8.9.3/8.9.3) id OAA19614; Thu, 4 Jan 2001 14:55:08 +0900 (KST) Date: Thu, 4 Jan 2001 14:55:08 +0900 (KST) Message-Id: <200101040555.OAA19614@rmail7.hanmir.com> To: ietf-pkix@imc.org Subject: How can I implement VSD srvice? From: "±è¿ø¹ü" Content-Type: text/html; charset=euc-kr Status: O Content-Transfer-Encoding: 8bit X-Mailer: HanMir Mailer X-IP: 210.182.155.5 How are you?
My name is Wonbeom, Kim. I'm Korean.
I'm engaged in PKI application development job.
Nowadays, I study DVCS protocol.

I have compiled DVCS protocol with ASN compiler.
And then, in generated result, I notice that "message", "messageImprint", and "certs" elements are eveloped with "union" in "data" element of "DVCSRequest" type.

To support VSD service, I think that a requester must send plain text, digital signed hash value of it, and certificate to a respondent. But, I can't send these informations simultaneously, becasue "message", "messageImprint", and "certs" are unionized.

If the C-codes are generated from ASN.1 notations correctly,
how can I handle this problem. Sorry but, I ask your advice.

____________________________________________________________________________
Çѹ̸£ ¸ÞÀÏ(http://mail.hanmir.com/)
¿øÇÏ´Â °Í¸¸ ²À Áý¾î ã¾ÆÁÖ´Â Çѹ̸£(http://www.hanmir.com/)

From owner-ietf-pkix Wed Jan 3 23:11:32 2001 Received: from mh.transparity.com (IDENT:root@[203.127.198.235]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24084 for ; Wed, 3 Jan 2001 23:11:31 -0800 (PST) Received: from transparity.com (xiaoying.secureage.com [203.127.198.231]) by mh.transparity.com (8.9.3/8.8.7) with ESMTP id PAA12659 for ; Thu, 4 Jan 2001 15:25:04 +0800 Message-ID: <3A54243A.B6BAA0A7@transparity.com> Date: Thu, 04 Jan 2001 15:20:26 +0800 From: Wu Xiao Ying Organization: Transparity Ltd. X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en,zh MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: [Fwd: test certificate with full extensions] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I'd like to see whether my program can read most of the certificate extensions (better in full implementation) defined in X.509 and PKIX. Are there any certificate samples available at any places? Hope they include as many extensions as possible... Please email me privately. Thanks in advance. Regards, Xiaoying From owner-ietf-pkix Thu Jan 4 05:52:42 2001 Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA09347 for ; Thu, 4 Jan 2001 05:52:41 -0800 (PST) Received: from krdp2 (krdp2.ncsl.nist.gov [129.6.54.107]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id IAA05559; Thu, 4 Jan 2001 08:57:03 -0500 (EST) Message-Id: <4.2.2.20010104084709.00acd100@email.nist.gov> X-Sender: cooper@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 04 Jan 2001 08:56:52 -0500 To: Wu Xiao Ying , "ietf-pkix@imc.org" From: "David A. Cooper" Subject: Re: [Fwd: test certificate with full extensions] In-Reply-To: <3A54243A.B6BAA0A7@transparity.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Xiaoying, A few months ago NIST worked with Cygnacom Solutions and Getronics Government Solutions, LLC to develop a set of certification paths for use in testing implementations of the X.509 path validation algorithm. The set of extensions that are included in the test certificates are somewhat limited, but it should work as a very good starting point. If you are interested, information about the test suite, including documentation and the test data itself, is available from http://csrc.nist.gov/pki/testing/x509paths.html I hope this helps, David Cooper At 03:20 PM 1/4/01 +0800, Wu Xiao Ying wrote: >I'd like to see whether my program can read most of the certificate >extensions (better in full implementation) defined in X.509 and PKIX. >Are there any certificate samples available at any places? Hope they >include as many extensions as possible... From owner-ietf-pkix Thu Jan 4 06:11:26 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10404 for ; Thu, 4 Jan 2001 06:11:26 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA25784; Thu, 4 Jan 2001 09:15:55 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <1BE57AA01A5ED411866500B0D049657B42A5B4@exchange.cylink.com> References: <1BE57AA01A5ED411866500B0D049657B42A5B4@exchange.cylink.com> Date: Thu, 4 Jan 2001 09:07:44 -0500 To: "Covey, Carlin" From: Stephen Kent Subject: RE: DPD & DPV requirements - return one or more sets of certifica tion paths Cc: PKIX-List Content-Type: multipart/alternative; boundary="============_-1233504668==_ma============" --============_-1233504668==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Carlin, >Steve and PKIX working group, > >I think Steve has done an excellent job is setting forth a proposed >set of requirements for evaluating DPD and DPV standards. > >Thank you Steve. This should help us on the way to reaching closure >on this important set of standards. > Thanks for the compliment, and the help in refining the requirements. > >That said, I'd like to weigh in with some suggested revisions to >Steve's proposal. I'll make each suggestion in a separate posting, >with a view to generating more, but shorter and more focused >discussion threads. > >From Steve's email sent Friday, December 29, 2000 11:25 AM : > "2.2 A server must be able to return one or more sets of >certification paths and associated revocation data as a result of >path > discovery/validation.. .." > >This requirement is a bit ambiguous. It probably is intended to mean >that the server must be able to return one or more sets of >certification paths and associated revocation data related to a >single target certificate. However, the wording >could be interpreted as meaning that the server must be able to >return this information for a set of (possibly unrelated) target >certificates. My preference is for the former. I suggest the >following revision: > > "2.2 A server must be able to return >one or more sets of certification paths and associated > revocation data as a result of path >discovery/validation related to a single target certificate." Good point. If the WG wants to require support for multiple target certificates per request/response, we can add that as a separate requirement. I will update the spec based on your comments. Steve --============_-1233504668==_ma============ Content-Type: text/enriched; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Carlin, Arial0000,0000,FFFFSteve and PKIX working group, I think Steve has done an excellent job is setting forth a proposed set of requirements for evaluating DPD and DPV standards. Thank you Steve. This should help us on the way to reaching closure on this important set of standards. Arial0000,0000,FFFF Thanks for the compliment, and the help in refining the requirements. Arial0000,0000,FFFFThat said, I'd like to weigh in with some suggested revisions to Steve's proposal. I'll make each suggestion in a separate posting, with a view to generating more, but shorter and more focused discussion threads. =46rom Steve's email sent Friday, December 29, 2000 11:25 AM : "2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path=20 discovery/validation.. .." FFFF,0000,0000This requirement is a bit ambiguous. It probably is intended to mean that the server must be able to return one or more sets of certification paths and associated revocation data related to a single target certificate. However, the wording could be interpreted as meaning that the server must be able to return this information for a set of (possibly unrelated) target certificates. My preference is for the former. I suggest the following revision: "2.2 A server must be able to return one or more sets of certification paths and associated=20 revocation data as a result of path discovery/validation related to a single target certificate." FFFF,0000,0000 Good point. If the WG wants to require support for multiple target certificates per request/response, we can add that as a separate requirement. I will update the spec based on your comments. Steve --============_-1233504668==_ma============-- From owner-ietf-pkix Thu Jan 4 06:11:27 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA10406 for ; Thu, 4 Jan 2001 06:11:26 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA25787; Thu, 4 Jan 2001 09:15:56 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <1BE57AA01A5ED411866500B0D049657B42A5B6@exchange.cylink.com> References: <1BE57AA01A5ED411866500B0D049657B42A5B6@exchange.cylink.com> Date: Thu, 4 Jan 2001 09:09:36 -0500 To: "Covey, Carlin" From: Stephen Kent Subject: RE: DPD & DPV requirements Cc: PKIX-List Content-Type: multipart/alternative; boundary="============_-1233504667==_ma============" --============_-1233504667==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Carlin, >From Steve's email sent Friday, December 29, 2000 11:25 AM : > > > 2.2 A server must be able to return >one or more sets of certification paths and associated revocation >data > as a result of path discovery/validation. >Each set shall consist of an ordered list of certificates and >associated > CRLs and/or OCSP responses. > >The wording concerning an ordered list could use some more >specifics. Is the response to be an ordered list of certificates, >followed by an ordered >list of revocation information (presumably in the same order), or is >it to be an ordered list of certificate/revocation-information pairs? >My preference is for the pairs. > > >Although the sort order is intuitive, it should probably be >declared more explicitly. My preference is for certificate-path >order, beginning with the target certificate. > >I propose the following revised wording: > > " ... Each set shall consist of a list of >pairs of certificates and CRLs and/or OCSP responses, in certificate >path order. I'm comfortable with this proposed refinement, if there are no objections. Steve --============_-1233504667==_ma============ Content-Type: text/enriched; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Carlin, Arial0000,0000,FFFFFrom Steve's email sent Friday, December 29, 2000 11:25 AM : =20 =20 0000,0000,FFFF 2.2 A server must be able to return one or more sets of certification paths and associated revocation data as a result of path discovery/validation. Each set shall consist of an ordered list of certificates and associated Arial=20 CRLs and/or OCSP responses. ArialFFFF,0000,0000= The wording concerning an ordered list could use some more specifics. Is the response to be an ordered list of certificates, followed by an ordered list of revocation information (presumably in the same order), or is it to be an ordered list of certificate/revocation-information pairs? My preference is for the pairs. =20 Although the sort order is intuitive, it should probably be declared more explicitly. My preference is for certificate-path order, beginning with the target certificate.=20 0000,0000,FFFFI propose the following revised wording: " ... Each set shall consist of a list of pairs of certificates and CRLs and/or OCSP responses, in certificate path order. Arial0000,0000,FFFF I'm comfortable with this proposed refinement, if there are no objections.=20 Steve --============_-1233504667==_ma============-- From owner-ietf-pkix Thu Jan 4 06:20:57 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11131 for ; Thu, 4 Jan 2001 06:20:56 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA26838; Thu, 4 Jan 2001 09:25:26 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <1BE57AA01A5ED411866500B0D049657B42A5B8@exchange.cylink.com> References: <1BE57AA01A5ED411866500B0D049657B42A5B8@exchange.cylink.com> Date: Thu, 4 Jan 2001 09:21:03 -0500 To: "Covey, Carlin" From: Stephen Kent Subject: RE: DPD & DPV requirements - server usage of data proffered by cl ient Cc: PKIX-List Content-Type: multipart/alternative; boundary="============_-1233504097==_ma============" --============_-1233504097==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 2:47 PM -0800 1/3/01, Covey, Carlin wrote: Carlin, >Steve, I have some questions concerning requirements 1.1 and 1.2 >from your proposed DPD and DPV requirements. > > > "1.1 A client request can contain a single certificate or >a certificate chain terminating > in the "target" certificate, to assist the server in >path construction. " > > "1.2 A client request can contain one or more >revocation data items, to assist the server > in path validation." > >In requirement 1.1, the phrase "...to assist the server in path >construction. " implies that the client's intent is >simply to aid the server, rather than to impose constraints on the >server. This interpretation is supported by >the absence of a requirement that would obligate the server to >construct a path using the certificate chain proffered >by the client. Have I made the correct interpretation? yes, that was the intent. I expected control over path validation to be managed by the parameters. The offered cert chain was could have been supplied as part of a protocol that pushed a purported path to the client, but the client might not have looked at it at all, especially a DPV client who might not be PKI aware. One might make an argument here for two cases, one in which the client is passing on cert path (and revocation status data) that it has not examined, and one in which the client is trying to constrain path processing by mandating use of the supplied data. if folks agree that support for both flavors of inputs is needed, we can mandate that. Syntactically it's probably easy to add a flag indicating which sort of input is being provided, but it will add complexity to server processing to be able to deal with both cases. > >Requirement 1.2 contains the similar phrase "to assist the server in >path validation." and again there is no requirement >on the server to make use of this revocation data. But in this >case, it doesn't seem quite right for the server to ignore >the proffered revocation data, nor to accept it as verity. For >example, if the proffered data is an OCSP response that >indicates that a certificate is revoked**, it does not seem safe for >the server to ignore this data in favor of a somewhat >dated CRL that indicates that the certificate is not revoked. On >the other hand, if the proffered data is an OCSP response >that indicates that the certificate is not revoked, is the server >under no obligation to perform any further checks on the >revocation status? Note that the server may not be able to >determine the freshness of the proffered OCSP response >with any exactitude. As above, the intent was to accommodate clients who might know nothing of the supplied data and thus were merely passing it on to the server in case it might help. I'm more concerned here that a server not be mislead by outdated revocation status data supplied by a client, maybe an unwitting client, as that could return an inaccurate, "certificate valid" answer based on bad revocation status data that would override what the server would otherwise have used. I'm not comfortable making this sort of change yet. > (** Of course, it would be silly for the client to proffer an OCSP >response or CRL that indicates that the target certificate >is revoked. However, the proffered revocation data may be for some >other certificate that the client thinks that the server >might use for constructing a certification path. Another >possibility is that an XML-literate but ASN.1-illiterate client is >incapable of parsing the OCSP response or CRL, but wishes the server >to make use of this revocation data.) right. that argues for the advisory, but not authoritative, approach I proposed, or the safe approach you describe below. > I realize that such issues will eventually be clarified in the >finite state models for the server actions, but I think these >points are important, and ought to be captured in the requirements >that will drive the development of the state models. > >I propose the addition of the following clarifications and >requirements for the server: > > > "The server may use a certificate chain proffered by the >client, but is not obligated to do so. " > > "If revocation data proffered by the client indicates >that a certificate is revoked, the server must > reject as invalid any certificate paths containing >this certificate." > > "If revocation data proffered by the client indicates >that a certificate is not revoked, the server must > independently verify this data before accepting as >valid any certificate paths containing this certificate." This is a reasonable, safe set of clarifications to the current spec and I'm happy to incorporate them. If folks want to expand the requirements to include the mandatory use of supplied cert chains, I could add that, but will not do so yet. Steve --============_-1233504097==_ma============ Content-Type: text/enriched; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At 2:47 PM -0800 1/3/01, Covey, Carlin wrote: Carlin, =20 Arial0000,0000,FFFFSteve, I have some questions concerning requirements 1.1 and 1.2 from your proposed DPD and DPV requirements.=20 =20 "1.1 A client request can contain a single certificate or a certificate chain terminating=20 in the "target" certificate, to assist the server in path construction. "=20 "1.2 A client request can contain one or more revocation data items, to assist the server=20 in path validation." In requirement 1.1, the phrase "...to assist the server in path construction. " implies that the client's intent is simply to aid the server, rather than to impose constraints on the server. This interpretation is supported by the absence of a requirement that would obligate the server to construct a path using the certificate chain proffered by the client. Have I made the correct interpretation?=20 Arial0000,0000,FFFF yes, that was the intent. I expected control over path validation to be managed by the parameters. The offered cert chain was could have been supplied as part of a protocol that pushed a purported path to the client, but the client might not have looked at it at all, especially a DPV client who might not be PKI aware.=20 One might make an argument here for two cases, one in which the client is passing on cert path (and revocation status data) that it has not examined, and one in which the client is trying to constrain path processing by mandating use of the supplied data. if folks agree that support for both flavors of inputs is needed, we can mandate that. Syntactically it's probably easy to add a flag indicating which sort of input is being provided, but it will add complexity to server processing to be able to deal with both cases. =20 Arial0000,0000,FFFFRequirem= ent 1.2 contains the similar phrase "to assist the server in path validation." and again there is no requirement on the server to make use of this revocation data. But in this case, it doesn't seem quite right for the server to ignore the proffered revocation data, nor to accept it as verity. For example, if the proffered data is an OCSP response that indicates that a certificate is revoked**, it does not seem safe for the server to ignore this data in favor of a somewhat dated CRL that indicates that the certificate is not revoked. On the other hand, if the proffered data is an OCSP response that indicates that the certificate is not revoked, is the server under no obligation to perform any further checks on the revocation status? Note that the server may not be able to determine the freshness of the proffered OCSP response with any exactitude. Arial0000,0000,FFFF As above, the intent was to accommodate clients who might know nothing of the supplied data and thus were merely passing it on to the server in case it might help. I'm more concerned here that a server not be mislead by outdated revocation status data supplied by a client, maybe an unwitting client, as that could return an inaccurate, "certificate valid" answer based on bad revocation status data that would override what the server would otherwise have used. I'm not comfortable making this sort of change yet. Arial0000,0000,FFFF(** Of course, it would be silly for the client to proffer an OCSP response or CRL that indicates that the target certificate is revoked. However, the proffered revocation data may be for some other certificate that the client thinks that the server might use for constructing a certification path. Another possibility is that an XML-literate but ASN.1-illiterate client is incapable of parsing the OCSP response or CRL, but wishes the server to make use of this revocation data.) Arial0000,0000,FFFF right. that argues for the advisory, but not authoritative, approach I proposed, or the safe approach you describe below. Arial0000,0000,FFFFI realize that such issues will eventually be clarified in the finite state models for the server actions, but I think these points are important, and ought to be captured in the requirements that will drive the development of the state models. =20 I propose the addition of the following clarifications and requirements for the server: =20 "The server may use a certificate chain proffered by the client, but is not obligated to do so. "=20 "If revocation data proffered by the client indicates that a certificate is revoked, the server must reject as invalid any certificate paths containing this certificate." "If revocation data proffered by the client indicates that a certificate is not revoked, the server must independently verify this data before accepting as valid any certificate paths containing this certificate." Arial0000,0000,FFFF This is a reasonable, safe set of clarifications to the current spec and I'm happy to incorporate them. If folks want to expand the requirements to include the mandatory use of supplied cert chains, I could add that, but will not do so yet. Steve --============_-1233504097==_ma============-- From owner-ietf-pkix Thu Jan 4 06:40:54 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11770 for ; Thu, 4 Jan 2001 06:40:54 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA29579; Thu, 4 Jan 2001 09:45:24 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <1BE57AA01A5ED411866500B0D049657B42A5BA@exchange.cylink.com> References: <1BE57AA01A5ED411866500B0D049657B42A5BA@exchange.cylink.com> Date: Thu, 4 Jan 2001 09:37:05 -0500 To: "Covey, Carlin" From: Stephen Kent Subject: RE: DPD & DPV requirements - to nonce or not to nonce? Cc: PKIX-List Content-Type: multipart/alternative; boundary="============_-1233502899==_ma============" --============_-1233502899==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:21 PM -0800 1/3/01, Covey, Carlin wrote: >To thwart replay attacks, both OCSP and SCVP have provisions for the >optional inclusion of nonces in requests and responses . > >The premise of this is that the requester picks a nonce that it >hasn't used before, and includes it in its request. >The server is obligated to return this same nonce, ensuring that the >response was prepared after the request. > >I don't see a provision in the proposed DPD and DPV requirements for >the optional inclusion of a nonce. >Is this an intentional omission, or inadvertent? Do we want/need >nonces in the new DPD/DPV standards? I didn't want to mandate the use of nonces per se. However, the security requirement that nonces address is covered in 1.8: 1.8 Either the request/response protocol itself, or a specified lower layer protocol to be employed for requests and responses, there must be a provision for data origin authentication and connectionless integrity for requests and responses, and responses must be matched to requests. Request authentication & integrity is needed to support access control to the server, a requirement for public servers. Responses must be authenticated and integrity-protected to ensure that they are from the indicated server, and matched to the request in question. Additional security services may be offered optionally. > >I won't venture an opinion, but I will make some observations. >Since nonces are permitted in OCSP v1 responses, >nonces may appear in OCSP responses embedded in the requests sent to >the DPD or DPV server. > > "1.2 A client request can contain one or more >revocation data items, > to assist the server in path validation." - from >proposed DPD & DPV requirements > >The nonces in the OCSP responses will be of no use to the server, >because the server did not generate the OCSP >requests with the matching nonces. > > > > > >Likewise, the responses that a DPD server returns may contain OCSP >responses with nonces. (To thwart replay attacks, >the DPD server may have put nonces in the requests that it made to >OCSP servers.) > > "2.2 A server must be able to return one or more >sets of certification paths and associated > revocation data as a result of path >discovery/validation. Each set shall consist of an ordered > list of certificates and associated CRLs and/or >OCSP responses." - from proposed DPD & > DPV requirements > >These nonces will be useful to the DPD server, but not to the DPD >client, since the client did not generate the matching >OCSP requests. UNLESS ....... the DPD server chooses the same >nonce that it received from the DPD client. (Contemplating >this makes me queasy.) Recall that the protection against replay >attacks was based upon the requester not using the same >nonce it had used before. This can be done cheaply by generating >the nonces as a sequence, or as a sizable random number. >But if the DPD server doesn't generate the nonce, then it must keep >a record of all the nonces that it has seen (well, perhaps >only those it has seen within some global time-ambiguity interval). >Failing to keep track of past nonces renders the DPD >server vulnerable to conspiracies between the DPD client and another >agent replaying older OCSP responses to the DPD server. >But why would a DPD client conspire against itself? It might >undertake such a conspiracy in order to fool the DPD server >into attesting to incorrect (or at least out-of-date) certificate >status, with a view toward later presenting this incorrect >attestation to someone else. (If the DPD response is timestamped, >then all the response data, including the incorrect revocation >data, will have been signed as part of the timestamp.) > >An alternative would be for the DPD server to generate its own >nonces, and then simply attest to the DPD client that all the OCSP >responses returned in the DPD response are fresh. But this calls >for some amount of trust in the DPD server, and part of the >premise for DPD (as opposed to DPV) was that the client might not >trust the server. Interesting point re a DPD server returning OCSPv1 responses. i didn't think about that in detail! I'll have to think more about that case. Steve --============_-1233502899==_ma============ Content-Type: text/enriched; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At 5:21 PM -0800 1/3/01, Covey, Carlin wrote: Arial0000,0000,FFFFTo thwart replay attacks, both OCSP and SCVP have provisions for the optional inclusion of nonces in requests and responses . =20 The premise of this is that the requester picks a nonce that it hasn't used before, and includes it in its request. The server is obligated to return this same nonce, ensuring that the response was prepared after the request. =20 I don't see a provision in the proposed DPD and DPV requirements for the optional inclusion of a nonce. Is this an intentional omission, or inadvertent? Do we want/need nonces in the new DPD/DPV standards? Arial0000,0000,FFFF I didn't want to mandate the use of nonces per se. However, the security requirement that nonces address is covered in 1.8: 1Times.8 Either the request/response protocol itself, or a specified lower layer protocol to be employed for requests and responses, there must be a provision for data origin authentication and connectionless integrity for requests and responses, and responses must be matched to requests. Request authentication & integrity is needed to support access control to the server, a requirement for public servers. Responses must be authenticated and integrity-protected to ensure that they are from the indicated server, and matched to the request in question. Additional security services may be offered optionally. =20 Arial0000,0000,FFFFI won't venture an opinion, but I will make some observations. Since nonces are permitted in OCSP v1 responses, nonces may appear in OCSP responses embedded in the requests sent to the DPD or DPV server.=20 "1.2 A client request can contain one or more revocation data items,=20 to assist the server in path validation." - from proposed DPD & DPV requirements 0000,0000,FFFFThe nonces in the OCSP responses will be of no use to the server, because the server did not generate the OCSP requests with the matching nonces. =20 =20 Likewise, the responses that a DPD server returns may contain OCSP responses with nonces. (To thwart replay attacks, the DPD server may have put nonces in the requests that it made to OCSP servers.)=20 "2.2 A server must be able to return one or more sets of certification paths and associated=20 revocation data as a result of path discovery/validation. Each set shall consist of an ordered=20 list of certificates and associated CRLs and/or OCSP responses." - from proposed DPD & DPV requirements 0000,0000,FFFFThese nonces will be useful to the DPD server, but not to the DPD client, since the client did not generate the matching OCSP requests. UNLESS ....... the DPD server chooses the same nonce that it received from the DPD client. (Contemplating this makes me queasy.) Recall that the protection against replay attacks was based upon the requester not using the same nonce it had used before. This can be done cheaply by generating the nonces as a sequence, or as a sizable random number. But if the DPD server doesn't generate the nonce, then it must keep a record of all the nonces that it has seen (well, perhaps only those it has seen within some global time-ambiguity interval).=20 =46ailing to keep track of past nonces renders the DPD server vulnerable to conspiracies between the DPD client and another agent replaying older OCSP responses to the DPD server. But why would a DPD client conspire against itself? It might undertake such a conspiracy in order to fool the DPD server into attesting to incorrect (or at least out-of-date) certificate status, with a view toward later presenting this incorrect attestation to someone else. (If the DPD response is timestamped, then all the response data, including the incorrect revocation data, will have been signed as part of the timestamp.) An alternative would be for the DPD server to generate its own nonces, and then simply attest to the DPD client that all the OCSP responses returned in the DPD response are fresh. But this calls for some amount of trust in the DPD server, and part of the premise for DPD (as opposed to DPV) was that the client might not trust the server. Arial0000,0000,FFFF Interesting point re a DPD server returning OCSPv1 responses. i didn't think about that in detail! I'll have to think more about that case. Steve --============_-1233502899==_ma============-- From owner-ietf-pkix Thu Jan 4 07:01:18 2001 Received: from web221.mail.yahoo.com (web221.mail.yahoo.com [128.11.68.121]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA12852 for ; Thu, 4 Jan 2001 07:01:17 -0800 (PST) Message-ID: <20010104150549.7851.qmail@web221.mail.yahoo.com> Received: from [216.144.146.62] by web221.mail.yahoo.com; Thu, 04 Jan 2001 07:05:49 PST Date: Thu, 4 Jan 2001 07:05:49 -0800 (PST) From: julie whitfield Subject: REMOVE To: "'PKIX-List'" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii ===== Happy Holidays! Ho, ho, ho!!!! Love, Julie "Courage is resistance to fear, mastery of fear - not absence of fear." Mark Twain (1835 - 1910) __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ From owner-ietf-pkix Thu Jan 4 08:23:02 2001 Received: from exchange.cylink.com (exchange.cylink.com [192.43.161.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21713 for ; Thu, 4 Jan 2001 08:23:02 -0800 (PST) Received: by exchange.cylink.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 08:19:59 -0800 Message-ID: <1BE57AA01A5ED411866500B0D049657B42A5BB@exchange.cylink.com> From: "Covey, Carlin" To: PKIX-List Subject: RE: DPD & DPV requirements - Let us Recurse Date: Thu, 4 Jan 2001 08:19:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0766A.2EA685D0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0766A.2EA685D0 Content-Type: text/plain; charset="iso-8859-1" Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD proposal all permit OCSP responses to be returned to the client as revocation status data. Presumably in each case this refers to OCSP v1 basic responses, at least. This is all well and good, but would it not be desirable to also permit recursion in the DPD response? That is, the DPD response might include an embedded DPD response from another server. Among other benefits, this would preserve the timestamp (if any) on the embedded DPD response. - Regards Carlin Covey Cylink Corp. ------_=_NextPart_001_01C0766A.2EA685D0 Content-Type: text/html; charset="iso-8859-1"
Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD proposal all permit OCSP responses
to be returned to the client as revocation status data.  Presumably in each case this refers to OCSP v1 basic responses,
at least.  This is all well and good, but would it not be desirable to also permit recursion in the DPD response?  That is, the DPD
response might include an embedded DPD response from another server.  Among other benefits, this would preserve the
timestamp (if any) on the embedded DPD response.
 
- Regards
  Carlin Covey
  Cylink Corp.
------_=_NextPart_001_01C0766A.2EA685D0-- From owner-ietf-pkix Thu Jan 4 12:21:57 2001 Received: from mail.westpac.com.au (mail.westpac.com.au [203.24.6.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA06447 for ; Thu, 4 Jan 2001 12:21:56 -0800 (PST) Received: (from smtpuser@localhost) by mail.westpac.com.au (8.9.1a/8.9.1) id HAA29559 for ; Fri, 5 Jan 2001 07:19:21 +1100 (EST) Message-Id: <200101042019.HAA29559@mail.westpac.com.au> Received: from inetsvr02(10.10.70.26) by xlprod02 via smap (V2.1+anti-relay+anti-spam) id xma029548; Fri, 5 Jan 01 07:19:16 +1100 Received: from inetsrv02.king77.nsw.westpac.com.au (localhost [127.0.0.1]) by inetsrv02.king77.nsw.westpac.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C1A6CV9L; Fri, 5 Jan 2001 07:25:52 +1100 Received: from 10.10.70.19 by inetsrv02.king77.nsw.westpac.com.au (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 07:25:52 +1100 (Syd2000 Daylight Time) Received: by exhub04.king77.nsw.westpac.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 5 Jan 2001 07:25:57 +1100 From: "RANFORD, Cameron" To: "'PKIX-List'" Subject: RE: REMOVE Date: Sat, 6 Jan 2001 02:23:00 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0768C.8ACE3926" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C0768C.8ACE3926 Content-Type: text/plain; charset="windows-1252" -----Original Message----- From: julie whitfield [mailto:jacywhit@yahoo.com] Sent: Thursday, 4 January 2001 7:06 AM To: 'PKIX-List' Subject: REMOVE ===== Happy Holidays! Ho, ho, ho!!!! Love, Julie "Courage is resistance to fear, mastery of fear - not absence of fear." Mark Twain (1835 - 1910) __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ ------_=_NextPart_000_01C0768C.8ACE3926 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IjoUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQALAAAAUkU6IFJFTU9WRQC/AgEJgAEAIQAAADU0NkQ1NzYx N0ZBMkI4NEE4NjQ1Qjk5NzZFOTQ0QTQ3AB8HASCAAwAOAAAA0QcBAAUABwAZADgABQA7AQEFgAMA DgAAANEHAQAGAAIAFwAAAAYA/gABDYAEAAIAAAACAAIAAQOQBgCMBgAAKwAAAAsAAgABAAAAAwAu AAAAAABAADkAELNqYyt3wAEeAHAAAQAAAAcAAABSRU1PVkUAAAIBcQABAAAAGwAAAAHAdmB5YC7s A3jiMxHUiJcAAPa5FFkAMrlBcAACAQkQAQAAAAcCAAADAgAAPwMAAExaRnUp8nPUAwAKAHJjcGcx MjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAG wxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFDzCwkBZDM2FlALpgrjCoTVCoAtHbJPBRBn C4AHQMMF0AeQc2FnZR2zHPSCRgNhOiBqdWwIkDAgd2hpADAIkGxkDCBbAMADEHRvOmoFANB5IHJA eWFob+RvLgWgbV0c9AZgAjAJH/BUaAhwc2RheaAsIDQgSgBwdQrABHkgAdAwMSA3OlQwNhDATRz0 VCFwIIAnUEtJWC1MBADEdCcixXViagWQI1HAUkVNT1ZFHPoc9Bsc5RzrPSqCHPRIYXAqcCSgSAbw aSPRcyHeICuBJAAiQCxiISzhHPqwTG92ZSQAHPRKICKtHPoiCFIe0SAEACAYIDcAkCagAHBjIFAh YCBmfmUKwCQAAMAmoASQJKBvgmYxQyAtIG5vBUBPAaAUEDDiMjUuIhz0TRUKwGsjcHcLcSAoMQg4 MzUyoTE5MTB6KRz6XzbPN9843Rz0RJ0xMFkIYDpgIjIhPxz0eTq0IFAiQCFgBCAysFM7E+EgUHkI YSxxK7MgcKc8BAIgIDBuZS0VaAJAUHA6Ly89tC4iJy8FHPR9QOAAAwD9P1IDAAAeAEIQAQAAADIA AAA8MjAwMTAxMDQxNTA1NDkuNzg1MS5xbWFpbEB3ZWIyMjEubWFpbC55YWhvby5jb20+AAAAAwDe P+QEAAADAAlZAQAAAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwAAgAggBgAAAAAA wAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAMABIAI IAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgAFgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEA AAAEAAAAOS4wAAsAFIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAACwAIgAggBgAAAAAAwAAA AAAAAEYAAAAADoUAAAAAAAADAAmACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMACoAIIAYA AAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAwAmAAAAAAADADYAAAAAAB4AMUABAAAAEAAAAEw4MDA5 NDk4RUQ0QkY4QwADABpAAAAAAB4AMEABAAAAEAAAAEw4MDA5NDk4RUQ0QkY4QwADABlAAAAAAAMA gBD/////AgH5PwEAAABjAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPVdFU1RQQUMv T1U9V0JDL0NOPVJFQ0lQSUVOVFMvQ049TVNNQUlMIEFERFJFU1NFUy9DTj1MODAwOTQ5OEVENEJG OEMAAB4A+D8BAAAAEQAAAFJBTkZPUkQsIENhbWVyb24AAAAAHgA4QAEAAAAQAAAATDgwMDk0OThF RDRCRjhDAAIB+z8BAAAAYwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1XRVNUUEFD L09VPVdCQy9DTj1SRUNJUElFTlRTL0NOPU1TTUFJTCBBRERSRVNTRVMvQ049TDgwMDk0OThFRDRC RjhDAAAeAPo/AQAAABEAAABSQU5GT1JELCBDYW1lcm9uAAAAAB4AOUABAAAAEAAAAEw4MDA5NDk4 RUQ0QkY4QwBAAAcwUOxaXit3wAFAAAgwJjnOiox2wAEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4B AAAABwAAAFJFTU9WRQAACwApAAAAAAALACMAAAAAAAMABhDXqVCbAwAHEDkBAAADABAQAAAAAAMA ERAAAAAAHgAIEAEAAABlAAAALS0tLS1PUklHSU5BTE1FU1NBR0UtLS0tLUZST006SlVMSUVXSElU RklFTERNQUlMVE86SkFDWVdISVRAWUFIT09DT01TRU5UOlRIVVJTREFZLDRKQU5VQVJZMjAwMTc6 MDZBTQAAAACDXw== ------_=_NextPart_000_01C0768C.8ACE3926-- From owner-ietf-pkix Thu Jan 4 12:48:04 2001 Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08467 for ; Thu, 4 Jan 2001 12:48:03 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id VAA29025 for ; Thu, 4 Jan 2001 21:52:35 +0100 (CET) Received: from mega (t7o69p155.telia.com [213.65.46.155]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f04KqYl13441 for ; Thu, 4 Jan 2001 21:52:34 +0100 (CET) Message-ID: <015901c07690$0c24f250$0201a8c0@vincent.se> From: "Anders Rundgren" To: "PKIX-List" Subject: Basic Cert-2-Directory mapping question Date: Thu, 4 Jan 2001 21:51:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA08470 Basic question from an RDBMS-hack. Assume you have a directory structure like /O=Internet/DC=COM/DC=Acme/CN=Users/CN=James A Smith Now you have a [probably TTP-issued] certificate for this person with a DN CN=James Adrian Smith + SN=343434 How do you map/match such a "alien" certificate in an efficient and easy-to-adminster way using directory technology? The solution should support many-to-one mappings of certificates-to-individuals. To make it simple, ignore the issuer part. To reduce load on the PKIX-list you may mail me directly. Anders From owner-ietf-pkix Thu Jan 4 13:23:25 2001 Received: from mail.westpac.com.au (mail.westpac.com.au [203.24.6.110]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10957 for ; Thu, 4 Jan 2001 13:23:24 -0800 (PST) Received: (from smtpuser@localhost) by mail.westpac.com.au (8.9.1a/8.9.1) id IAA08303 for ; Fri, 5 Jan 2001 08:20:50 +1100 (EST) Message-Id: <200101042120.IAA08303@mail.westpac.com.au> Received: from inetsvr02(10.10.70.26) by xlprod02 via smap (V2.1+anti-relay+anti-spam) id xma008253; Fri, 5 Jan 01 08:20:36 +1100 Received: from inetsrv02.king77.nsw.westpac.com.au (localhost [127.0.0.1]) by inetsrv02.king77.nsw.westpac.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C1A6CX9L; Fri, 5 Jan 2001 08:27:13 +1100 Received: from 10.10.70.19 by inetsrv02.king77.nsw.westpac.com.au (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 08:27:11 +1100 (Syd2000 Daylight Time) Received: by exhub04.king77.nsw.westpac.com.au with Internet Mail Service (5.5.2448.0) id ; Fri, 5 Jan 2001 08:27:16 +1100 From: "RANFORD, Cameron" To: "RANFORD, Cameron" , "'PKIX-List'" Subject: REMOVE Date: Sat, 6 Jan 2001 03:24:54 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C07695.1C335B0A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C07695.1C335B0A Content-Type: text/plain; charset="windows-1252" this is it! ------_=_NextPart_000_01C07695.1C335B0A Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhEVAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAHAAAAUkVNT1ZFAM4BAQmAAQAhAAAAQjE4OERFMTQzRDYy QkE0NzlBOUE5QjA0OERCNTkyQUMAUwcBIIADAA4AAADRBwEABQAIABsAEAAFABYBAQWAAwAOAAAA 0QcBAAYAAwAYADYABgA2AQENgAQAAgAAAAIAAgABA5AGALAEAAArAAAACwACAAEAAAADAC4AAAAA AEAAOQBgiTEJNHfAAR4AcAABAAAABwAAAFJFTU9WRQAAAgFxAAEAAAAbAAAAAcB2jaGkUl7wH+J7 EdSIlwAA9rkUWQApl/NQAAIBCRABAAAAkwAAAI8AAAAeAQAATFpGdUZclG4DAAoAcmNwZzEyNeIy A0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2 MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUPMLCQFkMzYWUAumCuMKgJR0aAQAIB1ydCEc9AUc 9H0e0AADAP0/UgMAAB4AQhABAAAALAAAADwyMDAxMDEwNDIwMTkuSEFBMjk1NTlAbWFpbC53ZXN0 cGFjLmNvbS5hdT4AAwDeP+QEAAADAAlZAQAAAAsAA4AIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAA AAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAA AAABhQAAAAAAAAMABIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAB9bgEAHgAFgAggBgAAAAAAwAAA AAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAFIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA CwAIgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAmACCAGAAAAAADAAAAAAAAARgAAAAAR hQAAAAAAAAMACoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAAwAmAAAAAAADADYAAAAAAB4A MUABAAAAEAAAAEw4MDA5NDk4RUQ0QkY4QwADABpAAAAAAB4AMEABAAAAEAAAAEw4MDA5NDk4RUQ0 QkY4QwADABlAAAAAAAMAgBD/////AgH5PwEAAABjAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA BgAAAC9PPVdFU1RQQUMvT1U9V0JDL0NOPVJFQ0lQSUVOVFMvQ049TVNNQUlMIEFERFJFU1NFUy9D Tj1MODAwOTQ5OEVENEJGOEMAAB4A+D8BAAAAEQAAAFJBTkZPUkQsIENhbWVyb24AAAAAHgA4QAEA AAAQAAAATDgwMDk0OThFRDRCRjhDAAIB+z8BAAAAYwAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAA AAYAAAAvTz1XRVNUUEFDL09VPVdCQy9DTj1SRUNJUElFTlRTL0NOPU1TTUFJTCBBRERSRVNTRVMv Q049TDgwMDk0OThFRDRCRjhDAAAeAPo/AQAAABEAAABSQU5GT1JELCBDYW1lcm9uAAAAAB4AOUAB AAAAEAAAAEw4MDA5NDk4RUQ0QkY4QwBAAAcwkJJzATR3wAFAAAgwClszHJV2wAEeAD0AAQAAAAEA AAAAAAAAHgAdDgEAAAAHAAAAUkVNT1ZFAAALACkAAAAAAAsAIwAAAAAAAwAGEGLONzQDAAcQCAAA AAMAEBAAAAAAAwAREAEAAAAeAAgQAQAAAAkAAABUSElTSVNJVAAAAAD0yw== ------_=_NextPart_000_01C07695.1C335B0A-- From owner-ietf-pkix Thu Jan 4 13:26:12 2001 Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11173 for ; Thu, 4 Jan 2001 13:26:12 -0800 (PST) Received: from postal-gw2.verisign.com (verisign.com [63.104.27.102]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id NAA03588 for ; Thu, 4 Jan 2001 13:32:33 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Thu, 4 Jan 2001 13:30:45 -0800 Message-ID: From: Ram Austryjak Moskovitz To: "'RANFORD, Cameron'" , "'PKIX-List'" Subject: RE: REMOVE Date: Thu, 4 Jan 2001 13:30:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Not likely :-) -----Original Message----- From: RANFORD, Cameron [mailto:CRANFORD@westpac.com.au] Sent: Friday, January 05, 2001 8:25 AM To: RANFORD, Cameron; 'PKIX-List' Subject: REMOVE this is it! From owner-ietf-pkix Thu Jan 4 14:27:38 2001 Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14366 for ; Thu, 4 Jan 2001 14:27:38 -0800 (PST) Received: from phaos_arik (ruskie.spacerat.com [207.51.38.135]) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id VAA37390 for ; Thu, 4 Jan 2001 21:33:25 -0500 (EST) (envelope-from arik@phaos.com) Message-Id: <4.2.0.58.20010104173909.00c00140@mail.phaos.com> X-Sender: arik@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 04 Jan 2001 17:42:53 -0500 To: ietf-pkix@imc.org From: Ari Kermaier Subject: draft-ietf-pkix-rfc2510bis-02 syntax question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed An inconsistency between the text and the ASN.1 module: 3.3.18 Certificate Confirmation content CertStatus ::= SEQUENCE { certHash OCTET STRING, -- the hash of the certificate, using the same hash algorithm -- as is used to create and verify the certificate signature certReqId INTEGER, -- to match this confirmation with the corresponding req/rep statusInfo PKIStatusInfo OPTIONAL } Appendix F: "Compilable" ASN.1 Module using 1988 Syntax CertStatus ::= SEQUENCE { certHash OCTET STRING, -- the hash of the certificate, using the same hash algorithm -- as is used to create and verify the certificate signature statusInfo PKIStatusInfo OPTIONAL } Any clarification would be appreciated. Ari Kermaier Phaos Technology From owner-ietf-pkix Thu Jan 4 22:37:16 2001 Received: from c1mailgw06.prontomail.com (mailgw.prontomail.com [216.163.184.10] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA24485 for ; Thu, 4 Jan 2001 22:37:16 -0800 (PST) From: nag_amani@indya.com Received: from c1web109 (216.163.184.10) by c1mailgw06.prontomail.com (NPlex 5.1.050) id 3A413A6E001D289E for ietf-pkix@imc.org; Thu, 4 Jan 2001 22:41:20 -0800 X-Version: indya 6.3.2329.0 Message-Id: Date: Fri, 5 Jan 2001 12:10:25 +0530 X-Priority: Normal Content-Type: text/plain; charset=iso-8859-1 To: ietf-pkix@imc.org X-Mailer: Web Based Pronto Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Hi! I want to include secrity in my work using shttp.So to do the same is it necessary to get a certificate issued from Verisign.What r the other options to do & which is the best method encryption or signature.Various steps to be followed.If at all i have to fill up any forms where will i get them.Please give the exact website to follow the things. Regds Nagamani. U can mail me either to nag_amani@indya.com OR nagamani_npurohit@usa.net. Enjoy being an Indyan at http://www.indya.com From owner-ietf-pkix Fri Jan 5 06:27:14 2001 Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14051 for ; Fri, 5 Jan 2001 06:27:13 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA22966; Fri, 5 Jan 2001 15:31:48 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 5 Jan 2001 15:31:48 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA13530; Fri, 5 Jan 2001 15:31:46 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA15535; Fri, 5 Jan 2001 15:31:46 +0100 (MET) Date: Fri, 5 Jan 2001 15:31:46 +0100 (MET) Message-Id: <200101051431.PAA15535@emeriau.edelweb.fr> To: ietf-pkix@imc.org, ccovey@cylink.com Subject: RE: DPD & DPV requirements - Let us Recurse > > Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD > proposal all permit OCSP responses > to be returned to the client as revocation status data. Presumably in each > case this refers to OCSP v1 basic responses, > at least. This is all well and good, but would it not be desirable to also > permit recursion in the DPD response? That is, the DPD > response might include an embedded DPD response from another server. Among > other benefits, this would preserve the > timestamp (if any) on the embedded DPD response. > I have some feeling that handling DPV and DPD at the same time is not an extremely good thing, there may be well some requirements that apply for both, in this case I think that these are general requirements for almost any secure protocol. Furthermore DPV and DPD seem to be at different (sub)layers, e.g.., a DPV layer could run a loop towards a DPD server. The text mentions several usage environments, public, private and heterogeneous. There was a question recently about OCSP mentioning a similar issue: A DPV server in any environment should be able to delegate part of the service to another server, it should be possible that the response delivered to the client include the response of the delegated/relayed request, and all elements that can be used to determine the authenticity of the response, e.g., signatures from the primary server (as a coutersignature or as a parallel signature), It has been mentioned that the response is to be time stamped and used in order to validate a long term document etc. It seems important to me that the client can use the response not only to make a decision, but also to have all information about why this decision had been made. Thus, a client can create a statement saying: " I accept this certificate because my server told me that it is good, and he provides the following justifications: ..." instead of: " I accept this certificate because my server told me that it is good, if you want to know wy, go ask elsewhere" (how?). In some contexts this is related to relaying: A company server tells that a cert is good because a request to a remote server (from another company or elsewhere) has been made, i.e.: the response says something like: "We, the humble XXX compnay server think that the certificate CCC is good because we have this validity statement from XYZZY according to policy PPP...". PS From owner-ietf-pkix Fri Jan 5 10:13:59 2001 Received: from web3706.mail.yahoo.com (web3706.mail.yahoo.com [204.71.203.135]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA29331 for ; Fri, 5 Jan 2001 10:13:59 -0800 (PST) Message-ID: <20010105181826.2862.qmail@web3706.mail.yahoo.com> Received: from [32.102.78.253] by web3706.mail.yahoo.com; Fri, 05 Jan 2001 10:18:26 PST Date: Fri, 5 Jan 2001 10:18:26 -0800 (PST) From: Timothy Fisher Subject: pkix servers To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Does anyone know if there are any publicly available PKIX servers available for testing PKIX-CMP messages? Sincerely, Timothy Fisher PricewaterhouseCoopers From owner-ietf-pkix Fri Jan 5 10:31:28 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01940 for ; Fri, 5 Jan 2001 10:31:28 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA24796; Fri, 5 Jan 2001 13:36:04 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <1BE57AA01A5ED411866500B0D049657B42A5BB@exchange.cylink.com> References: <1BE57AA01A5ED411866500B0D049657B42A5BB@exchange.cylink.com> Date: Fri, 5 Jan 2001 13:32:08 -0500 To: "Covey, Carlin" From: Stephen Kent Subject: RE: DPD & DPV requirements - Let us Recurse Cc: PKIX-List Content-Type: multipart/alternative; boundary="============_-1233402667==_ma============" --============_-1233402667==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Carlin, >Steve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP >DPD proposal all permit OCSP responses >to be returned to the client as revocation status data. Presumably >in each case this refers to OCSP v1 basic responses, >at least. This is all well and good, but would it not be desirable >to also permit recursion in the DPD response? That is, the DPD >response might include an embedded DPD response from another server. >Among other benefits, this would preserve the >timestamp (if any) on the embedded DPD response. > >- Regards > Carlin Covey > Cylink Corp. Recursion has its attractions, but nested responses seem complex, syntactically if not semantically. Given the issues you raised about the 1 level of indirection posed by a DPD or DPV server interacting with an OCSP server, I am not yet comfortable with making life more complex in this regard. First I think we need to solve the problem you identified, and then we can see if that solution will generalize to allow the recursion to work smoothly and in a readily understandable manner. Steve --============_-1233402667==_ma============ Content-Type: text/enriched; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Carlin, Arial0000,0000,FFFFSteve Kent's DPD/DPV requirements, the SCVP proposal, and the OCSP DPD proposal all permit OCSP responses to be returned to the client as revocation status data. Presumably in each case this refers to OCSP v1 basic responses, at least. This is all well and good, but would it not be desirable to also permit recursion in the DPD response? That is, the DPD response might include an embedded DPD response from another server.=20 Among other benefits, this would preserve the timestamp (if any) on the embedded DPD response. =20 - Regards Carlin Covey Cylink Corp. Arial0000,0000,FFFF Recursion has its attractions, but nested responses seem complex, syntactically if not semantically. Given the issues you raised about the 1 level of indirection posed by a DPD or DPV server interacting with an OCSP server, I am not yet comfortable with making life more complex in this regard. First I think we need to solve the problem you identified, and then we can see if that solution will generalize to allow the recursion to work smoothly and in a readily understandable manner. Steve --============_-1233402667==_ma============-- From owner-ietf-pkix Fri Jan 5 10:31:34 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA01989 for ; Fri, 5 Jan 2001 10:31:34 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA24785; Fri, 5 Jan 2001 13:35:57 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200101051431.PAA15535@emeriau.edelweb.fr> References: <200101051431.PAA15535@emeriau.edelweb.fr> Date: Fri, 5 Jan 2001 13:29:02 -0500 To: Peter Sylvester From: Stephen Kent Subject: RE: DPD & DPV requirements - Let us Recurse Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Peter, I am open to the suggestion that we further separate DPV vs. DPD requirements, to make each clearer, although my impressions, after some thinking, are that these two types of servers are more alike than I had originally imagined. Returning info that explains why a server believes that the returned data supports validation is an interesting notion. The first example of that I saw was in work performed by colleagues here at BBN, on a project calls IOS, in the early 90s, where servers did that. But, I think this is still an R&D topic for now, not yet ready for standardization. Steve From owner-ietf-pkix Fri Jan 5 13:10:59 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11518 for ; Fri, 5 Jan 2001 13:10:58 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id QAA17480; Fri, 5 Jan 2001 16:15:33 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A51B25D.A449FC37@bull.net> References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> <004401c06739$f7b9f550$0201a8c0@vincent.se> <3A51B25D.A449FC37@bull.net> Date: Fri, 5 Jan 2001 16:10:33 -0500 To: Denis Pinkas From: Stephen Kent Subject: Re: DPD & DPV requirements Cc: PKIX-List Content-Type: multipart/alternative; boundary="============_-1233393097==_ma============" --============_-1233393097==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Denis, >Steve, > >First of all, many thanks for posting this long document. > >I will not respond using directly your text, since my arguments >are fairly different. I will however re-use some of your arguments. > >Let us use the concept of "validation policy", that you introduce, which is >all the set of rules to be followed when validating a certificate. It will >usually not simply be the rules mentioned in RFC 2459, but these rules with >additional conditions. Note that in the context of electronic signatures, a >"signature policy" is a specific example of a "validation policy". We need to be explicit about what are the parameters that control=20 path validation. The 2459 validation algorithm has a well-defined=20 set, but if there are others, we need to have them specified and=20 agreed upon. One conversation that took place in San Diego noted that=20 one could imagine a lot of parameters that a user might want to=20 express re path validation, but which have not been standardized, and=20 for which we do not have general agreement. A very rich list of this=20 sort, and the associated complexity that would accompany an enhanced=20 validation algorithm that used thise parameters, was thought to be=20 out of scope for now, more an R&D topic vs. a topic for=20 standardization. So we have to be careful here. >DPV >=3D=3D=3D > >Let us start with DPV first. A DPV client will not necessarily be either >PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol: > >=20 1) one not using ASN.1 (e.g. using XML), >=20 2) one using ASN.1. > >In both cases the client only supplies an unambiguous reference of the >certificate (CA name, serial number and a hash of the certificate) or the >certificate itself and specifies the rules to be followed to validate the >certificate: an identification of a pre-defined "validation policy" (e.g. a= n >OID and/or a URL to find the policy and a hash of that validation policy). Given the problems we have had in OCSP (v1) re referring to a target=20 cert, I am not comfortable specifying a target cert other than by=20 providing a copy of that cert to the server. >As a result, the client expects a signed response which reproduces the >requested parameters and includes a status. The status is not simply: >"passed validation", "failed validation", or "don't' know" but can also be >"incomplete validation", meaning that some revocation status information is >not yet available at the time of processing and a later attempt might >succeed. Incomplete validation is a reasonable response. maybe we should=20 include the set of parameters used for the validation, including ones=20 not supplied by the client, e.g., defaults, or overrides imposed by=20 the server, or the values bound to a policy that was specified. >The response must include the time at which the validation has been >performed. Allowing to test a certificate "in the past", would place some >requirements that cannot always be accomplished by a standard PKI: currentl= y >we do not mandate CAs to maintain revocation information beyond the end of >the validity period of a certificate. We should not change that rule. So I >am very reluctant to autorise validation in the past, e.g. 10 years later. Good points; we should include the time of the response. I added the=20 "in the past" requirement based on its inclusion in SCVP, but there=20 clearly limits to one's ability to support that feature. However, if=20 the server is uable to verify a cert relative to a prior time, based=20 on unavailability of some revocation data, it can always state that=20 in a response. One might add a requirement to allow the server to be=20 configured to reject requests for validation that cite a time/date=20 prior to some confugured value. >If a client is interested in a later proof, then it should obtain that >information from the server at the time the information is still available. >This means that a client should have the possibility to ask the server to >optionally return an opaque blob that contains all what has been used to >validate the certificate (i.e. a certification path and all the CRLs or >OCSPs needed for each certificate from the path). =20 We have this requirement already, with a time stamp option. >A question arises from the requirements 1.5 and 1.6 that you listed: should >that opaque blob be time-stamped ? If there is a fear that some of the >issuing keys used in the certification path might later on be compromised, >then this can be useful. This case should be very seldom and hence this >service would not always be required. In addition, why should that service >be embedded in this protocol ? This could be obtained using directly the >TSP, leaving more possibilities: free choice of the TSAs, time stamp of the >full blob, time stamp of the certification chain only, time stamp on both >the certification chain and the revocation information. Thus I do not favor >to piggy-back the two services. Yes, one could keep the services separate. I am not hard over on=20 this, and can be persuaded to remove the requirement, or to make=20 server support for it optional. >In order to simplify the protocol and allow for PKI-ignorant clients, the >client should NOT be allowed to provide any other element than the >certificate, that might help to construct the path or the revocation >information. I don't see the rationale for this. We already have application=20 protocols where a client that is not PKI-aware might acquire cert=20 paths and/or revocation data that it could pass on to a DPV server.=20 So, I don't think you have made a good argument here for not allowing=20 such data to be transmitted. Also, I don't think we have agreement=20 yet that we are supporting clients that are not PKI-aware. I merely=20 noted that IF we choose to support such clients, then there are=20 implications for the syntax used for the protocol, and for the=20 semantics of what is transmitted. I don't think we have made the next=20 step to agree to support such clients. >This means that, not only I do not agree with a common list of requirements >for both DPV and DPD, but also that I do not agree with many of the >requirements that you listed: > >For a DPV client: > >1.1. Only a single certificate should be allowed. >1.2. No revocation items should be allowed. >1.3. No request in the past should be allowed. >1.4. Imposing constraints for CRLs or OCSP responses should be hidden >=20 under the "validation policy" that is selected. >1.5. and 1.6. Time stamped responses, if needed, should not be part of the >=20 service. >1.7. Validation policies are not necessarily "configured at the server", >=20 but can simply be pre-defined, outside the server. I any case, the >=20 rules that has been followed - i.e. "validation policy" - must be >=20 indicated in the response. >1.8. For DPV, responses must be signed. >1.9. The policy ID format can/will be specified in the protocol. > >For a DPV server: > >2.1. A DPV server, will have to do more than RFC 2459, hence why the use >=20 of a validation policy is needed. >2.2. An opaque blob MAY be returned. >2.3. Time stamping is not needed. >2.4. The concept of policy overriding is too complex: a reference to >=20 a validation policy is sufficient. >2.5. No comment. >2.6. A server must support LDAP for certificate fetching, and EITHER CRL >=20 fetching OR OSCP (OCSP should not be mandatory). >2.7. No comment. > Given that we no longer agree on the underlying assumptions, it=20 probably is not worthwhile discussing each of your proposed changes=20 above. >DPD >=3D=3D=3D > >Let us continue with DPD. I agree in general with many of the requirements >that you listed in that case. In particular, since a DPD client must be bot= h >PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1. > >The major difference with the previous protocol is that no evaluation of th= e >returned chain needs to be done, since the client is supposed to be able to >perform all the checks himself. Therefor no validation status is returned b= y >the server. I don't think I agree with both of the statements above. No explicit=20 validation status is returned, but I do think the server is=20 performing validation so that only valid chains are returned. >The service is more a single place for shopping all (?) the needed >certificates and revocation status information. > >In the request, the client could either specify a validation policy or the >trusted points with, for each level of the chain, the indication whether >CRLs or OCSP responses are requested. > >One or more chains, corresponding to the request may be obtained. > >The response does not need to be signed, but only protected by a combined >integrity and data origin authentication service. > > >CONCLUSION >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >We could support three protocols: > >=20 1=B0 DPV in XML, >=20 2=B0 DPV in ASN.1, >=20 3=B0 DPD in ASN.1. The operative term here is "could." Also, DPV in XML and DPV in ASN.1=20 need not be the same protocol, because of different assumptions about=20 the clients. So I think of it three protocols where 2 & 3 may be very=20 similar, but 1 is quite different. >ADDITIONAL QUESTION >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >For the two protocols in ASN.1, should these two protocols be piggy-back on >OCSP ? That's one of the proposals, but the answer should be the result of=20 analysis of a revised proposal consistent with the requirements that=20 we adopt. >Before going at the technical details, it is important to raise the >following question: which combination(s) of the three basic requests (OCSP, >DPV and DPD) could make sense ? > >If a client requests DPV, then it does not care about OCSP and neither on >DPD (multiple certification chains to be tested). >For a PKI-aware client, only OCSP + DPD makes sense. > >This means that : > >=20 1) DPV does not need to be supported by OCSP. >=20 2) The only protocol to be piggy-backed to OCSP would be DPD. I don't understand these comments. You need to provide more substantiation. Steve --============_-1233393097==_ma============ Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Denis, Steve, =46irst of all, many thanks for posting this long document. I will not respond using directly your text, since my arguments are fairly different. I will however re-use some of your arguments. Let us use the concept of "validation policy", that you introduce, which is all the set of rules to be followed when validating a certificate. It will usually not simply be the rules mentioned in RFC 2459, but these rules with additional conditions. Note that in the context of electronic signatures, a "signature policy" is a specific example of a "validation policy". We need to be explicit about what are the parameters that control path validation. The 2459 validation algorithm has a well-defined set, but if there are others, we need to have them specified and agreed upon. One conversation that took place in San Diego noted that one could imagine a lot of parameters that a user might want to express re path validation, but which have not been standardized, and for which we do not have general agreement. A very rich list of this sort, and the associated complexity that would accompany an enhanced validation algorithm that used thise parameters, was thought to be out of scope for now, more an R&D topic vs. a topic for standardization. So we have to be careful here. DPV =3D=3D=3D Let us start with DPV first. A DPV client will not necessarily be either PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol: 1) one not using ASN.1 (e.g. using XML), 2) one using ASN.1. In both cases the client only supplies an unambiguous reference of the certificate (CA name, serial number and a hash of the certificate) or the certificate itself and specifies the rules to be followed to validate the certificate: an identification of a pre-defined "validation policy" (e.g. an OID and/or a URL to find the policy and a hash of that validation policy). Given the problems we have had in OCSP (v1) re referring to a target cert, I am not comfortable specifying a target cert other than by providing a copy of that cert to the server. As a result, the client expects a signed response which reproduces the requested parameters and includes a status. The status is not simply: "passed validation", "failed validation", or "don't' know" but can also be "incomplete validation", meaning that some revocation status information is not yet available at the time of processing and a later attempt might succeed. Incomplete validation is a reasonable response. maybe we should include the set of parameters used for the validation, including ones not supplied by the client, e.g., defaults, or overrides imposed by the server, or the values bound to a policy that was specified. The response must include the time at which the validation has been performed. Allowing to test a certificate "in the past", would place some requirements that cannot always be accomplished by a standard PKI: currently we do not mandate CAs to maintain revocation information beyond the end of the validity period of a certificate. We should not change that rule. So I am very reluctant to autorise validation in the past, e.g. 10 years later. Good points; we should include the time of the response. I added the "in the past" requirement based on its inclusion in SCVP, but there clearly limits to one's ability to support that feature. However, if the server is uable to verify a cert relative to a prior time, based on unavailability of some revocation data, it can always state that in a response. One might add a requirement to allow the server to be configured to reject requests for validation that cite a time/date prior to some confugured value. If a client is interested in a later proof, then it should obtain that information from the server at the time the information is still available. This means that a client should have the possibility to ask the server to optionally return an opaque blob that contains all what has been used to validate the certificate (i.e. a certification path and all the CRLs or OCSPs needed for each certificate from the path). We have this requirement already, with a time stamp option. A question arises from the requirements 1.5 and 1.6 that you listed: should that opaque blob be time-stamped ? If there is a fear that some of the issuing keys used in the certification path might later on be compromised, then this can be useful. This case should be very seldom and hence this service would not always be required. In addition, why should that service be embedded in this protocol ? This could be obtained using directly the TSP, leaving more possibilities: free choice of the TSAs, time stamp of the full blob, time stamp of the certification chain only, time stamp on both the certification chain and the revocation information. Thus I do not favor to piggy-back the two services. Yes, one could keep the services separate. I am not hard over on this, and can be persuaded to remove the requirement, or to make server support for it optional. In order to simplify the protocol and allow for PKI-ignorant clients, the client should NOT be allowed to provide any other element than the certificate, that might help to construct the path or the revocation information. I don't see the rationale for this. We already have application protocols where a client that is not PKI-aware might acquire cert paths and/or revocation data that it could pass on to a DPV server. So, I don't think you have made a good argument here for not allowing such data to be transmitted. Also, I don't think we have agreement yet that we are supporting clients that are not PKI-aware. I merely noted that IF we choose to support such clients, then there are implications for the syntax used for the protocol, and for the semantics of what is transmitted. I don't think we have made the next step to agree to support such clients. =20 This means that, not only I do not agree with a common list of requirements for both DPV and DPD, but also that I do not agree with many of the requirements that you listed: =46or a DPV client:=20 1.1. Only a single certificate should be allowed. 1.2. No revocation items should be allowed. 1.3. No request in the past should be allowed. 1.4. Imposing constraints for CRLs or OCSP responses should be hidden=20 under the "validation policy" that is selected. 1.5. and 1.6. Time stamped responses, if needed, should not be part of the service.=20 1.7. Validation policies are not necessarily "configured at the server",=20 but can simply be pre-defined, outside the server. I any case, the rules that has been followed - i.e. "validation policy" - must be indicated in the response. 1.8. For DPV, responses must be signed. 1.9. The policy ID format can/will be specified in the protocol. =46or a DPV server: 2.1. A DPV server, will have to do more than RFC 2459, hence why the use=20 of a validation policy is needed. 2.2. An opaque blob MAY be returned. 2.3. Time stamping is not needed. 2.4. The concept of policy overriding is too complex: a reference to=20 a validation policy is sufficient.=20 2.5. No comment. 2.6. A server must support LDAP for certificate fetching, and EITHER CRL fetching OR OSCP (OCSP should not be mandatory). 2.7. No comment. Given that we no longer agree on the underlying assumptions, it probably is not worthwhile discussing each of your proposed changes above. DPD =3D=3D=3D Let us continue with DPD. I agree in general with many of the requirements that you listed in that case. In particular, since a DPD client must be both PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1. The major difference with the previous protocol is that no evaluation of the returned chain needs to be done, since the client is supposed to be able to perform all the checks himself. Therefor no validation status is returned by the server. I don't think I agree with both of the statements above. No explicit validation status is returned, but I do think the server is performing validation so that only valid chains are returned. The service is more a single place for shopping all (?) the needed certificates and revocation status information. In the request, the client could either specify a validation policy or the trusted points with, for each level of the chain, the indication whether CRLs or OCSP responses are requested. One or more chains, corresponding to the request may be obtained.=20 The response does not need to be signed, but only protected by a combined integrity and data origin authentication service. CONCLUSION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We could support three protocols: 1=B0 DPV in XML, 2=B0 DPV in ASN.1, 3=B0 DPD in ASN.1. The operative term here is "could." Also, DPV in XML and DPV in ASN.1 need not be the same protocol, because of different assumptions about the clients. So I think of it three protocols where 2 & 3 may be very similar, but 1 is quite different. ADDITIONAL QUESTION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =46or the two protocols in ASN.1, should these two protocols be piggy-back on OCSP ? That's one of the proposals, but the answer should be the result of analysis of a revised proposal consistent with the requirements that we adopt.=20 Before going at the technical details, it is important to raise the following question: which combination(s) of the three basic requests (OCSP, DPV and DPD) could make sense ? If a client requests DPV, then it does not care about OCSP and neither on DPD (multiple certification chains to be tested). For a PKI-aware client, only OCSP + DPD makes sense. This means that : 1) DPV does not need to be supported by OCSP. 2) The only protocol to be piggy-backed to OCSP would be DPD. I don't understand these comments. You need to provide more substantiation. Steve --============_-1233393097==_ma============-- From owner-ietf-pkix Fri Jan 5 17:14:34 2001 Received: from fw. ([203.75.122.253]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA16755 for ; Fri, 5 Jan 2001 17:14:33 -0800 (PST) From: alvin@tainet.net Received: from tw02.tainet.net (unverified [203.75.122.16]) by dnsnet.tainet.net (EMWAC SMTPRS 0.83) with SMTP id ; Sat, 06 Jan 2001 09:22:33 +0800 Received: by tw02.tainet.net(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 482569CC.000780B7 ; Sat, 6 Jan 2001 09:21:57 +0800 X-Lotus-FromDomain: TAINET To: ietf-pkix@imc.org Message-ID: <482569CC.00077FB2.00@tw02.tainet.net> Date: Sat, 6 Jan 2001 09:16:19 +0800 Subject: unsubscribe Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe From owner-ietf-pkix Fri Jan 5 17:27:18 2001 Received: from mail-fwd.verio-web.com (mail11a.verio-web.com [161.58.16.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA16889 for ; Fri, 5 Jan 2001 17:27:18 -0800 (PST) Received: from 161.58.117.181 (161.58.117.181) by mail11a.verio-web.com (RS ver 1.0.57s) with SMTP id 019607417; Fri, 5 Jan 2001 20:25:49 -0500 (EST) Received: from caveosystems.com (adsl-141-154-28-165.bostma.adsl.bellatlantic.net [141.154.28.165]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id UAA25996; Fri, 5 Jan 2001 20:25:56 -0500 Message-ID: <3A5674F8.335BF65F@caveosystems.com> Date: Fri, 05 Jan 2001 20:29:28 -0500 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: PKIX-List Subject: Re: DPD & DPV requirements References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> <004401c06739$f7b9f550$0201a8c0@vincent.se> <3A51B25D.A449FC37@bull.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > Given the problems we have had in OCSP (v1) re referring to a target cert, > I am not comfortable specifying a target cert other than by providing a copy > of that cert to the server. It would be nice if some other folks got their lawyers to check about infringement against that d--n Micali patent I mentioned here some weeks ago. /r$ From owner-ietf-pkix Fri Jan 5 18:10:49 2001 Received: from geos.coastside.net (geos.coastside.net [207.213.212.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17556 for ; Fri, 5 Jan 2001 18:10:48 -0800 (PST) Received: from heatherdale (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.1) with SMTP id f062EvV23257; Fri, 5 Jan 2001 18:14:58 -0800 (PST) From: "Michael Myers" To: "Stephen Kent" , "Peter Sylvester" Cc: Subject: RE: DPD & DPV requirements - Let us Recurse Date: Fri, 5 Jan 2001 18:18:35 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Steve, It is precisely this overlap that led to the existence and architecture of the current DPV and DPD drafts, namely that a DPD server was simply tapping into the path discovery logic that a DPV server must execute. Care must taken however as we go forward with high-level requirements to ensure that a DPD server delivers up that path a DPV server would have used. Or are we otherwise comfortable that some ambiguity may emerge? This was an open question that we as DPV and DPD authors were and are grappling with. Mike -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Friday, January 05, 2001 10:29 AM . . . I am open to the suggestion that we further separate DPV vs. DPD requirements, to make each clearer, although my impressions, after some thinking, are that these two types of servers are more alike than I had originally imagined. From owner-ietf-pkix Fri Jan 5 19:44:47 2001 Received: from heather.ithnet.com (ns.ithnet.com [62.157.157.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA18801 for ; Fri, 5 Jan 2001 19:44:46 -0800 (PST) Received: by heather.ithnet.com (Smail3.2 #4) id m14EkM9-000CMfC; Sat, 6 Jan 2001 04:49:25 +0100 (CET) Received: from gate.ots-erdl.de(62.157.156.209), claiming to be "gate.ots-ag.de" via SMTP by mail2.ithnet.com, id smtpdCBQsxb; Sat Jan 6 04:49:14 2001 Received: from newsletter.com (pC19EB466.dip.t-dialin.net [193.158.180.102]) by gate.ots-ag.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id EAA26752 for ; Sat, 6 Jan 2001 04:48:45 +0100 Date: Sat, 6 Jan 2001 04:48:45 +0100 Message-Id: <200101060348.EAA26752@gate.ots-ag.de> Reply-To: HOP@newsletter.com Content-Type: text/plain; charset=us-ascii X-Priority: 1 From: House Of Pleasure To: ietf-pkix@imc.org Subject: A NEW CYBERPAGE IN SPACE, FUN, FUN, FUN !!! Hello there, there is a very new Website about fun, fun and fun again. The URL is www.h-o-p.de check it out. NOW. Thanx. The webmaster This email was sent via Ellipse Bulk Emailer v2.0 From owner-ietf-pkix Sat Jan 6 00:37:22 2001 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17180 for ; Sat, 6 Jan 2001 00:37:21 -0800 (PST) Received: by ns.celocom.se; id JAA15192; Sat, 6 Jan 2001 09:41:58 +0100 (CET) Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma015188; Sat, 6 Jan 01 09:41:22 +0100 Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id JAA09429; Sat, 6 Jan 2001 09:41:21 +0100 Sender: ricle@celocom.se Message-ID: <3A56D9C6.777B76F0@celocom.se> Date: Sat, 06 Jan 2001 09:39:34 +0100 From: Richard Levitte at Celo Organization: Celo Communications, Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: PKIX-List Subject: Re: Basic Cert-2-Directory mapping question References: <015901c07690$0c24f250$0201a8c0@vincent.se> Content-Type: multipart/mixed; boundary="------------6EE9DA735EFDC58FE31BDC3E" This is a multi-part message in MIME format. --------------6EE9DA735EFDC58FE31BDC3E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If I understand things correctly, you need support for one-to-many of certificate-to-direntry, because CN=James Adrian Smith + SN=343434 would map both to /CN=James Adrian Smith and /SN=343434 If I'm incorrect, I'll gladly be corrected. Anders Rundgren wrote: > > Basic question from an RDBMS-hack. > > Assume you have a directory structure like > > /O=Internet/DC=COM/DC=Acme/CN=Users/CN=James A Smith > > Now you have a [probably TTP-issued] certificate for this person with a DN > > CN=James Adrian Smith + SN=343434 > > How do you map/match such a "alien" certificate in an efficient and easy-to-adminster way > using directory technology? The solution should support many-to-one mappings > of certificates-to-individuals. To make it simple, ignore the issuer part. -- Richard Levitte !!! New cell phone number !!! richard.levitte@celocom.se /* You might enjoy viewing the complete vCard */ --------------6EE9DA735EFDC58FE31BDC3E Content-Type: text/x-vcard; charset=us-ascii; name="richard.levitte.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Levitte at Celo Content-Disposition: attachment; filename="richard.levitte.vcf" begin:vcard n:Levitte;Richard tel;cell:+46-733-72 8811 tel;work:+46-8-58 72 8811 x-mozilla-html:FALSE org:Celo Communications version:2.1 email;internet:richard.levitte@celocom.se title:Software Artist adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN note;quoted-printable:
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
o/~Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
x-mozilla-cpt:;0 fn:Richard Levitte end:vcard --------------6EE9DA735EFDC58FE31BDC3E-- From owner-ietf-pkix Sat Jan 6 00:40:19 2001 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA17727 for ; Sat, 6 Jan 2001 00:40:18 -0800 (PST) Received: by ns.celocom.se; id JAA15220; Sat, 6 Jan 2001 09:44:58 +0100 (CET) Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma015209; Sat, 6 Jan 01 09:44:32 +0100 Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id JAA09457; Sat, 6 Jan 2001 09:44:31 +0100 Sender: ricle@celocom.se Message-ID: <3A56DA86.A5AA171F@celocom.se> Date: Sat, 06 Jan 2001 09:42:46 +0100 From: Richard Levitte at Celo Organization: Celo Communications, Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: PKIX-List Subject: Re: Basic Cert-2-Directory mapping question References: <015901c07690$0c24f250$0201a8c0@vincent.se> Content-Type: multipart/mixed; boundary="------------E7551AC1AED3DDBAB3E04901" This is a multi-part message in MIME format. --------------E7551AC1AED3DDBAB3E04901 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If I understand things correctly, you need support for one-to-many of certificate-to-direntry, because CN=James Adrian Smith + SN=343434 would map both to /CN=James Adrian Smith and /SN=343434 If I'm incorrect, I'll gladly be corrected. Anders Rundgren wrote: > > Basic question from an RDBMS-hack. > > Assume you have a directory structure like > > /O=Internet/DC=COM/DC=Acme/CN=Users/CN=James A Smith > > Now you have a [probably TTP-issued] certificate for this person with a DN > > CN=James Adrian Smith + SN=343434 > > How do you map/match such a "alien" certificate in an efficient and easy-to-adminster way > using directory technology? The solution should support many-to-one mappings > of certificates-to-individuals. To make it simple, ignore the issuer part. -- Richard Levitte !!! New cell phone number !!! richard.levitte@celocom.se /* You might enjoy viewing the complete vCard */ --------------E7551AC1AED3DDBAB3E04901 Content-Type: text/x-vcard; charset=us-ascii; name="richard.levitte.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Levitte at Celo Content-Disposition: attachment; filename="richard.levitte.vcf" begin:vcard n:Levitte;Richard tel;cell:+46-733-72 8811 tel;work:+46-8-58 72 8811 x-mozilla-html:FALSE org:Celo Communications version:2.1 email;internet:richard.levitte@celocom.se title:Software Artist adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN note;quoted-printable:
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
o/~Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
x-mozilla-cpt:;0 fn:Richard Levitte end:vcard --------------E7551AC1AED3DDBAB3E04901-- From owner-ietf-pkix Sat Jan 6 00:53:19 2001 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA20531 for ; Sat, 6 Jan 2001 00:53:18 -0800 (PST) Received: by ns.celocom.se; id JAA15387; Sat, 6 Jan 2001 09:57:58 +0100 (CET) Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma015383; Sat, 6 Jan 01 09:57:17 +0100 Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id JAA09532; Sat, 6 Jan 2001 09:57:16 +0100 Sender: ricle@celocom.se Message-ID: <3A56DD82.3DDB7011@celocom.se> Date: Sat, 06 Jan 2001 09:55:30 +0100 From: Richard Levitte at Celo Organization: Celo Communications, Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren , PKIX-List Subject: Re: Basic Cert-2-Directory mapping question References: <015901c07690$0c24f250$0201a8c0@vincent.se> <3A56DA86.A5AA171F@celocom.se> Content-Type: multipart/mixed; boundary="------------D659D55E13529837EA4826C9" This is a multi-part message in MIME format. --------------D659D55E13529837EA4826C9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry for the double message. I had some trouble on my end and it looked like the first try didn't get through... -- Richard Levitte !!! New cell phone number !!! richard.levitte@celocom.se /* You might enjoy viewing the complete vCard */ --------------D659D55E13529837EA4826C9 Content-Type: text/x-vcard; charset=us-ascii; name="richard.levitte.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Levitte at Celo Content-Disposition: attachment; filename="richard.levitte.vcf" begin:vcard n:Levitte;Richard tel;cell:+46-733-72 8811 tel;work:+46-8-58 72 8811 x-mozilla-html:FALSE org:Celo Communications version:2.1 email;internet:richard.levitte@celocom.se title:Software Artist adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN note;quoted-printable:
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
o/~Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
x-mozilla-cpt:;0 fn:Richard Levitte end:vcard --------------D659D55E13529837EA4826C9-- From owner-ietf-pkix Sat Jan 6 02:57:48 2001 Received: from heather.ithnet.com (ns.ithnet.com [62.157.157.10]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA02146 for ; Sat, 6 Jan 2001 02:57:47 -0800 (PST) Received: by heather.ithnet.com (Smail3.2 #4) id m14Er7D-000Dz9C; Sat, 6 Jan 2001 12:02:27 +0100 (CET) Received: from gate.ots-erdl.de(62.157.156.209), claiming to be "gate.ots-ag.de" via SMTP by mail2.ithnet.com, id smtpdWeWliQ; Sat Jan 6 12:02:13 2001 Received: from newsmail.com ([193.255.114.246]) by gate.ots-ag.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id MAA08959 for ; Sat, 6 Jan 2001 12:01:44 +0100 Date: Sat, 6 Jan 2001 12:01:44 +0100 Message-Id: <200101061101.MAA08959@gate.ots-ag.de> Reply-To: HOP@newsmail.com Content-Type: text/html; charset=us-ascii X-Priority: 1 From: House of Pleasure To: ietf-pkix@imc.org Subject: NEW CYBERPAGE IN SPACE, HAVE FUN Hello There,

Threre is a very new Website aboub fun, fun and fun again.

The URL is http://www.h-o-p.de

visit it !!!!

HOP Webmaster.

This email was sent via Ellipse Bulk Emailer v2.0 From owner-ietf-pkix Sat Jan 6 03:35:49 2001 Received: from maild.telia.com (root@maild.telia.com [194.22.190.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA08609 for ; Sat, 6 Jan 2001 03:35:48 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maild.telia.com (8.9.3/8.9.3) with ESMTP id MAA20975; Sat, 6 Jan 2001 12:40:24 +0100 (CET) Received: from mega (t3o69p72.telia.com [62.20.145.72]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f06BeNl20508; Sat, 6 Jan 2001 12:40:24 +0100 (CET) Message-ID: <009101c077d5$3c5e0d30$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Richard Levitte at Celo" , "PKIX-List" Cc: "Philip Hallam-Baker" References: <015901c07690$0c24f250$0201a8c0@vincent.se> <3A56D9C6.777B76F0@celocom.se> Subject: Re: Basic Cert-2-Directory mapping question Date: Sat, 6 Jan 2001 12:38:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA08611 Richard, > If I understand things correctly, you need support for one-to-many of > certificate-to-direntry, because > > CN=James Adrian Smith + SN=343434 > > would map both to > > /CN=James Adrian Smith > > and > > /SN=343434 > > If I'm incorrect, I'll gladly be corrected. No, that was not exactly what I searched for. As a side note: Regarding SN I thought that it denoted serial number that could be used as an entity UID. The key issue is: How do you map/match using *X500 directory technology* (in contrast to using RDBMSs where this is a piece of cake), an arbitrary certificate with an equally arbitrary directory entry in an efficient and standard-conformant way? That this is not that easy is demonstrated by the fact that you (AFAIK) cannot use anthyning but a Win2K kerberos certificate to perform a local Win2K PKI-based login. If you have a PKI credential (for example in a GemSAFE card) it will only be usable in one domain which is awkward as you (as a person) may be trusted in multiple *independent* places. #################################################################### Essentially the value of TTP-issued ID-certificates is severely reduced by such limitations. Commercial CA vendors out there! Are you listening? #################################################################### The request for many-to-one mappings is optional but potentially extremely useful as you could end-up having different credentials in your PDA than in your smart card. If my findings are correct I would say this this issue should absolutely be studied to see if there is a feasibility to come up with a generic solution. Yet Another Standard that is. /Anders From owner-ietf-pkix Sat Jan 6 17:27:22 2001 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19530 for ; Sat, 6 Jan 2001 17:27:21 -0800 (PST) Received: by ns.celocom.se; id CAA17809; Sun, 7 Jan 2001 02:32:04 +0100 (CET) Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma017803; Sun, 7 Jan 01 02:31:42 +0100 Received: from celocom.se (root@localhost [127.0.0.1]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id CAA15308; Sun, 7 Jan 2001 02:31:41 +0100 Sender: ricle@celocom.se Message-ID: <3A57C692.FBFB918E@celocom.se> Date: Sun, 07 Jan 2001 02:29:54 +0100 From: Richard Levitte at Celo Organization: Celo Communications, Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: PKIX-List , Philip Hallam-Baker Subject: Re: Basic Cert-2-Directory mapping question References: <015901c07690$0c24f250$0201a8c0@vincent.se> <3A56D9C6.777B76F0@celocom.se> <009101c077d5$3c5e0d30$0201a8c0@vincent.se> Content-Type: multipart/mixed; boundary="------------4A785FE1164DF9E6EE8B9E93" This is a multi-part message in MIME format. --------------4A785FE1164DF9E6EE8B9E93 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > The key issue is: How do you map/match using *X500 directory technology* (in contrast > to using RDBMSs where this is a piece of cake), an arbitrary certificate with an equally arbitrary > directory entry in an efficient and standard-conformant way? Ah... Eh, you got me stumped there. You see, I was under the impression that certificate DNs (I assume we're talking RFC2459 or X.509 certificates heer) would map more or less directly into a X.500 directory with no trouble at all. But then, I don't know X.500 that well, so I may be talking out of my behind... > That this is not that easy is demonstrated by the fact that you (AFAIK) cannot use > anthyning but a Win2K kerberos certificate to perform a local Win2K PKI-based login. > If you have a > PKI credential (for example in a GemSAFE card) it will only be usable in one domain > which is awkward as you (as a person) may be trusted in multiple *independent* places. I've always wondered what those "Kerberos Certificates" are, or do you mean tickets? They have nothing to do with PKI, since Kerberos doesn't use PKC. Could this not just be an IP security policy problem? (in that case, this discussion has nothing more to do on this list) -- Richard Levitte !!! New cell phone number !!! richard.levitte@celocom.se /* You might enjoy viewing the complete vCard */ --------------4A785FE1164DF9E6EE8B9E93 Content-Type: text/x-vcard; charset=us-ascii; name="richard.levitte.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Levitte at Celo Content-Disposition: attachment; filename="richard.levitte.vcf" begin:vcard n:Levitte;Richard tel;cell:+46-733-72 8811 tel;work:+46-8-58 72 8811 x-mozilla-html:FALSE org:Celo Communications version:2.1 email;internet:richard.levitte@celocom.se title:Software Artist adr;quoted-printable:;;Sveav=E4gen 145, 5tr=0D=0AStockholm;;;;SWEDEN note;quoted-printable:
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
c=EAlo, =E2vi, =E2tum, (latin) 1,v.a.=0D=0A to hide something from one, to keep secret, to conceal.=0D=0A
=0D=0A
=0D=0A=0D=0A=0D=0A =0D=0A=0D=0A
=0D=0A =0D=0A =0D=0A =0D=0A =0D=0A =0D=0A
o/~Coding, coding, coding
=0D=0A Keep'em hackers coding
=0D=0A And When They're Done Coding
=0D=0A COMPIIIIIIILE!!
=0D=0A
x-mozilla-cpt:;0 fn:Richard Levitte end:vcard --------------4A785FE1164DF9E6EE8B9E93-- From owner-ietf-pkix Sat Jan 6 22:15:50 2001 Received: from mailf.telia.com (root@mailf.telia.com [194.22.194.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22699 for ; Sat, 6 Jan 2001 22:15:49 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailf.telia.com (8.9.3/8.9.3) with ESMTP id HAA04978; Sun, 7 Jan 2001 07:20:33 +0100 (CET) Received: from mega (t3o69p53.telia.com [62.20.145.53]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f076KWl24461; Sun, 7 Jan 2001 07:20:32 +0100 (CET) Message-ID: <002001c07871$b8f140f0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Richard Levitte at Celo" Cc: "PKIX-List" References: <015901c07690$0c24f250$0201a8c0@vincent.se> <3A56D9C6.777B76F0@celocom.se> <009101c077d5$3c5e0d30$0201a8c0@vincent.se> <3A57C692.FBFB918E@celocom.se> Subject: Re: Basic Cert-2-Directory mapping question Date: Sun, 7 Jan 2001 07:18:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id WAA22700 Richard, > Anders Rundgren wrote: > > The key issue is: How do you map/match using *X500 directory technology* (in contrast > > to using RDBMSs where this is a piece of cake), an arbitrary certificate with an equally arbitrary > > directory entry in an efficient and standard-conformant way? > > Ah... Eh, you got me stumped there. You see, I was under the impression that > certificate DNs (I assume we're talking RFC2459 or X.509 certificates heer) > would map more or less directly into a X.500 directory with no trouble at all. > But then, I don't know X.500 that well, so I may be talking out of my behind... The question rephrased: How could an RFC2459-compliant cert using an arbitrary DN map in an equally arbitrary X.500-compliant directory? Arbitrary could also be expressed in this context as: The certs are not tailor-made for this particular directory. This is what you get if you for example buy a Swedish Electronic ID-card based on a citizen registration system that usually have no relevance in a private company. Still you would like to use it in that context and the question is how? The answer is mapping and my question was how you do that using *directory technology* using an (hopefully) standardized method. > > That this is not that easy is demonstrated by the fact that you (AFAIK) cannot use > > anthyning but a Win2K kerberos certificate to perform a local Win2K PKI-based login. > > If you have a > > PKI credential (for example in a GemSAFE card) it will only be usable in one domain > > which is awkward as you (as a person) may be trusted in multiple *independent* places. > > I've always wondered what those "Kerberos Certificates" are, or do you mean > tickets? They have nothing to do with PKI, since Kerberos doesn't use PKC. > Could this not just be an IP security policy problem? (in that case, this > discussion has nothing more to do on this list) No, maybe the name is bad but I referred to the certificates that the Win2K kerberos accepts which currently is AFAIK limited to certs issued by the domain controller CA itself (approx.) which results in the problems noted. Anders From owner-ietf-pkix Sun Jan 7 08:03:22 2001 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17316 for ; Sun, 7 Jan 2001 08:03:21 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id FAA10605; Mon, 8 Jan 2001 05:07:53 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97888367312331>; Mon, 8 Jan 2001 05:07:53 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: anders.rundgren@telia.com, richard.levitte@celocom.se Subject: Re: Basic Cert-2-Directory mapping question Cc: ietf-pkix@imc.org Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Mon, 8 Jan 2001 05:07:53 (NZDT) Message-ID: <97888367312331@kahu.cs.auckland.ac.nz> "Anders Rundgren" writes: >The question rephrased: How could an RFC2459-compliant cert using an >arbitrary DN map in an equally arbitrary X.500-compliant directory? >Arbitrary could also be expressed in this context as: The certs are not >tailor-made for this particular directory. This is what you get if you for >example buy a Swedish Electronic ID-card based on a citizen registration >system that usually have no relevance in a private company. Still you would >like to use it in that context and the question is how? The answer is >mapping and my question was how you do that using *directory technology* >using an (hopefully) standardized method. You can't do it. Actually the answer is a lot more complex than that, I looked at it in my ACASC'00 paper on certificate stores which should be available from http://www.acsac.org, this is a shorter version due to size constraints of a somewhat longer work which I'll put on my home page within the next week or two (it's the middle of the summer break over here, so some things are running at a low priority). The main problem is that DN's don't work [0], so you end up with ones which people have filled with whatever they feel like, odd things required by cert profiles or signature laws or organisational constraints or whatever which generally don't fit any known directory schema. The current approaches to this problem if you're using a directory as a cert store are: - Continually update the directory schema to match any new DNs which appear until the directory admin(s) go insane (hi Paul :-). - Create aliases in the directory mapping DNs in certs to the (fixed) directory schema. - Force all certs to use the schema used in the directory (someone who's been through this one once described it to me as "extraordinarily painful"). - Use the directory DN to identify the cert owner and store the cert as just another attribute, with the actual cert DN ignored. - (There may be more, since the whole thing is badly broken there are probably lots of workarounds being used. If anyone knows of others please let me know) A much better approach IMNSHO, and the one I look at in my paper, is to treat the DN as a blob and hash it down to a fixed-length value which you use as a key to look up the cert in an RDBMS or something like dbm if you don't need the full RDBMS functionality [1]. This approach just plain works no matter how garbled and broken the DN is. That's the short version, the longer one, with a fairly detailed analysis of requirements and performance issues, will be on the paper I'll have on my home page and in the ACSAC version. Peter. [0] Strictly speaking this should say "After ~15 years of trying to make them work noone's really managed it", but I usually generalise it to "DN's don't work" to save having to update the year count every year or so. [1] One somewhat surprising thing I found out during and after publishing the paper is how many vendors are actually using RDBMS' as cert stores, even if they have to bolt an X.500/LDAP interface on top of them. I only know of one vendor which isn't using either an RDBMS or dbm with an X.500 glue layer on top for their cert store (not counting toy stuff like MS using the registry to store certs). From owner-ietf-pkix Sun Jan 7 09:44:26 2001 Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23295 for ; Sun, 7 Jan 2001 09:44:25 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id SAA11942; Sun, 7 Jan 2001 18:49:11 +0100 (CET) Received: from mega (t7o69p165.telia.com [213.65.46.165]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f07HnAl18592; Sun, 7 Jan 2001 18:49:10 +0100 (CET) Message-ID: <002001c078d1$ebab1650$0201a8c0@vincent.se> From: "Anders Rundgren" To: Cc: References: <97888367312331@kahu.cs.auckland.ac.nz> Subject: Re: Basic Cert-2-Directory mapping question Date: Sun, 7 Jan 2001 18:45:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id JAA23297 Peter, Thanx for the very elaborate answer that matched my worst fears about TTP-issued certificates! I could not find your paper though - please send me it directly and I will respond with a paper that I am currently working on, on how to solve this problem. Would you BTW be interested in participating in a BOF-like feasibility study to see if DNs must continue to be broken until the end of time? Or maybe you have already given IYNSHO the likely outcome of such a study :-):-) /Anders > Anders Rundgren writes: > > >The question rephrased: How could an RFC2459-compliant cert using an > >arbitrary DN map in an equally arbitrary X.500-compliant directory? > >Arbitrary could also be expressed in this context as: The certs are not > >tailor-made for this particular directory. This is what you get if you for > >example buy a Swedish Electronic ID-card based on a citizen registration > >system that usually have no relevance in a private company. Still you would > >like to use it in that context and the question is how? The answer is > >mapping and my question was how you do that using *directory technology* > >using an (hopefully) standardized method. > > You can't do it. Actually the answer is a lot more complex than that, I > looked at it in my ACASC'00 paper on certificate stores which should be > available from http://www.acsac.org, this is a shorter version due to size > constraints of a somewhat longer work which I'll put on my home page within > the next week or two (it's the middle of the summer break over here, so some > things are running at a low priority). > > The main problem is that DN's don't work [0], so you end up with ones which > people have filled with whatever they feel like, odd things required by cert > profiles or signature laws or organisational constraints or whatever which > generally don't fit any known directory schema. The current approaches to > this problem if you're using a directory as a cert store are: > > - Continually update the directory schema to match any new DNs which appear > until the directory admin(s) go insane (hi Paul :-). > - Create aliases in the directory mapping DNs in certs to the (fixed) > directory schema. > - Force all certs to use the schema used in the directory (someone who's > been through this one once described it to me as "extraordinarily painful"). > - Use the directory DN to identify the cert owner and store the cert as just > another attribute, with the actual cert DN ignored. > - (There may be more, since the whole thing is badly broken there are > probably lots of workarounds being used. If anyone knows of others > please let me know) > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > the DN as a blob and hash it down to a fixed-length value which you use as a > key to look up the cert in an RDBMS or something like dbm if you don't need > the full RDBMS functionality [1]. This approach just plain works no matter > how garbled and broken the DN is. > > That's the short version, the longer one, with a fairly detailed analysis of > requirements and performance issues, will be on the paper I'll have on my home > page and in the ACSAC version. > > Peter. > > [0] Strictly speaking this should say "After ~15 years of trying to make them > work noone's really managed it", but I usually generalise it to "DN's > don't work" to save having to update the year count every year or so. > > [1] One somewhat surprising thing I found out during and after publishing the > paper is how many vendors are actually using RDBMS' as cert stores, even > if they have to bolt an X.500/LDAP interface on top of them. I only know > of one vendor which isn't using either an RDBMS or dbm with an X.500 glue > layer on top for their cert store (not counting toy stuff like MS using > the registry to store certs). > From owner-ietf-pkix Sun Jan 7 22:03:55 2001 Received: from fsnt.future.futsoft.com ([203.197.140.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA15728 for ; Sun, 7 Jan 2001 22:03:54 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 08 Jan 2001 11:43:24 +0530 Received: from ruheenar (ruheenar.future.futsoft.com [10.0.12.41]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f0868O217357 for ; Mon, 8 Jan 2001 11:38:25 +0530 Reply-To: From: "Ruheena Rashid" To: Subject: unsubscribe Date: Mon, 8 Jan 2001 11:46:32 +0530 Message-Id: <001e01c0793a$8c086b80$290c000a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit unsubscribe From owner-ietf-pkix Mon Jan 8 00:28:49 2001 Received: from venus.initech.com ([203.238.37.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA03081 for ; Mon, 8 Jan 2001 00:28:48 -0800 (PST) Received: from initech.com ([203.238.37.143]) by venus.initech.com (8.11.0/8.11.0) with ESMTP id f088Tlj02631 for ; Mon, 8 Jan 2001 17:29:47 +0900 (KST) Message-ID: <3A597B5C.A64C3BF1@initech.com> Date: Mon, 08 Jan 2001 17:33:32 +0900 From: ChungKil Kim X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,ko MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Experimental TSA Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Our TSA service is available at the following address 203.238.37.132 , port 3318. this TSA is TCP/IP based service. Implementation based on draft-ietf-pkix-time-stamp-12.txt thanks From owner-ietf-pkix Mon Jan 8 03:46:22 2001 Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24454 for ; Mon, 8 Jan 2001 03:46:21 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA03744; Mon, 8 Jan 2001 12:51:05 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 8 Jan 2001 12:51:05 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id MAA19405; Mon, 8 Jan 2001 12:51:03 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id MAA16511; Mon, 8 Jan 2001 12:51:03 +0100 (MET) Date: Mon, 8 Jan 2001 12:51:03 +0100 (MET) Message-Id: <200101081151.MAA16511@emeriau.edelweb.fr> To: kent@bbn.com Subject: RE: DPD & DPV requirements - Let us Recurse Cc: ietf-pkix@imc.org > > Returning info that explains why a server believes that the returned > data supports validation is an interesting notion. The first example > of that I saw was in work performed by colleagues here at BBN, on a > project calls IOS, in the early 90s, where servers did that. But, I > think this is still an R&D topic for now, not yet ready for > standardization. Isn't part of this 'interesting notion' the cert chain itself. The certificate chain return by a DPV server is the chain that has been used to validate it, and the server believes that this chain is valid. If the service is implemented using some relaying, such that a server becomes a client of someone else, what research problem is there that the intermediate server/client wants to provide the results? If for the initial client the result of the validation becomes something that can be stored somewhere, e.g. similar to an OCSP response stored in the SMIME/ETSI signature format stuff, then essentially this client becomes an intermediate server for another verifier of the enhanced signature. From owner-ietf-pkix Mon Jan 8 04:14:15 2001 Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25769 for ; Mon, 8 Jan 2001 04:14:14 -0800 (PST) Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA44762; Mon, 8 Jan 2001 13:25:56 +0100 Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id NAA23532; Mon, 8 Jan 2001 13:18:32 +0100 Message-ID: <3A59B018.90B0ACB@bull.net> Date: Mon, 08 Jan 2001 13:18:32 +0100 From: Denis Pinkas Organization: Bull X-Mailer: Mozilla 4.7 [fr] (Win98; I) X-Accept-Language: fr MIME-Version: 1.0 To: Stephen Kent CC: PKIX-List Subject: Re: DPD & DPV requirements References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> <004401c06739$f7b9f550$0201a8c0@vincent.se> <3A51B25D.A449FC37@bull.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id EAA25770 Steve, See my responses embbeded with your comments. > Denis, > > Steve, > > First of all, many thanks for posting this long document. > > I will not respond using directly your text, since my arguments > are fairly different. I will however re-use some of your arguments. > > Let us use the concept of "validation policy", that you introduce, which is > all the set of rules to be followed when validating a certificate. It will > usually not simply be the rules mentioned in RFC 2459, but these rules with > additional conditions. Note that in the context of electronic signatures, a > "signature policy" is a specific example of a "validation policy". > [Steve] We need to be explicit about what are the parameters that control path validation. The 2459 validation algorithm has a well-defined set, but if there are others, we need to have them specified and agreed upon. One conversation that took place in San Diego noted that one could imagine a lot of parameters that a user might want to express re path validation, but which have not been standardized, and for which we do not have general agreement. A very rich list of this sort, and the associated complexity that would accompany an enhanced validation algorithm that used thise parameters, was thought to be out of scope for now, more an R&D topic vs. a topic for standardization. So we have to be careful here. [Denis] The current validation algorithm described in RFC 2459 is fine but too restritive. It works fine with a single root key in the case where there are no naming constraints nor Certification Policy constraints, or in the case where there are are included in the (root) self-signed certificates. I have worked with Tim Polk so that in the "son-of-RFC2459" we will have the description of an enhanced path validation algorithm that will take care of multiple roots, each one associated with different naming constraints or Certification Policy constraints - which will not necessarilly be included in the root self-signed certificates. So we would need to support two options, which are not mutually exclusive: 1) define with a great level of accuracy each of the parameters, or 2) provide an OID which is a global reference to all these parameters. > DPV > === > > Let us start with DPV first. A DPV client will not necessarily be either > PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV protocol: > > 1) one not using ASN.1 (e.g. using XML), > 2) one using ASN.1. > > In both cases the client only supplies an unambiguous reference of the > certificate (CA name, serial number and a hash of the certificate) or the > certificate itself and specifies the rules to be followed to validate the > certificate: an identification of a pre-defined "validation policy" (e.g. an > OID and/or a URL to find the policy and a hash of that validation policy). > [Steve] Given the problems we have had in OCSP (v1) re referring to a target cert, I am not comfortable specifying a target cert other than by providing a copy of that cert to the server. [Denis] In a signed CMS message, you may only have the EESCertID, without the certificate itself. ESSCertID ::= SEQUENCE { certHash Hash, issuerSerial IssuerSerial OPTIONAL } Hash ::= OCTET STRING -- SHA1 hash of entire certificate IssuerSerial ::= SEQUENCE { issuer GeneralNames, serialNumber CertificateSerialNumber } The idea is to be able to use ESSCertID without the need to fetch the certificate itself. > As a result, the client expects a signed response which reproduces the > requested parameters and includes a status. The status is not simply: > "passed validation", "failed validation", or "don't' know" but can also be > "incomplete validation", meaning that some revocation status information is > not yet available at the time of processing and a later attempt might > succeed. > [Steve] Incomplete validation is a reasonable response. [Denis] :-) [Steve] maybe we should include the set of parameters used for the validation, including ones not supplied by the client, e.g., defaults, or overrides imposed by the server, or the values bound to a policy that was specified. [Denis] We are not on the same track here. I am assuming that a DPV client is PKI ignorant. You are making the assumption that the client MAY simply some elements of the certification path, where I make the assumption that the single element that MAY be supplied in a DPV request is the leaf certificate. For all the other elements of a certification path, the server is supposed to have access to the various repositories. The response contains a blob of what has been used, that can be blinding copied and stored. > The response must include the time at which the validation has been > performed. Allowing to test a certificate "in the past", would place some > requirements that cannot always be accomplished by a standard PKI: currently > we do not mandate CAs to maintain revocation information beyond the end of > the validity period of a certificate. We should not change that rule. So I > am very reluctant to autorise validation in the past, e.g. 10 years later. > [Steve] Good points; we should include the time of the response. I added the "in the past" requirement based on its inclusion in SCVP, but there clearly limits to one's ability to support that feature. However, if the server is uable to verify a cert relative to a prior time, based on unavailability of some revocation data, it can always state that in a response. One might add a requirement to allow the server to be configured to reject requests for validation that cite a time/date prior to some confugured value. [Denis] Since archiving of recocation information is not mandated to the CAs, such a function would need to be provided by some other trusted service provider. We should be very careful before allowing the provision of such a new service. I believe that the PKI is already sufficiently complex so that we make our best efforts not to introduced additional Trusted Service Providers (that could be avoided). The only case to be supported should be the "current time" and some time "soon after the end of validity of a certificate" (i.e. a few weeks, in case someone being on holidays would like to check, when coming back from holidays, if a received message, was signed by a revoked certificate or not). > If a client is interested in a later proof, then it should obtain that > information from the server at the time the information is still available. > This means that a client should have the possibility to ask the server to > optionally return an opaque blob that contains all what has been used to > validate the certificate (i.e. a certification path and all the CRLs or > OCSPs needed for each certificate from the path). > [Steve] We have this requirement already, with a time stamp option. [Denis] We should remove the time stamp option. > A question arises from the requirements 1.5 and 1.6 that you listed: should > that opaque blob be time-stamped ? If there is a fear that some of the > issuing keys used in the certification path might later on be compromised, > then this can be useful. This case should be very seldom and hence this > service would not always be required. In addition, why should that service > be embedded in this protocol ? This could be obtained using directly the > TSP, leaving more possibilities: free choice of the TSAs, time stamp of the > full blob, time stamp of the certification chain only, time stamp on both > the certification chain and the revocation information. Thus I do not favor > to piggy-back the two services. > [Steve] Yes, one could keep the services separate. I am not hard over on this, and can be persuaded to remove the requirement, or to make server support for it optional. [Denis] If you are not hard on this issue, let us remove the time stamping option. :-) > In order to simplify the protocol and allow for PKI-ignorant clients, the > client should NOT be allowed to provide any other element than the > certificate, that might help to construct the path or the revocation > information. > [Steve] I don't see the rationale for this. We already have application protocols where a client that is not PKI-aware might acquire cert paths and/or revocation data that it could pass on to a DPV server. So, I don't think you have made a good argument here for not allowing such data to be transmitted. Also, I don't think we have agreement yet that we are supporting clients that are not PKI-aware. I merely noted that IF we choose to support such clients, then there are implications for the syntax used for the protocol, and for the semantics of what is transmitted. I don't think we have made the next step to agree to support such clients. [Denis] I have difficulties to understand how a client that would NOT be "PKI-aware might acquire cert paths and/or revocation data" :-) Once again, I am advocating a simple protocol for DPV to be used by PKI ignorant clients. > This means that, not only I do not agree with a common list of requirements > for both DPV and DPD, but also that I do not agree with many of the > requirements that you listed: > > For a DPV client: > > 1.1. Only a single certificate should be allowed. > 1.2. No revocation items should be allowed. > 1.3. No request in the past should be allowed. > 1.4. Imposing constraints for CRLs or OCSP responses should be hidden > under the "validation policy" that is selected. > 1.5. and 1.6. Time stamped responses, if needed, should not be part of the > service. > 1.7. Validation policies are not necessarily "configured at the server", > but can simply be pre-defined, outside the server. I any case, the > rules that has been followed - i.e. "validation policy" - must be > indicated in the response. > 1.8. For DPV, responses must be signed. > 1.9. The policy ID format can/will be specified in the protocol. > > For a DPV server: > > 2.1. A DPV server, will have to do more than RFC 2459, hence why the use > of a validation policy is needed. > 2.2. An opaque blob MAY be returned. > 2.3. Time stamping is not needed. > 2.4. The concept of policy overriding is too complex: a reference to > a validation policy is sufficient. > 2.5. No comment. > 2.6. A server must support LDAP for certificate fetching, and EITHER CRL > fetching OR OSCP (OCSP should not be mandatory). > 2.7. No comment. > [Steve] Given that we no longer agree on the underlying assumptions, it probably is not worthwhile discussing each of your proposed changes above. [Denis] Yes and no. We clearly have different assumptions, but we need to find an agreement. I am first advocating to separate the requirements for DPV from the requirements for DPD. Then we need to discuss the requirements for each of them. So we need to come with separate lists of requirements. This is what I did in my response. > DPD > === > > Let us continue with DPD. I agree in general with many of the requirements > that you listed in that case. In particular, since a DPD client must be both > PKI-aware and ASN.1 aware, the protocol should only be described in ASN.1. > > The major difference with the previous protocol is that no evaluation of the > returned chain needs to be done, since the client is supposed to be able to > perform all the checks himself. Therefor no validation status is returned by > the server. > [Steve] I don't think I agree with both of the statements above. No explicit validation status is returned, but I do think the server is performing validation so that only valid chains are returned. [Denis] Since these chains may not be complete, I would not consider such chains to be "valid". These chains will comply with the request, but some elements (more probably revovation information, but also certificates ?) may be missing. > The service is more a single place for shopping all (?) the needed > certificates and revocation status information. > > In the request, the client could either specify a validation policy or the > trusted points with, for each level of the chain, the indication whether > CRLs or OCSP responses are requested. > > One or more chains, corresponding to the request may be obtained. > > The response does not need to be signed, but only protected by a combined > integrity and data origin authentication service. > > CONCLUSION > ========== > > We could support three protocols: > > 1° DPV in XML, > 2° DPV in ASN.1, > 3° DPD in ASN.1. > [Steve] The operative term here is "could." Also, DPV in XML and DPV in ASN.1 need not be the same protocol, because of different assumptions about the clients. So I think of it three protocols where 2 & 3 may be very similar, but 1 is quite different. [Denis] Two remarks: 1) What kind of different assumptions are you making on: 1) DPV in XML and 2) DPV in ASN.1 ? 2) You think that protocols 2 & 3 may be very similar, but you do not provide arguments. On the contrary, I do not think the same and I have have provided arguments to explain why they are pretty different. > ADDITIONAL QUESTION > =================== > > For the two protocols in ASN.1, should these two protocols be piggy-back on > OCSP ? > [Steve] That's one of the proposals, but the answer should be the result of analysis of a revised proposal consistent with the requirements that we adopt. [Denis] Agreed. > Before going at the technical details, it is important to raise the > following question: which combination(s) of the three basic requests (OCSP, > DPV and DPD) could make sense ? > > If a client requests DPV, then it does not care about OCSP and neither on > DPD (multiple certification chains to be tested). > > For a PKI-aware client, only OCSP + DPD makes sense. > > This means that : > > 1) DPV does not need to be supported by OCSP. > 2) The only protocol to be piggy-backed to OCSP would be DPD. > [Steve] I don't understand these comments. You need to provide more substantiation. [Denis] OK. Let me try to explain more: " If a client requests DPV, then it does not care about OCSP and neither on DPD (multiple certification chains to be tested)." If a client requests DPV, it would normally like to get the response "passed validation", and will ask whether or not it wants back the single proof (as a blob) that lead to that conclusion. In that case, it does not care about the OCSP response which has been used in the validation algorithm and is part from the blob. A single chain is returned in that case. "For a PKI-aware client, only OCSP + DPD makes sense. This means that : 1) DPV does not need to be supported by OCSP. 2) The only protocol to be piggy-backed to OCSP would be DPD." DPV is NOT designed for a PKI-aware client, but of course can be used by a PKI aware client, that will behave as if it were PKI ignorant. So the single combination that remains is between the two remaining protocols for PKI-aware clients (i.e. OCSP and DPD). In that sense, DPD could be piggy-backed on top of OCSP. Denis > Steve From owner-ietf-pkix Mon Jan 8 04:26:17 2001 Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26228 for ; Mon, 8 Jan 2001 04:26:16 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 14FbS6-000ObU-0W for ietf-pkix@imc.org; Mon, 8 Jan 2001 12:31:07 +0000 Message-ID: <3A59B3B3.EB5B7B3B@celocom.com> Date: Mon, 08 Jan 2001 12:33:55 +0000 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PKIX-List Subject: OCSP authorized responder clarification. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In RFC2560 4.2.2.2 the certificate signing an OCSP request is valid if it: > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage > extension and is issued by the CA that issued the certificate in > question." A certain CA issues end user certificates signed by an intermediate CA which is in turn signed by the root CA. The responder certificate is signed by the root CA. Does this, as appears to be the case, mean that the above condition does not apply because the OCSP reponder certificate is not signed by the intermediate CA? Alternatively is the condition satisfied because they both have the same root CA? Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-pkix Mon Jan 8 05:08:06 2001 Received: from tienesmail.com (cx116181-b.tulsa1.ok.home.com [24.179.28.16]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA00380; Mon, 8 Jan 2001 05:08:04 -0800 (PST) From: marc5858@usa.com Subject: A Curious and Interesting Opportunity!! Date: Mon, 8 Jan 2001 03:32:52 Message-Id: <734.623821.633792@tienesmail.com> Dear Friend: AS SEEN ON NATIONAL TV : ''Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time'' THANKS TO THE COMPUTER AGE AND THE INTERNET! ================================================= BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!! Before you say ''Bull'', please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below, to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are ''absolutely NO laws prohibiting the participation in the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost''. DUE TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: ''Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in''. Pam Hedland, Fort Lee, New Jersey. ------------------------------------------------------------ Here is another testimonial: ''This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and voila' - 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program, I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything'' More testimonials later but first, ****PRINT THIS NOW FOR YOUR FUTURE REFERENCE**** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: ****Order all 5 reports shown on the list below. ****For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. ****When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. ****Within a few days you will receive, vie e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. ****IMPORTANT __ DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructed below in step '' 1 through 6 '' or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1....After you have ordered all 5 reports, take this advertisement and REMOVE the name & address of the person in REPORT #5. This person has made it through the cycle and is no doubt counting their fortune. 2....Move the name & address in REPORT #4 down TO REPORT #5 3....Move the name & address in REPORT #3 down TO REPORT #4 4....Move the name & address in REPORT #2 down TO REPORT #3 5....Move the name & address in REPORT #1 down TO REPORT #2 6....Insert YOUR name & address in the REPORT #1 Position. PLEASE MAKE SURE you copy every name & address ACCURATELY! ================================================= ****Take this entire letter, with the modified list of names, and save it on your computer. DO NOT MAKE ANY OTHER CHANGES. Save this on a disk as well just in case if you loose any data. ****To assist you with marketing your business on the internet, the 5 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails legally, where to find thousands of free classified ads and much more. There are 2 Primary methods to get this venture going: METHOD #1 : BY SENDING BULK E-MAIL LEGALLY ================================================= Let's say that you decide to start small, just to see how it goes, and we will assume You and those involved send out only 5,000 e- mails each. Let's also assume that the mailing receive only a 0.2% response (the response could be much better but lets just say it is only 0.2% . Also many people will send out hundreds of thousands e-mails instead of only 5,000 each). Continuing with this example, you send out only 5,000 e- mails. With a 0.2% response, that is only 10 orders for report # 1.Those 10 people responded by sending out 5,000 e- mail each for a total of 50,000. Out of those 50,000 e-mails only 0.2% responded with orders. That's = 100 people responded and ordered Report # 2. Those 100 people mail out 5,000 e-mails each for a total of 500,000 e-mails. The 0.2% response to that is 1000 orders for Report # 3. Those 1000 people send out 5,000 e-mails each for a total of 5 million e-mails sent out. The 0.2% response to that is 10,000 orders for Report # 4. Those 10,000 people send out 5,000 e-mails each for a total of 50,000,000 (50 million) e-mails. The 0.2% response to that is 100,000 orders for Report # 5 THAT'S 100,000 ORDERS TIMES $5 EACH = $500,000.00 (half million). Your total income in this example is: 1..... $50 + 2..... $500 + 3..... $5,000 + 4..... $50,000 + 5..... $500,000 ......... Grand Total = $555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY! ------------------------------------------------------------ REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE ORDERING OUT OF 5,000 YOU MAILED TO. Dare to think for a moment what would happen if everyone, or half or even one 4th of those people mailed 100,000 e-mails each or more? There are over 150 million people on the internet worldwide and counting. Believe me, any people will do just that, and more! METHOD #2 : BY PLACING FREE ADS ON THE INTERNET ================================================= Advertising on the net is very very inexpensive and there are hundreds of FREE places to advertise. Placing a lot of free ads on the internet will easily get a larger response. We strongly suggest you start with method #1 and add METHOD #2 as you go along. For every $5 you receive, all you must do is e-mail them the Report they ordered. That's it . Always provide same day service on all orders. This will guarantee that the e-mail they send out, with your name and address on it, will be prompt because they cannot advertise until they receive the report. _________________AVAILABLE REPORTS__________________ ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes: Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT accepted. Make sure the cash is concealed by wrapping it in at least 2 sheets of paper. On one of those sheets of paper, Write the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL ADDRESS and your name and postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ================================================= REPORT #1 ''The Insider's Guide to Advertising for Free on the Net'' Order Report #1 from: M. Somerstein 9904 E 73 ST S #1004 Tulsa, OK 74133 U.S.A _____________________________________________________ REPORT #2 ''The Insider's Guide to Sending Bulk e-mail on the Net'' Order Report #2 from : A. Bain P.O. Box 811331 Chicago, IL 60681 U.S.A. ____________________________________________________ REPORT #3 ''The Secret to Multilevel marketing on the Net'' Order Report #3 from: T. Kann P.O. Box 218 Woody Creek, CO 81656 U.S.A. _____________________________________________________ REPORT #4 ''How to become a millionaire utilizing MLM & the Net'' Order Report #4 from: Bonnie Jay P.O. Box 1463 Montrose, CO 81402 U.S.A. ______________________________________________________ REPORT #5 ''HOW TO SEND 1 MILLION E-MAILS FOR FREE'' Order Report #5 from: Daryn Dunn 6214 E. 126th St., Apt 302 Grandview, MO 64030 U.S.A. ____________________________________________________ $$$$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$$$$ Follow these guidelines to guarantee your success: ***If you do not receive at least 10 orders for Report #1 within 2 weeks, continue sending e-mails until you do. ***After you have received 10 orders, 2 to 3 weeks after that you should receive 100 orders or more for REPORT #2. If you did not, continue advertising or sending e-mails until you do. ***Once you have received 100 or more orders for Report #2, YOU CAN RELAX, because the system is already working for you and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER : Every time your name is moved down on the list, you are placed in front of a Different report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. IF YOU WANT TO GENERATE MORE INCOME SEND ANOTHER BATCH OF E-MAILS AND START THE WHOLE PROCESS AGAIN. There is NO LIMIT to the income you can generate from this business!!! ______________________________________________________ FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS PROGRAM: "You have just received information that can give you financial freedom for the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few weeks and months than you have ever imagined. Follow the program EXACTLY AS INSTRUCTED. Do Not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report after you have put your name and address in Report #1 and moved others to #2 ...........#5 as instructed above. One of the people you send this to may send out 100,000 or more e-mails and your name will be on every one of them. Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! ****************MORE TESTIMONIALS***************** 'My name is Mitchell. My wife, Jody and I live in Chicago. I am an accountant with a major U.S. Corporation and I make pretty good money. When I received this program I grumbled to Jody about receiving ''junk mail''. I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I ''knew'' it wouldn't work. Jody totally ignored my supposed intelligence and few days later she jumped in with both feet. I made merciless fun of her, and was ready to lay the old ''I told you so'' on her when the thing didn't work. Well, the laugh was on me! Within 3 weeks she had received 50 responses. Within the next 45 days she had received total $ 147,200.00 ......... all cash! I was shocked. I have joined Jody in her ''hobby''. Mitchell Wolf, M.D. , Chicago, Illinois ------------------------------------------------------------ ''Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back''. ''I was surprised when I found my medium size post office box crammed with orders. I made $319,210.00 in the first 12 weeks. The nice thing about this deal is that it does not matter where people live. There simply isn't a better investment with a faster return and so big''. Dan Sondstrom, Alberta, Canada ------------------------------------------------------------ ''I had received this program before. I deleted it, but later I wondered if I should have given it a try. Of course, I had no no idea who to contact to get another copy, so I had to wait until I was e-mailed again by someone else.........11 months passed then it luckily came again...... I did not delete this one! I made more than $490,000 on my first try and all the money came within 22 weeks''. Susan De Suza, New York, N.Y. ------------------------------------------------------------ ''It really is a great opportunity to make relatively easy money with little cost to you. I followed the simple instructions carefully and within 10 days the money started to come in. My first month I made $ 20, 560.00 and by the end of third month my total cash count was $ 362,840.00. Life is beautiful, Thanx to internet''. Fred Dellaca, Westport, New Zealand ------------------------------------------------------------ ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! ================================================== If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection, Washington, D.C. //////////////////////////////////////////////////////////// ONE TIME MAILING, NO NEED TO REMOVE //////////////////////////////////////////////////////////// This message is sent in compliance of the proposed bill SECTION 301. per Section 301, Paragraph (a)(2)(C) of S. 1618. Further transmission to you by the sender of this e- mail may be stopped at no cost to you by sending a reply to: marc5858@usa.com with the word Remove in the subject line. This message is not intended for residents in the State of Washington, screening of addresses has been done to the best of our technical ability. From owner-ietf-pkix Mon Jan 8 06:23:39 2001 Received: from magpie.csie.nctu.edu.tw (root@magpie.csie.nctu.edu.tw [140.113.209.21]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05794 for ; Mon, 8 Jan 2001 06:23:15 -0800 (PST) Received: (from leefy@localhost) by magpie.csie.nctu.edu.tw (8.11.1/8.9.1) id f08ERRJ45827 for ietf-pkix@imc.org; Mon, 8 Jan 2001 22:27:27 +0800 (CST) Date: Mon, 8 Jan 2001 22:27:27 +0800 From: Lee Fu-yuan To: ietf-pkix@imc.org Subject: subscribe Message-ID: <20010108222727.A45816@magpie.csie.nctu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i uth ab43ec31 subscribe ietf-pkix \ Lee Fu-yuan From owner-ietf-pkix Mon Jan 8 06:24:08 2001 Received: from extapps03.intra.dmz ([194.200.144.248]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05861 for ; Mon, 8 Jan 2001 06:24:07 -0800 (PST) From: Jonathan.Tuliani@symbian.com Received: from SymbianUK05.Symbian.com (unverified) by extapps03.intra.dmz (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 8 Jan 2001 14:26:48 +0000 Received: from symbianuk20.symbian.com ([10.170.2.25]) by SymbianUK05.Symbian.com (Lotus Domino Release 5.0.1b (Intl)) with ESMTP id 2001010814271044:16537 ; Mon, 8 Jan 2001 14:27:10 +0000 Subject: Servers for OCSP v1 interoperability testing To: ietf-pkix@imc.org Cc: X-Mailer: Lotus Notes Release 5.0.2c (Intl) 2 February 2000 Message-ID: Date: Mon, 8 Jan 2001 14:27:00 +0000 X-Priority: 3 (Normal) MIME-Version: 1.0 X-MIMETrack: Serialize by Router on SymbianUK20/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 01/08/2001 02:27:00 PM, Itemize by SMTP Server on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 08/01/2001 02:27:10 PM, Serialize by Router on SymbianUK05/Symbian(Release 5.0.1b (Intl)|30 September 1999) at 08/01/2001 02:27:10 PM, Serialize complete at 08/01/2001 02:27:10 PM Content-type: text/plain; charset=us-ascii All, Does anyone currently run an OCSP (v1) server against which we can test our OCSP client implementation? Any help would be much appreciated. Of course, we would be happy to give feedback in exchange. Regards, Jonathan ------------------------- Dr Jonathan Tuliani Jonathan.Tuliani@Symbian.com www.symbian.com ******************************************************************************************************************* Symbian Limited (Co.No.3173352) Registered Office: Sentinel House, 16 Harcourt Street, London, W1H 1DS, UK. This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@symbian.com and delete the message and any attachments accompanying it immediately. Symbian does not accept liability for any corruption, interception, amendment, tampering or viruses occuring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy. ******************************************************************************************************************* From owner-ietf-pkix Mon Jan 8 07:39:33 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13327 for ; Mon, 8 Jan 2001 07:39:33 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA08993; Mon, 8 Jan 2001 10:44:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97888367312331@kahu.cs.auckland.ac.nz> References: <97888367312331@kahu.cs.auckland.ac.nz> Date: Mon, 8 Jan 2001 10:40:10 -0500 To: pgut001@cs.auckland.ac.nz From: Stephen Kent Subject: Re: Basic Cert-2-Directory mapping question Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Peter, I have not read your paper, but the assertion that DNs don't work, without substantiation, seems a bit strong. Certainly when people create arbitrary DNs, without regard to the semantics of directory structure, bad things happen. Also, it is fair to say that the grand, nations as top level directory operators model that X.500 envisioned has not happened, and it unlikely to ever happen in some places, e.g., the U.S. However, the suggestion of hashing a DN and using it as a search key always seems to have the problem of breaking the knowledge reference part of X.500 (and of all, analogous, tree structure, distributed directories), which rely on looking at name structure to figure out where to look for an entry that is not local. finally, the IETF has had a standard means of encoding a DNS name as a DN for several years, which suggests that there is at least one scheme that would work. Steve From owner-ietf-pkix Mon Jan 8 08:29:58 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16913 for ; Mon, 8 Jan 2001 08:29:57 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA16649; Mon, 8 Jan 2001 11:34:13 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 8 Jan 2001 11:30:14 -0500 To: "Michael Myers" From: Stephen Kent Subject: RE: DPD & DPV requirements - Let us Recurse Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Mike, >Steve, > >It is precisely this overlap that led to the existence and architecture of >the current DPV and DPD drafts, namely that a DPD server was simply tapping >into the path discovery logic that a DPV server must execute. > >Care must taken however as we go forward with high-level requirements to >ensure that a DPD server delivers up that path a DPV server would have used. >Or are we otherwise comfortable that some ambiguity may emerge? This was an >open question that we as DPV and DPD authors were and are grappling with. We'll see what the group says, but for now I am assuming that ASN.1-based DPD and DPV servers will exhibit considerable mechanism and maybe message format overlap. Steve From owner-ietf-pkix Mon Jan 8 08:32:59 2001 Received: from indy.gradient.com (root@indy.gradient.com [192.92.110.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17634 for ; Mon, 8 Jan 2001 08:32:59 -0800 (PST) Received: from bigbird.gradient.com (bigbird.gradient.com [192.92.110.50]) by indy.gradient.com (8.9.1a/8.9.1) with ESMTP id LAA23122; Mon, 8 Jan 2001 11:37:48 -0500 (EST) Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10) id ; Mon, 8 Jan 2001 11:36:18 -0500 Message-ID: <899128A30EEDD1118FC900A0C9C74A34BA9525@bigbird.gradient.com> From: Hal Lockhart To: "'Richard Levitte at Celo'" , Anders Rundgren Cc: PKIX-List , Philip Hallam-Baker Subject: RE: Basic Cert-2-Directory mapping question Date: Mon, 8 Jan 2001 11:36:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" > I've always wondered what those "Kerberos Certificates" are, > or do you mean > tickets? They have nothing to do with PKI, since Kerberos > doesn't use PKC. This is not true. The Kerberos working group has developed a scheme for allowing an initial PKI handshake in place of the original symmetric key scheme. Once the exchange is over, symmetric key-based tickets are used as always. The spec is: http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-pk-init-12.txt certificates may or may not be used. If they are used, there are special requirements. For example, the DN must correspond to a Kerberos name/realm. Hal ======================================================= Harold W. Lockhart Entegrity Solutions 2 Mount Royal Avenue Marlborough, MA 01752 USA V: 1-508-624-9600 x 260 hal.lockhart@entegrity.com F: 1-508-229-0338 www.entegrity.com ======================================================= From owner-ietf-pkix Mon Jan 8 08:59:26 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20352 for ; Mon, 8 Jan 2001 08:59:25 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA21077; Mon, 8 Jan 2001 12:04:09 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200101081151.MAA16511@emeriau.edelweb.fr> References: <200101081151.MAA16511@emeriau.edelweb.fr> Date: Mon, 8 Jan 2001 12:02:45 -0500 To: Peter Sylvester From: Stephen Kent Subject: RE: DPD & DPV requirements - Let us Recurse Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Peter, > > > > Returning info that explains why a server believes that the returned > > data supports validation is an interesting notion. The first example > > of that I saw was in work performed by colleagues here at BBN, on a > > project calls IOS, in the early 90s, where servers did that. But, I > > think this is still an R&D topic for now, not yet ready for > > standardization. > >Isn't part of this 'interesting notion' the cert chain itself. The >certificate chain return by a DPV server is the chain that has >been used to validate it, and the server believes that this chain >is valid. The interesting part of the notion is using a common representation, which can then be translated into human readable language, to express the validation chain assertions, especially when the validation process is incomplete, or not exact, e.g., outdated CRLs. >If the service is implemented using some relaying, such that a >server becomes a client of someone else, what research problem >is there that the intermediate server/client wants to provide the >results? If for the initial client the result of the validation >becomes something that can be stored somewhere, e.g. similar to >an OCSP response stored in the SMIME/ETSI signature format stuff, >then essentially this client becomes an intermediate server for >another verifier of the enhanced signature. Well, there is already a suggestion (that I need to look into further) that proxied OCSP responses may pose problems. if one has to assemble a mix of serial and parallel signed responses to satisfy a query, that adds complexity both syntactically and semantically. But, for the most part, my allusion to R&D issues has to do with the problems that arise when the revocation status data is not quite perfect and one wants to respond with something more that "NP" and with the human interface presentation issues. Steve From owner-ietf-pkix Mon Jan 8 10:22:37 2001 Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23144 for ; Mon, 8 Jan 2001 10:22:35 -0800 (PST) Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA07059; Mon, 8 Jan 2001 19:27:24 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 8 Jan 2001 19:27:25 +0100 (MET) Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA21022; Mon, 8 Jan 2001 19:27:22 +0100 (MET) From: Peter Sylvester Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA16605; Mon, 8 Jan 2001 19:27:22 +0100 (MET) Date: Mon, 8 Jan 2001 19:27:22 +0100 (MET) Message-Id: <200101081827.TAA16605@emeriau.edelweb.fr> To: Peter.Sylvester@EdelWeb.fr, kent@bbn.com Subject: RE: DPD & DPV requirements - Let us Recurse Cc: ietf-pkix@imc.org > > Peter, > > > > > > > Returning info that explains why a server believes that the returned > > > data supports validation is an interesting notion. The first example > > > of that I saw was in work performed by colleagues here at BBN, on a > > > project calls IOS, in the early 90s, where servers did that. But, I > > > think this is still an R&D topic for now, not yet ready for > > > standardization. > > > >Isn't part of this 'interesting notion' the cert chain itself. The > >certificate chain return by a DPV server is the chain that has > >been used to validate it, and the server believes that this chain > >is valid. > > The interesting part of the notion is using a common representation, > which can then be translated into human readable language, to express > the validation chain assertions, especially when the validation > process is incomplete, or not exact, e.g., outdated CRLs. There are several interesting things IMHO: - what statements are to be returned, - whether ALL elements that contribute to a decision are returned. - how can they be translated into whatever a client tells. There exist already a data structure which is used in other protocols, i.e. PKIStatus, that can be used to carry additional information. It just seems to me that if one starts to create a DPV response that by itself already contains information about whether or not the certificate is valid, then one should try to return all the information that might be appropriate. This includes CRLs, OCSP reponses, statement expressed in PKIStatus or an attribute certificate. A validation server makes it decision in some linear way, or at least it can assemble all the results in a linear way. Thus, a simple list of statements, "I've looked at this", "I consider it to be valid/invalid/incomplete" seems to me a good starting point. A cert chain is just a subset of that. > > Well, there is already a suggestion (that I need to look into > further) that proxied OCSP responses may pose problems. if one has to > assemble a mix of serial and parallel signed responses to satisfy a > query, that adds complexity both syntactically and semantically. But, > for the most part, my allusion to R&D issues has to do with the > problems that arise when the revocation status data is not quite > perfect and one wants to respond with something more that "NP" and > with the human interface presentation issues. Just because it create complexity, this is one reason that these things are discussed and standardized. I have just given a provoking example of parallel or enbedded signatures by borrowing some ideas from CMS; it may be sufficient that a relaying server just embeds a response from another server, and parallel CMS signedData are not necessary. What do you mean by revocation status not quite perfect? A server makes a desision, and tells what it had looked at, it may happen that another server verifier looks at the same data in a different way, and comes to another conclusion; this tru independant of whether the first returns its justifications or not. One entity might validate a cert chain, another might not, etc. Returning as much as possible data about why one decision has been made does not change that. If a client has a user interface to explain a server decision, it seems necessary anyway to display certificates, elements on a CRL, OCSP reponses, PKIStatus data. We already have the problem of user interfaces of certificate and CRL displays, and also of how to display responses from a OCSP server, or from the new services to be standardized. But do we actually care? But: I don't see in other pkix standards a description of about how a certificate chain has to be presented or even a single certificate. What seems useful to me is to specify a list of elements that may be supposed to be presented to users. Such a list should be a simple as possible, contain a small number of different data type that allow to express a large set of situations, so that we don't have to add new stuff each 6 months or 3 years. We have already *MANY* standards that return 'status information' in different ways. One question here would be: Is it more appropriate to use a new textual format like in SCVP or something like PKIStatus as used in several standards maybe accompanied by OCSP responses? Peter From owner-ietf-pkix Mon Jan 8 10:23:58 2001 Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23315 for ; Mon, 8 Jan 2001 10:23:57 -0800 (PST) Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id NAA17324 for ; Mon, 8 Jan 2001 13:28:20 -0500 (EST) Message-Id: <200101081828.NAA17320@stingray.missi.ncsc.mil> Date: Mon, 8 Jan 2001 13:29:47 -0500 (EST) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: Basic Cert-2-Directory mapping question To: ietf-pkix@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hS5xcvaUDuw0+geNhWJ/6A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Peter, I thought what Anders asked was: "given an arbitrary DN, how do I find a cert stored somewhere in an arbitrary collection of independently-managed X.500 or LDAP directory servers", not: "given an arbitrary DN, how do I fetch a cert which I already have a copy of, stored on my own server." It shouldn't be at all surprising that a db or ISAM store, with or without an RDBMS layer above, and with or without a DAP or LDAP access layer, is a reasonable way to store certs on your own machine. [1] Developing a DN-schema-independent local retrieval mechanism is all well and good, but it doesn't solve the registration problem, and as a result, it doesn't help you to find a cert which you don't already have. The real problem with finding and using certs which are stored elsewhere is the reverse of what you stated, namely: cause: people fill DNs with whatever they like, and therefore effect: those particular DN's don't work (i.e. they don't solve Anders' question because they aren't valid addresses in a global address space.) Instead of saying "DN's don't work", with a footnote, it would be more accurate to say "people choose not to use working DNs". The Web works only because every Internet URL begins with DNS-registered name. Something related to your third approach below, requiring all certs and directories to use a standard DN registration scheme, may be extraordinarily painful, but it's better than ad-hoc workarounds using other certificate fields. If PKI consumers and providers aren't willing to standardise within a global DN space, we will have only islands of interoperability. [2] Dave [1] You could also just use the native filesystem, storing each cert as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based flat folder. This works as long as you keep secondary indices synchronised with the folder contents, or if you don't need secondary indices at all. [2] Blue sky thought: it might be nice if there were a "Registration Point (RP)" DN attribute which would be analogous to the hostname portion of a URL. The RP attribute would be the first RDN of a DN, and the RP value would be an OID identifying the registration authority and the schema for the remainder of the DN. In principle, this is no better (except for being less verbose) than current DNs, but in practice OIDs are better managed - people actually choose to follow OID registration procedures instead of just poaching in somebody else's space. > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > The main problem is that DN's don't work [0], so you end up with ones which > people have filled with whatever they feel like, odd things required by cert > profiles or signature laws or organisational constraints or whatever which > generally don't fit any known directory schema. The current approaches to > this problem if you're using a directory as a cert store are: > > - Continually update the directory schema to match any new DNs which appear > until the directory admin(s) go insane (hi Paul :-). > - Create aliases in the directory mapping DNs in certs to the (fixed) > directory schema. > - Force all certs to use the schema used in the directory (someone who's > been through this one once described it to me as "extraordinarily painful"). > - Use the directory DN to identify the cert owner and store the cert as just > another attribute, with the actual cert DN ignored. > - (There may be more, since the whole thing is badly broken there are > probably lots of workarounds being used. If anyone knows of others > please let me know) > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > the DN as a blob and hash it down to a fixed-length value which you use as a > key to look up the cert in an RDBMS or something like dbm if you don't need > the full RDBMS functionality [1]. This approach just plain works no matter > how garbled and broken the DN is. From owner-ietf-pkix Mon Jan 8 10:27:22 2001 Received: from mail-fwd.verio-web.com ([161.58.16.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24145 for ; Mon, 8 Jan 2001 10:27:21 -0800 (PST) Received: from 161.58.117.181 (161.58.117.181) by mail11b.verio-web.com (RS ver 1.0.57s) with SMTP id 017831031; Mon, 8 Jan 2001 13:31:46 -0500 (EST) Received: from caveosystems.com (adsl-141-154-28-165.bostma.adsl.bellatlantic.net [141.154.28.165]) by os390.caveosystems.com (8.9.3/8.9.3) with ESMTP id NAA02748; Mon, 8 Jan 2001 13:33:11 -0500 Message-ID: <3A5A08BB.5A888EF7@caveosystems.com> Date: Mon, 08 Jan 2001 13:36:43 -0500 From: Rich Salz X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dr S N Henson CC: PKIX-List Subject: Re: OCSP authorized responder clarification. References: <3A59B3B3.EB5B7B3B@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 > A certain CA issues end user certificates signed by an intermediate CA > which is in turn signed by the root CA. So do you mean this Root->Certain CA->End-Entity \->Responder-> Now a client has an EE cert and wants to know if Responder is authorized? Then you are right, there is nothing inherent in the PKI. A client would have to treat it as case two, at the top of page 2 of RFC 2560 -- a trusted responder whose key it trusts (because it has out of band information.) I can think of two ways to strengthen the trust decision for a client. First, the "Certain CA" could include an AIA in the end-entity certs that points to where the Responder is listening. Second, the Certain CA could on its own cross-certify the Responder and distribute the cert that *IT* signed. The root might also issue the Responder cert using the same DN as it did for the Certain CA. (Just as some vendors like(d) to sure DN's for signing and CRL-issuing.) The first method only provides a hint, since no crypto rigor is involved, just the foundation of sand that is DNS. The second could be seen as voiding your hypothesis. In my limited experience of OCSP deployment, the client trust issue is almost always addressed by saying "trust this responder" analogous to the way the client is told to "just trust this root." /r$ From owner-ietf-pkix Mon Jan 8 11:00:32 2001 Received: from pigeon.verisign.com (pigeon.verisign.com [208.206.241.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27400 for ; Mon, 8 Jan 2001 11:00:32 -0800 (PST) Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by pigeon.verisign.com (8.9.3/BCH1.7.1) with ESMTP id LAA22303 for ; Mon, 8 Jan 2001 11:00:52 -0800 (PST) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Jan 2001 11:05:25 -0800 Message-ID: From: Alex Deacon To: ietf-pkix@imc.org Cc: cmc-interop Subject: CMC Interop testing... Date: Mon, 8 Jan 2001 11:05:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C079A5.F3213B60" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C079A5.F3213B60 Content-Type: text/plain; charset="iso-8859-1" VeriSign is seeking to conduct interoperability testing with individuals and/or organizations who have (or are working on) CMC implementations. If you are interested in participating and would like further details and information, please send email to cmc-interop@verisign.com Regards, Alex ------_=_NextPart_001_01C079A5.F3213B60 Content-Type: text/html; charset="iso-8859-1"
 
VeriSign is seeking to conduct interoperability testing with individuals and/or organizations who have (or are working on) CMC implementations. 
 
If you are interested in participating and would like further details and information, please send email to
 
 
Regards,
Alex
 
 
------_=_NextPart_001_01C079A5.F3213B60-- From owner-ietf-pkix Mon Jan 8 12:30:44 2001 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02227 for ; Mon, 8 Jan 2001 12:30:43 -0800 (PST) Received: from survis.surfnet.nl ([192.87.108.3] helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 14Fj0w-0007hg-00; Mon, 8 Jan 2001 21:35:34 +0100 Message-ID: <3A5A24B8.4E3DB4EC@surfnet.nl> Date: Mon, 08 Jan 2001 21:36:08 +0100 From: Janus Liebregts Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "David P. Kemp" CC: ietf-pkix@imc.org, tf-lsd@terena.nl, pki-coord@terena.nl Subject: Re: Basic Cert-2-Directory mapping question References: <200101081828.NAA17320@stingray.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I fully agree with David. I don't agree that using a standard DN registration scheme, is extraordinarily painful. Currently we, SURFnet (as the dutch National Research Network) use two simple rules for our pki-domain (Higher Education & Research): 1. only certify CA's using DN's as registered within our (LDAP)domain using the rules of our Naming Authority. 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified. with this we build our pki according to the ldap-namespace ACCORDING to SURFnet. We claim to be the Naming Authority for the C=NL namespace... Probably every country & state have their own laws about naming organisations, in Holland the Chambres of Commerce have such a (delegated) task. Every country (C= or state c=US, ST=) should have some sort of naming authority and name-registration is already taken place. But how to make available these authorative Naming databases in a (LDAP) way, to be the authorative name for certification.... For our community we have made available a pki-ldap cookbook which describes a method how to organise your DIT and how to store pki-related material http://ldap.gigacorp.nl/pkildap.html Janus Liebregts SURFnet "David P. Kemp" wrote: > > Peter, > > I thought what Anders asked was: > "given an arbitrary DN, how do I find a cert stored somewhere in an > arbitrary collection of independently-managed X.500 or LDAP directory > servers", > > not: > "given an arbitrary DN, how do I fetch a cert which I already have a > copy of, stored on my own server." > > It shouldn't be at all surprising that a db or ISAM store, with or > without an RDBMS layer above, and with or without a DAP or LDAP access > layer, is a reasonable way to store certs on your own machine. [1] > Developing a DN-schema-independent local retrieval mechanism is all > well and good, but it doesn't solve the registration problem, and as a > result, it doesn't help you to find a cert which you don't already > have. > > The real problem with finding and using certs which are stored > elsewhere is the reverse of what you stated, namely: > > cause: people fill DNs with whatever they like, and therefore > effect: those particular DN's don't work (i.e. they don't solve > Anders' question because they aren't valid addresses in > a global address space.) > > Instead of saying "DN's don't work", with a footnote, it would > be more accurate to say "people choose not to use working DNs". > > The Web works only because every Internet URL begins with > DNS-registered name. Something related to your third approach below, > requiring all certs and directories to use a standard DN registration > scheme, may be extraordinarily painful, but it's better than ad-hoc > workarounds using other certificate fields. If PKI consumers and > providers aren't willing to standardise within a global DN space, we > will have only islands of interoperability. [2] > > Dave > > [1] You could also just use the native filesystem, storing each cert > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based > flat folder. This works as long as you keep secondary indices > synchronised with the folder contents, or if you don't need secondary > indices at all. > > [2] Blue sky thought: it might be nice if there were a "Registration > Point (RP)" DN attribute which would be analogous to the hostname > portion of a URL. The RP attribute would be the first RDN of a > DN, and the RP value would be an OID identifying the registration > authority and the schema for the remainder of the DN. In principle, > this is no better (except for being less verbose) than current DNs, but > in practice OIDs are better managed - people actually choose to follow > OID registration procedures instead of just poaching in somebody else's > space. > > > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > > > The main problem is that DN's don't work [0], so you end up with ones which > > people have filled with whatever they feel like, odd things required by cert > > profiles or signature laws or organisational constraints or whatever which > > generally don't fit any known directory schema. The current approaches to > > this problem if you're using a directory as a cert store are: > > > > - Continually update the directory schema to match any new DNs which appear > > until the directory admin(s) go insane (hi Paul :-). > > - Create aliases in the directory mapping DNs in certs to the (fixed) > > directory schema. > > - Force all certs to use the schema used in the directory (someone who's > > been through this one once described it to me as "extraordinarily > painful"). > > - Use the directory DN to identify the cert owner and store the cert as just > > another attribute, with the actual cert DN ignored. > > - (There may be more, since the whole thing is badly broken there are > > probably lots of workarounds being used. If anyone knows of others > > please let me know) > > > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > > the DN as a blob and hash it down to a fixed-length value which you use as a > > key to look up the cert in an RDBMS or something like dbm if you don't need > > the full RDBMS functionality [1]. This approach just plain works no matter > > how garbled and broken the DN is. From owner-ietf-pkix Mon Jan 8 12:38:31 2001 Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA02944 for ; Mon, 8 Jan 2001 12:38:30 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by maila.telia.com (8.9.3/8.9.3) with ESMTP id VAA13409; Mon, 8 Jan 2001 21:43:20 +0100 (CET) Received: from mega (t6o69p100.telia.com [213.64.110.220]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f08KhIl07274; Mon, 8 Jan 2001 21:43:18 +0100 (CET) Message-ID: <00a201c079b3$69b17bc0$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Janus Liebregts" Cc: , , References: <200101081828.NAA17320@stingray.missi.ncsc.mil> <3A5A24B8.4E3DB4EC@surfnet.nl> Subject: Re: Basic Cert-2-Directory mapping question Date: Mon, 8 Jan 2001 21:41:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id MAA02948 Janus, Unforntunately your certificates will not be useful for Win2K local authentication due to this mapping problem. Does Novell offer a more flexible use of TTP-issued certificates without requiring the RP to use a 1-2-1 DN versus directory mapping? /anders > I fully agree with David. > > I don't agree that using a standard DN registration scheme, is > extraordinarily painful. Currently we, SURFnet (as the dutch National > Research Network) use two simple rules for our pki-domain (Higher > Education & Research): > > 1. only certify CA's using DN's as registered within our (LDAP)domain > using the rules of our Naming Authority. > 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified. > > with this we build our pki according to the ldap-namespace ACCORDING to > SURFnet. We claim to be the Naming Authority for the C=NL namespace... > > Probably every country & state have their own laws about naming > organisations, in Holland the Chambres of Commerce have such a > (delegated) task. Every country (C= or state c=US, ST=) should have some > sort of naming authority and name-registration is already taken place. > But how to make available these authorative Naming databases in a (LDAP) > way, to be the authorative name for certification.... > > For our community we have made available a pki-ldap cookbook which > describes a method how to organise your DIT and how to store pki-related > material http://ldap.gigacorp.nl/pkildap.html > > Janus Liebregts > SURFnet > > > > > "David P. Kemp" wrote: > > > > Peter, > > > > I thought what Anders asked was: > > "given an arbitrary DN, how do I find a cert stored somewhere in an > > arbitrary collection of independently-managed X.500 or LDAP directory > > servers", > > > > not: > > "given an arbitrary DN, how do I fetch a cert which I already have a > > copy of, stored on my own server." > > > > It shouldn't be at all surprising that a db or ISAM store, with or > > without an RDBMS layer above, and with or without a DAP or LDAP access > > layer, is a reasonable way to store certs on your own machine. [1] > > Developing a DN-schema-independent local retrieval mechanism is all > > well and good, but it doesn't solve the registration problem, and as a > > result, it doesn't help you to find a cert which you don't already > > have. > > > > The real problem with finding and using certs which are stored > > elsewhere is the reverse of what you stated, namely: > > > > cause: people fill DNs with whatever they like, and therefore > > effect: those particular DN's don't work (i.e. they don't solve > > Anders' question because they aren't valid addresses in > > a global address space.) > > > > Instead of saying "DN's don't work", with a footnote, it would > > be more accurate to say "people choose not to use working DNs". > > > > The Web works only because every Internet URL begins with > > DNS-registered name. Something related to your third approach below, > > requiring all certs and directories to use a standard DN registration > > scheme, may be extraordinarily painful, but it's better than ad-hoc > > workarounds using other certificate fields. If PKI consumers and > > providers aren't willing to standardise within a global DN space, we > > will have only islands of interoperability. [2] > > > > Dave > > > > [1] You could also just use the native filesystem, storing each cert > > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based > > flat folder. This works as long as you keep secondary indices > > synchronised with the folder contents, or if you don't need secondary > > indices at all. > > > > [2] Blue sky thought: it might be nice if there were a "Registration > > Point (RP)" DN attribute which would be analogous to the hostname > > portion of a URL. The RP attribute would be the first RDN of a > > DN, and the RP value would be an OID identifying the registration > > authority and the schema for the remainder of the DN. In principle, > > this is no better (except for being less verbose) than current DNs, but > > in practice OIDs are better managed - people actually choose to follow > > OID registration procedures instead of just poaching in somebody else's > > space. > > > > > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > > > > > The main problem is that DN's don't work [0], so you end up with ones which > > > people have filled with whatever they feel like, odd things required by cert > > > profiles or signature laws or organisational constraints or whatever which > > > generally don't fit any known directory schema. The current approaches to > > > this problem if you're using a directory as a cert store are: > > > > > > - Continually update the directory schema to match any new DNs which appear > > > until the directory admin(s) go insane (hi Paul :-). > > > - Create aliases in the directory mapping DNs in certs to the (fixed) > > > directory schema. > > > - Force all certs to use the schema used in the directory (someone who's > > > been through this one once described it to me as "extraordinarily > > painful"). > > > - Use the directory DN to identify the cert owner and store the cert as just > > > another attribute, with the actual cert DN ignored. > > > - (There may be more, since the whole thing is badly broken there are > > > probably lots of workarounds being used. If anyone knows of others > > > please let me know) > > > > > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > > > the DN as a blob and hash it down to a fixed-length value which you use as a > > > key to look up the cert in an RDBMS or something like dbm if you don't need > > > the full RDBMS functionality [1]. This approach just plain works no matter > > > how garbled and broken the DN is. From owner-ietf-pkix Mon Jan 8 13:55:54 2001 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA06512 for ; Mon, 8 Jan 2001 13:55:54 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Jan 2001 15:00:07 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 08 Jan 2001 14:56:58 -0700 From: "Bob Jueneman" To: , Subject: Re: Basic Cert-2-Directory mapping question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA06513 This has been a train wreck about the happen for nearly ten years. It's like watching "The Fugitive" one still frame at a time. The NADF tried to address this problem and gave up, and PKIX hasn't even tried. To quote Pogo, "We have met the enemy, and they is us." The first problem is not the DN -- that's secondary. As you correctly state, the first problem is knowing the location of a directory service provider that is supposed to contain the DN, so we can at least get to the right point and start browsing around for a certificate. I don't know that we need to name a Registration Point for a DN -- that might get all tangled up in naming issues, who has the right to name someone, etc. What I proposed more than a year ago, and what I think you are in essence saying, was that DNs in certificate should really be URLs, in essentially the same fashion as CRLDistributionPoints are. I don't particularly care what the exact syntax is -- something like ldap://ldap.mycompany.com/c=us, ....cn="My Name" would do just fine, I think, but I'll let other people debate that. Once we finally locate the directory, then we can have all of the religious arguments about my RDN schema vs. yours, and why yours is wrong and mine is the only one that any right-thinking system administer could possibly support, yada, yada, yada. Unfortunately, since the contents of PKI certificates are generally viewed as supposedly providing some degree of specificity with regard to a geopolitical identification and location of an end-entity, those schemas sometimes conflict with directory structures which are often organized around completely different principles, such as more or less reflecting the network structure or topology or span of control issues. But those issues, although certainly important, could reasonably be resolved by aliases, etc., no matter how painful But if a consumer of certificates doesn't even know where the directory can be found to start looking, then schema problems won't matter. Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software >>> "David P. Kemp" 01/08/01 11:29AM >>> Peter, I thought what Anders asked was: "given an arbitrary DN, how do I find a cert stored somewhere in an arbitrary collection of independently-managed X.500 or LDAP directory servers", not: "given an arbitrary DN, how do I fetch a cert which I already have a copy of, stored on my own server." It shouldn't be at all surprising that a db or ISAM store, with or without an RDBMS layer above, and with or without a DAP or LDAP access layer, is a reasonable way to store certs on your own machine. [1] Developing a DN-schema-independent local retrieval mechanism is all well and good, but it doesn't solve the registration problem, and as a result, it doesn't help you to find a cert which you don't already have. The real problem with finding and using certs which are stored elsewhere is the reverse of what you stated, namely: cause: people fill DNs with whatever they like, and therefore effect: those particular DN's don't work (i.e. they don't solve Anders' question because they aren't valid addresses in a global address space.) Instead of saying "DN's don't work", with a footnote, it would be more accurate to say "people choose not to use working DNs". The Web works only because every Internet URL begins with DNS-registered name. Something related to your third approach below, requiring all certs and directories to use a standard DN registration scheme, may be extraordinarily painful, but it's better than ad-hoc workarounds using other certificate fields. If PKI consumers and providers aren't willing to standardise within a global DN space, we will have only islands of interoperability. [2] Dave [1] You could also just use the native filesystem, storing each cert as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based flat folder. This works as long as you keep secondary indices synchronised with the folder contents, or if you don't need secondary indices at all. [2] Blue sky thought: it might be nice if there were a "Registration Point (RP)" DN attribute which would be analogous to the hostname portion of a URL. The RP attribute would be the first RDN of a DN, and the RP value would be an OID identifying the registration authority and the schema for the remainder of the DN. In principle, this is no better (except for being less verbose) than current DNs, but in practice OIDs are better managed - people actually choose to follow OID registration procedures instead of just poaching in somebody else's space. > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > The main problem is that DN's don't work [0], so you end up with ones which > people have filled with whatever they feel like, odd things required by cert > profiles or signature laws or organisational constraints or whatever which > generally don't fit any known directory schema. The current approaches to > this problem if you're using a directory as a cert store are: > > - Continually update the directory schema to match any new DNs which appear > until the directory admin(s) go insane (hi Paul :-). > - Create aliases in the directory mapping DNs in certs to the (fixed) > directory schema. > - Force all certs to use the schema used in the directory (someone who's > been through this one once described it to me as "extraordinarily painful"). > - Use the directory DN to identify the cert owner and store the cert as just > another attribute, with the actual cert DN ignored. > - (There may be more, since the whole thing is badly broken there are > probably lots of workarounds being used. If anyone knows of others > please let me know) > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > the DN as a blob and hash it down to a fixed-length value which you use as a > key to look up the cert in an RDBMS or something like dbm if you don't need > the full RDBMS functionality [1]. This approach just plain works no matter > how garbled and broken the DN is. From owner-ietf-pkix Mon Jan 8 14:04:10 2001 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA07190 for ; Mon, 8 Jan 2001 14:04:10 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Jan 2001 15:08:32 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 08 Jan 2001 15:08:24 -0700 From: "Bob Jueneman" To: , Cc: , , Subject: Re: Basic Cert-2-Directory mapping question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA07192 Unfortunately, the model you cite, with naming authorities that are truly authoritative, and in addition a monopoly, is in fact NOT the case the United States, and in a number of other countries in the world as well. If the government decrees what DNs are allowable, and perhaps where they have to be stored, then the problem is certainly simplified. Unfortunately, usually isn't the case. Bob >>> Janus Liebregts 01/08/01 01:36PM >>> I fully agree with David. I don't agree that using a standard DN registration scheme, is extraordinarily painful. Currently we, SURFnet (as the dutch National Research Network) use two simple rules for our pki-domain (Higher Education & Research): 1. only certify CA's using DN's as registered within our (LDAP)domain using the rules of our Naming Authority. 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified. with this we build our pki according to the ldap-namespace ACCORDING to SURFnet. We claim to be the Naming Authority for the C=NL namespace... Probably every country & state have their own laws about naming organisations, in Holland the Chambres of Commerce have such a (delegated) task. Every country (C= or state c=US, ST=) should have some sort of naming authority and name-registration is already taken place. But how to make available these authorative Naming databases in a (LDAP) way, to be the authorative name for certification.... For our community we have made available a pki-ldap cookbook which describes a method how to organise your DIT and how to store pki-related material http://ldap.gigacorp.nl/pkildap.html Janus Liebregts SURFnet "David P. Kemp" wrote: > > Peter, > > I thought what Anders asked was: > "given an arbitrary DN, how do I find a cert stored somewhere in an > arbitrary collection of independently-managed X.500 or LDAP directory > servers", > > not: > "given an arbitrary DN, how do I fetch a cert which I already have a > copy of, stored on my own server." > > It shouldn't be at all surprising that a db or ISAM store, with or > without an RDBMS layer above, and with or without a DAP or LDAP access > layer, is a reasonable way to store certs on your own machine. [1] > Developing a DN-schema-independent local retrieval mechanism is all > well and good, but it doesn't solve the registration problem, and as a > result, it doesn't help you to find a cert which you don't already > have. > > The real problem with finding and using certs which are stored > elsewhere is the reverse of what you stated, namely: > > cause: people fill DNs with whatever they like, and therefore > effect: those particular DN's don't work (i.e. they don't solve > Anders' question because they aren't valid addresses in > a global address space.) > > Instead of saying "DN's don't work", with a footnote, it would > be more accurate to say "people choose not to use working DNs". > > The Web works only because every Internet URL begins with > DNS-registered name. Something related to your third approach below, > requiring all certs and directories to use a standard DN registration > scheme, may be extraordinarily painful, but it's better than ad-hoc > workarounds using other certificate fields. If PKI consumers and > providers aren't willing to standardise within a global DN space, we > will have only islands of interoperability. [2] > > Dave > > [1] You could also just use the native filesystem, storing each cert > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based > flat folder. This works as long as you keep secondary indices > synchronised with the folder contents, or if you don't need secondary > indices at all. > > [2] Blue sky thought: it might be nice if there were a "Registration > Point (RP)" DN attribute which would be analogous to the hostname > portion of a URL. The RP attribute would be the first RDN of a > DN, and the RP value would be an OID identifying the registration > authority and the schema for the remainder of the DN. In principle, > this is no better (except for being less verbose) than current DNs, but > in practice OIDs are better managed - people actually choose to follow > OID registration procedures instead of just poaching in somebody else's > space. > > > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > > > The main problem is that DN's don't work [0], so you end up with ones which > > people have filled with whatever they feel like, odd things required by cert > > profiles or signature laws or organisational constraints or whatever which > > generally don't fit any known directory schema. The current approaches to > > this problem if you're using a directory as a cert store are: > > > > - Continually update the directory schema to match any new DNs which appear > > until the directory admin(s) go insane (hi Paul :-). > > - Create aliases in the directory mapping DNs in certs to the (fixed) > > directory schema. > > - Force all certs to use the schema used in the directory (someone who's > > been through this one once described it to me as "extraordinarily > painful"). > > - Use the directory DN to identify the cert owner and store the cert as just > > another attribute, with the actual cert DN ignored. > > - (There may be more, since the whole thing is badly broken there are > > probably lots of workarounds being used. If anyone knows of others > > please let me know) > > > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > > the DN as a blob and hash it down to a fixed-length value which you use as a > > key to look up the cert in an RDBMS or something like dbm if you don't need > > the full RDBMS functionality [1]. This approach just plain works no matter > > how garbled and broken the DN is. From owner-ietf-pkix Mon Jan 8 14:44:02 2001 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA09823 for ; Mon, 8 Jan 2001 14:44:02 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 08 Jan 2001 15:48:18 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Mon, 08 Jan 2001 15:48:09 -0700 From: "Bob Jueneman" To: Cc: Subject: Re: Basic Cert-2-Directory mapping question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA09824 >>> "Anders Rundgren" 01/08/01 01:41PM >>> Janus, >Unforntunately your certificates will not be useful for Win2K local authentication due to this mapping problem. >Does Novell offer a more flexible use of TTP-issued certificates without requiring the RP to use a 1-2-1 DN versus directory mapping? Sorry, I don't think we have any magic bullet in this space yet either. For those RP applications that matter, typically applications that are authenticating a user to the directory itself, perhaps in order to authenticate themselves to other resources, we tend to require a unique 1:1 mapping between the DN in the certificate and the DN of the directory. Of course the customer, or perhaps one of our consulting partners, may develop more complex solutions to fit particular requirements. How we get them into the directory in the first place is one of those infamous "local matters". The real telling issue is when you start to go beyond the intranet, and launch into the extranet or internet space. In the intranet space, it generally isn't too difficult to persuade the CA to issue certificate with the right schema, or to modify your directory schema to fit that of the PKI vendor or CA. What you do with a bunch of certificates from different CAs and/or toolkit vendors, none of which necessarily match the schema of your directory, is still an unsolved problem. We've started down the path of non-global schemas, and we have some other solutions that involve DirXML, which is a way of synchronizing two directories and/or databases via XML, but the basic problem is still with us. Yes, you could arbitrarily store the certificate somewhere, using for example the keyID a hash of the public key, or perhaps of the certificate itself, but is that what we really want to do? Maybe I'm making too big a point of this, but I don't necessarily want to import your certificate into MY directory. Instead, I think that I want to retrieve your certificate from your directory, or perhaps your CA's directory, where ever that might be. If I don't have to actually import the cert, most of these schema issues tend to go away. BTW, Tom Gindin just asked me why pkixrep didn't solve that problem, and I confess that I am clueless about that spec, so perhaps I've missed something fundamental here. But at the risk of oversimplifying, when it comes to extranet access, my preference is to base access control decisions on role-based criteria such as are embodied in the Novell Security Attributes, and to AUDIT the action of that user based on the information provided in his certificate, whatever that might be, assuming I have validated and accepted it. Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software. From owner-ietf-pkix Mon Jan 8 15:15:01 2001 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10529 for ; Mon, 8 Jan 2001 15:14:59 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id MAA07786 for ; Tue, 9 Jan 2001 12:19:51 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97899599117616>; Tue, 9 Jan 2001 12:19:51 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Re: Basic Cert-2-Directory mapping question Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Tue, 9 Jan 2001 12:19:51 (NZDT) Message-ID: <97899599117616@kahu.cs.auckland.ac.nz> Stephen Kent writes: >I have not read your paper, but the assertion that DNs don't work, without >substantiation, seems a bit strong. Certainly when people create arbitrary >DNs, without regard to the semantics of directory structure, bad things >happen. Also, it is fair to say that the grand, nations as top level >directory operators model that X.500 envisioned has not happened, and it >unlikely to ever happen in some places, e.g., the U.S. However, the >suggestion of hashing a DN and using it as a search key always seems to have >the problem of breaking the knowledge reference part of X.500 (and of all, >analogous, tree structure, distributed directories), which rely on looking at >name structure to figure out where to look for an entry that is not local. This is a somewhat circular argument, that if you have a DN which has been artificially constructed to be meaningful it will in fact be meaningful in locating a cert. In practice this never works except in the special case I mentioned earlier where everyone has been forced (on pain of pain) to use some fixed schema for their DN's. Consider for example finding one of the certs I've acquired over time for testing purposes (most of them have probably expired by now). Looking at my email address you'd start with C=NZ, and then perhaps O=Auckland University, or maybe University of Auckland, or perhaps University of New Zealand with another O=Auckland (the last one's definitely wrong, but non-NZers may not know that). After that it gets tricky, is it OU=Computer Science, Computer Science Department, Department of Computer Science, CompSci, CS, or even Mathematics and /School of Mathematics and ../Faculty of... with another OU specifying the department? (I've just checked and it's currently "School of Mathematical and Inforation Sciences", I'm sure if I asked 10 people here I'd get 15 different guesses as to how all this stuff is supposed to be specified in a DN). Even if you manage to find a directory which contains Uni certs (good luck with that) *and* spend an hour or two playing guess the DN, you won't find anything because all the CAs which I've got certs from use DNs which are meaningful to them, not to arbitrary third parties. It gets worse than that. Because the DNs are meaningful to the issuing CAs (which is perfectly OK, they issue the certs so they get to control the DN space) rather than the EE, the EE generally doesn't know their own DN. I can't actually tell you, without cheating and taking a look, what any of the DNs in the certs issued in my name are. I'll emphasise that again: I don't even know my *own* DNs without looking, and I doubt most other people outside of .govs/.mils which force you to use fixed DNs would either. The sole meaningful piece of information in any of my certs is my email address (my CN is vaguely meaningful, but suffers from the "Which John Smith" problem. There should also be certs out there with my email address but apparently belonging to the Jolly Green Giant - isn't it wonderful what CAs will let you put in a cert?). That's the point I made in the analysis in my paper, noone (well, almost noone :-) actually uses a DN in the way X.500 says it's supposed to be used. It's used in a check for equality when checking an S/MIME sig or fetching a decryption key or whatever, but an SHA-1 hash would do just as well, which is why I proposed hashing the DN to a fixed-length value and using that instead. Without wanting to rehash the entire paper, what I did was analyse the types of cert lookups which are typically performed and then design a scheme which handled them. A general summary of the concept is that if you design your application with the assuption that any DNs it encounters are meaningless blobs, you won't be disappointed. If you assume the DN has some sort of magical properties, your application breaks for the vast majority of DNs which don't have those magical properties. >finally, the IETF has had a standard means of encoding a DNS name as a DN for >several years, which suggests that there is at least one scheme that would >work. I assume you mean the RFC 2247 domainComponent? It's a nice theory, but since anyone who needs a URL/FQDN will use a GeneralName where it's available (which is in most cases when it's required) and where only a DN is available will stuff it into a CN like everyone else does and like everyone's software expects, I can't see it ever going beyond being a nice theory (I have a vague memory of actually having seen a solitary DC in a cert somewhere, but a quick check of my collection has failed to locate one... does anyone know of examples of these being used? How does the average third-party app handle them?). Peter. From owner-ietf-pkix Mon Jan 8 16:02:50 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA11766 for ; Mon, 8 Jan 2001 16:02:50 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA19078; Mon, 8 Jan 2001 19:07:20 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <97899599117616@kahu.cs.auckland.ac.nz> References: <97899599117616@kahu.cs.auckland.ac.nz> Date: Mon, 8 Jan 2001 19:00:40 -0500 To: pgut001@cs.auckland.ac.nz From: Stephen Kent Subject: Re: Basic Cert-2-Directory mapping question Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Peter, I think your analysis shows that we have a lot of folks playing CA who are not "qualified" to do so. This is somewhat analogous to people who operate closed IP nets and screw up address assignment, subnetting etc. It's all OK until they try to connect to the rest of the world, and then we get NAT! In the CA case, if you really want a closed CA environment, that's a more defensible practice, but then there is a responsibility to provide the whole environment, which includes the directory. If you do it right, then you can play fast and loose with names and users will be OK. But, all too often we see that systems that were intended to never be open, start developing cracks, and then people see what a mess has been made. I have no sympathy for folks who get themselves into messes of this sort. I think our friends at MS have adopted your attitude to DNs, i.e., "they're too hard to deal with properly and nobody uses them right anyway, so lets use a shortcut for lookups, etc." That appears to be at the heart of a design in which subject key ID takes on more significance than the names in a cert, is used as a search key in a local repository, and for chaining, overriding the 2459 cert path validation rules, etc. That will work if everyone plays by their rules, but does it scale well? Also, it has unintended effects, as one PKIX list member already reported when he discovered differing behavior between Explorer and Navigator. Surprises are never good in a security context. In the later half of the 1980s, Lotus (really Iris) developed its own cert format for use with the Notes product. It worked just fine within each work group context, but they soon discovered then when work groups tried to interconnect and they had issued certs in their own little CA domains without a bigger structure in mind, collisions happened and problems ensued. The problems you cite are real, and they arise for a wide range of reasons, some bad, some understandable. Today I encourage folks to use names from spaces where authoritative CAs can exist, e.g., DNS names, and to use DNs with caution. Steve From owner-ietf-pkix Mon Jan 8 23:10:28 2001 Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA23044 for ; Mon, 8 Jan 2001 23:10:27 -0800 (PST) Received: from d1o69.telia.com (d1o69.telia.com [62.20.144.241]) by mailc.telia.com (8.11.0/8.11.0) with ESMTP id f097FK415902; Tue, 9 Jan 2001 08:15:20 +0100 (CET) Received: from mega (t4o69p44.telia.com [62.20.145.164]) by d1o69.telia.com (8.10.2/8.10.1) with SMTP id f097FJl01366; Tue, 9 Jan 2001 08:15:19 +0100 (CET) Message-ID: <004f01c07a0b$b481ac80$0201a8c0@vincent.se> From: "Anders Rundgren" To: "Bob Jueneman" , , "Stephen Kent" , "PKIX-List" References: <97899599117616@kahu.cs.auckland.ac.nz> Subject: Re: Basic Cert-2-Directory mapping question Date: Tue, 9 Jan 2001 08:13:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id XAA23048 Guys! The response on this "basic" question has simply been overwhelming! Even if you can force CAs to obey certain rules regarding DNs, I still believe that this inability to use certificates created in "one regime", as credentials in another Win2K or NetWare "regime" calls for *some* kind of action. At least those who are into TTPs (commercial or not) should be interested. /anders From owner-ietf-pkix Mon Jan 8 23:30:24 2001 Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA26807 for ; Mon, 8 Jan 2001 23:30:23 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id UAA01017; Tue, 9 Jan 2001 20:35:17 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97902571718933>; Tue, 9 Jan 2001 20:35:17 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: kent@bbn.com Subject: Re: Basic Cert-2-Directory mapping question Cc: ietf-pkix@imc.org Sender: pgut001@cs.auckland.ac.nz Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Tue, 9 Jan 2001 20:35:17 (NZDT) Message-ID: <97902571718933@kahu.cs.auckland.ac.nz> Stephen Kent writes: >I think your analysis shows that we have a lot of folks playing CA who are >not "qualified" to do so. (Wibbly-wobbly effect, fade to shot of John Cleese being turned on a spit by some nuns) JOHN CLEESE: And now for something completely different... (Fairly empty generic modern room. End entity being rushed into the room on a dolly. PKI architects are flipping through standards documents) PKI ARCHITECT 1: commonName qualified with a serialNumber in the same RDN! PKI ARCHITECT 2: firstName + surname + generationQualifier (if required) + dnQualifier! (Sysadmin enters and interrupts them) SYSADMIN: The end entity is ready. PKI ARCHITECT 1: Good, take her into the PKI frightening room. SYSADMIN: Right. PKI ARCHITECT 2: I say, it's a bit barren in here isn't it? PKI ARCHITECT 1: Yes, more junk please sysadmin. The smart cards, the Safekeyper, and the biometrics. SYSADMIN: Yes, most certainly. PKI ARCHITECT 1: And get the machine that issues certificates! (Sysadmin wheels in a cart containing a PC which has "Intel Inside" and "Designed for Microsoft Windows" stickers on it) END ENTITY: What's that for? PKI ARCHITECT 1: That's the machine that issues certificates (Machine goes PING and pops up a "Save certificate as..." dialog) PKI ARCHITECT 1: You see, that means the end entity has been certified! PKI ARCHITECT 2: And that is the most expensive machine in the whole building! PKI ARCHITECT 1: Yes, it cost over three quarters of a million pounds. PKI ARCHITECT 2: Aren't you lucky?! SYSADMIN: The CEO is here doctor. PKI ARCHITECT 1: Switch everything on! (Bleep... whirrr... bing... rumble rumble) CEO: Ah very impressive, very impressive, and what are you doing this morning? PKI ARCHITECT 2: It is a certification. CEO: Ahhh,.. and what sort of thing is that? PKI ARCHITECT 2: Well, that's where we certify uncontestably and undeniably that someone we've never met before who lives on the other side of the planet and who we know only as a (possibly forged) email address really is who they claim to be and can be trusted to write good cheques, buy alcohol, sign contracts, and run a dot-com selling PKI services. CEO: Wonderful what you can do nowadays. (PING) Ahh, I see that you have the machine that issues certificates. This is my favorite. You see we leased it back from the company we sold it to and that way it comes out of the monthly current budget and not the capital account. (Applause) Thank you, thank you, we try to do our best, well do carry on. (CEO leaves) PKI ARCHITECT 1: Lovely, lovely, jolly good, that's better, much much better. PKI ARCHITECT 2: Yes, that's more like it. PKI ARCHITECT 1: Uhh... still something missing though. PKI ARCHITECT 1+2:END ENTITY! PKI ARCHITECT 2: Yes, where's the end entity? PKI ARCHITECT 1: Anyone seen the end entity? SYSADMIN: Ahhh... here she is! PKI ARCHITECT 1: Bring her over here. PKI ARCHITECT 2: Mind the machine. PKI ARCHITECT 1: Hello, now don't you worry. PKI ARCHITECT 2: We'll soon have you certified! PKI ARCHITECT 1: Leave it all to us, you'll never know what hit you. END ENTITY: Will it be a nonRepudiation certificate? PKI ARCHITECT 1: Now I think it's a little early to start imposing roles on it, don't you? Now a word of advice, you may find that you suffer for some time a totally irrational feeling of depression, PKID as we call it. So, it's lots of happy pills for you and you can find out all about the certification when you get home. It's available on Betamax, VHS, and Super-8. (Reporters and photographers enter the PKI frightening room) PKI ARCHITECT 1: Who are you? NOTARY PUBLIC: I am the end entity's notary public. PKI ARCHITECT 1: I am sorry, only people involved are allowed in here. END ENTITY: What do I do? PKI ARCHITECT 2: Yes? END ENTITY: What do I Do? PKI ARCHITECT 2: Nothing dear, you're not "qualified"! (Machine that issues certificates blue screens, camera zooms in to reveal text that says "And now for something completely different...") Peter :-). From owner-ietf-pkix Tue Jan 9 02:22:31 2001 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA17869 for ; Tue, 9 Jan 2001 02:22:28 -0800 (PST) Received: by ns.celocom.se; id LAA07121; Tue, 9 Jan 2001 11:27:19 +0100 (CET) Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma007115; Tue, 9 Jan 01 11:27:12 +0100 Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id LAA22577; Tue, 9 Jan 2001 11:27:11 +0100 Message-ID: <3A5AE77E.E136D8EF@celocom.com> Date: Tue, 09 Jan 2001 11:27:10 +0100 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Polk CC: ietf-pkix@imc.org Subject: Re: WG Last Call, PKI Repository Locator References: <4.2.0.58.20010119095009.01f74c50@email.nist.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim Polk wrote: > As most of you know, there is no requirement for a WG Last Call for > experimental RFCs. However, this specification has been through only a > single draft, and has drawn a very small number of comments. I am hoping > that a Last Call will prompt some of you to review the specification. I'm afraid I seem to have missed the previous batch of comments, and was wondering if you might help me clear out a minor niggle or two. The repository locator draft and RFC 2782 seem to refer to different layers of protocols. Where 2782 refers to protocols in the transport layer, such as TCP, UDP, etc. the draft apparently uses application layer protocols like HTTP, LDAP, and OCSP. These application layer protocols are referred to as services by RFC 2782, where the draft in stead uses the name "PKIXREP". I assume the intention is to differentiate between generic directory or web services and PKI repositories, but would it in such a case not be more prudent to restrict the usage of PKIX defined names to just services instead of both to services and protocols. This could be accomplished, say, by defining the service definitions "PKIXHTTP", "PKIXLDAP", and "PKIXOCSP", which compliant applications could then query at their leisure. Granted, it *is* perfectly possible to employ both RFC 2782 and the locator draft schemes independently to indicate the same directory or web server, but I was curios about these apparent discrepancies between the two documents and was wondering if anybody would care to explain the reasoning behind it to me. Thanks in advance, //oscar From owner-ietf-pkix Tue Jan 9 05:49:06 2001 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA02654 for ; Tue, 9 Jan 2001 05:49:05 -0800 (PST) Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 14FzDt-00000V-00; Tue, 9 Jan 2001 14:54:01 +0100 Received: from surfnet.nl (janus1.sec.nl [192.87.109.32]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id OAA12223; Tue, 9 Jan 2001 14:54:00 +0100 (MET) Message-ID: <3A5B189C.C1C1AE27@surfnet.nl> Date: Tue, 09 Jan 2001 14:56:44 +0100 From: Janus Liebregts Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Rundgren CC: ietf-pkix@imc.org, tf-lsd@terena.nl, pki-coord@terena.nl, "Bosch, J.C.F.v.d." Subject: Re: Basic Cert-2-Directory mapping question References: <200101081828.NAA17320@stingray.missi.ncsc.mil> <3A5A24B8.4E3DB4EC@surfnet.nl> <00a201c079b3$69b17bc0$0201a8c0@vincent.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders, as far as we have tested: you can use certs using X.521 naming in a win2k local authentication environment, the only restriction is that the issuing-CA HAS to be a MS enterprise CA and thus has to use dc-naming (in the current win2000-version). janus Anders Rundgren wrote: > > Janus, > Unforntunately your certificates will not be useful for Win2K local authentication > due to this mapping problem. Does Novell offer a more flexible use of > TTP-issued certificates without requiring the RP to use a 1-2-1 DN > versus directory mapping? > > /anders > > > I fully agree with David. > > > > I don't agree that using a standard DN registration scheme, is > > extraordinarily painful. Currently we, SURFnet (as the dutch National > > Research Network) use two simple rules for our pki-domain (Higher > > Education & Research): > > > > 1. only certify CA's using DN's as registered within our (LDAP)domain > > using the rules of our Naming Authority. > > 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified. > > > > with this we build our pki according to the ldap-namespace ACCORDING to > > SURFnet. We claim to be the Naming Authority for the C=NL namespace... > > > > Probably every country & state have their own laws about naming > > organisations, in Holland the Chambres of Commerce have such a > > (delegated) task. Every country (C= or state c=US, ST=) should have some > > sort of naming authority and name-registration is already taken place. > > But how to make available these authorative Naming databases in a (LDAP) > > way, to be the authorative name for certification.... > > > > For our community we have made available a pki-ldap cookbook which > > describes a method how to organise your DIT and how to store pki-related > > material http://ldap.gigacorp.nl/pkildap.html > > > > Janus Liebregts > > SURFnet > > > > > > > > > > "David P. Kemp" wrote: > > > > > > Peter, > > > > > > I thought what Anders asked was: > > > "given an arbitrary DN, how do I find a cert stored somewhere in an > > > arbitrary collection of independently-managed X.500 or LDAP directory > > > servers", > > > > > > not: > > > "given an arbitrary DN, how do I fetch a cert which I already have a > > > copy of, stored on my own server." > > > > > > It shouldn't be at all surprising that a db or ISAM store, with or > > > without an RDBMS layer above, and with or without a DAP or LDAP access > > > layer, is a reasonable way to store certs on your own machine. [1] > > > Developing a DN-schema-independent local retrieval mechanism is all > > > well and good, but it doesn't solve the registration problem, and as a > > > result, it doesn't help you to find a cert which you don't already > > > have. > > > > > > The real problem with finding and using certs which are stored > > > elsewhere is the reverse of what you stated, namely: > > > > > > cause: people fill DNs with whatever they like, and therefore > > > effect: those particular DN's don't work (i.e. they don't solve > > > Anders' question because they aren't valid addresses in > > > a global address space.) > > > > > > Instead of saying "DN's don't work", with a footnote, it would > > > be more accurate to say "people choose not to use working DNs". > > > > > > The Web works only because every Internet URL begins with > > > DNS-registered name. Something related to your third approach below, > > > requiring all certs and directories to use a standard DN registration > > > scheme, may be extraordinarily painful, but it's better than ad-hoc > > > workarounds using other certificate fields. If PKI consumers and > > > providers aren't willing to standardise within a global DN space, we > > > will have only islands of interoperability. [2] > > > > > > Dave > > > > > > [1] You could also just use the native filesystem, storing each cert > > > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based > > > flat folder. This works as long as you keep secondary indices > > > synchronised with the folder contents, or if you don't need secondary > > > indices at all. > > > > > > [2] Blue sky thought: it might be nice if there were a "Registration > > > Point (RP)" DN attribute which would be analogous to the hostname > > > portion of a URL. The RP attribute would be the first RDN of a > > > DN, and the RP value would be an OID identifying the registration > > > authority and the schema for the remainder of the DN. In principle, > > > this is no better (except for being less verbose) than current DNs, but > > > in practice OIDs are better managed - people actually choose to follow > > > OID registration procedures instead of just poaching in somebody else's > > > space. > > > > > > > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > > > > > > > The main problem is that DN's don't work [0], so you end up with ones which > > > > people have filled with whatever they feel like, odd things required by cert > > > > profiles or signature laws or organisational constraints or whatever which > > > > generally don't fit any known directory schema. The current approaches to > > > > this problem if you're using a directory as a cert store are: > > > > > > > > - Continually update the directory schema to match any new DNs which appear > > > > until the directory admin(s) go insane (hi Paul :-). > > > > - Create aliases in the directory mapping DNs in certs to the (fixed) > > > > directory schema. > > > > - Force all certs to use the schema used in the directory (someone who's > > > > been through this one once described it to me as "extraordinarily > > > painful"). > > > > - Use the directory DN to identify the cert owner and store the cert as just > > > > another attribute, with the actual cert DN ignored. > > > > - (There may be more, since the whole thing is badly broken there are > > > > probably lots of workarounds being used. If anyone knows of others > > > > please let me know) > > > > > > > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > > > > the DN as a blob and hash it down to a fixed-length value which you use as a > > > > key to look up the cert in an RDBMS or something like dbm if you don't need > > > > the full RDBMS functionality [1]. This approach just plain works no matter > > > > how garbled and broken the DN is. From owner-ietf-pkix Tue Jan 9 06:22:54 2001 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA04973 for ; Tue, 9 Jan 2001 06:22:53 -0800 (PST) Received: from zuurtje.surfnet.nl ([192.87.109.5]) by survis.surfnet.nl with ESMTP (exPP) id 14Fzkb-00007h-00; Tue, 9 Jan 2001 15:27:49 +0100 Received: from surfnet.nl (janus1.sec.nl [192.87.109.32]) by zuurtje.surfnet.nl (8.9.3/8.9.3/ZUURTJE-0.8) with ESMTP id PAA02184; Tue, 9 Jan 2001 15:27:48 +0100 (MET) Message-ID: <3A5B2088.E8FD8D2C@surfnet.nl> Date: Tue, 09 Jan 2001 15:30:32 +0100 From: Janus Liebregts Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: dpkemp@stingray.missi.ncsc.mil, ietf-pkix@imc.org, pki-coord@terena.nl, tf-lsd@terena.nl Subject: Re: Basic Cert-2-Directory mapping question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, every country has its own monopoly on local law, every country has a tax department which have to distinguish which company and which citizen has to pay tax. There should be some sort of distinguishing between companies and citizens done by authorities. Mapping of names, which can be used under this law, has to be done in every country. I think the problem is really simple, you can use a name not recognized by your law, but one of the CA's in your pki-hierarchy has to give some guarantee of this CA is operating under a CPS AND a certain law to be trustworthy. Some kind of company or citizen has to provide this guarantee. How do you sue a CSP if you don't know under which identity (recognized by some law) he operates? This is a main issue when doing business using pki-technology in between 2 or more legal systems. janus Bob Jueneman wrote: > > Unfortunately, the model you cite, with naming authorities that > are truly authoritative, and in addition a monopoly, is in fact NOT the > case the United States, and in a number of other countries in the > world as well. > > If the government decrees what DNs are allowable, and perhaps where > they have to be stored, then the problem is certainly simplified. > Unfortunately, usually isn't the case. > > Bob > > >>> Janus Liebregts 01/08/01 01:36PM >>> > I fully agree with David. > > I don't agree that using a standard DN registration scheme, is > extraordinarily painful. Currently we, SURFnet (as the dutch National > Research Network) use two simple rules for our pki-domain (Higher > Education & Research): > > 1. only certify CA's using DN's as registered within our (LDAP)domain > using the rules of our Naming Authority. > 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified. > > with this we build our pki according to the ldap-namespace ACCORDING to > SURFnet. We claim to be the Naming Authority for the C=NL namespace... > > Probably every country & state have their own laws about naming > organisations, in Holland the Chambres of Commerce have such a > (delegated) task. Every country (C= or state c=US, ST=) should have some > sort of naming authority and name-registration is already taken place. > But how to make available these authorative Naming databases in a (LDAP) > way, to be the authorative name for certification.... > > For our community we have made available a pki-ldap cookbook which > describes a method how to organise your DIT and how to store pki-related > material http://ldap.gigacorp.nl/pkildap.html > > Janus Liebregts > SURFnet > > "David P. Kemp" wrote: > > > > Peter, > > > > I thought what Anders asked was: > > "given an arbitrary DN, how do I find a cert stored somewhere in an > > arbitrary collection of independently-managed X.500 or LDAP directory > > servers", > > > > not: > > "given an arbitrary DN, how do I fetch a cert which I already have a > > copy of, stored on my own server." > > > > It shouldn't be at all surprising that a db or ISAM store, with or > > without an RDBMS layer above, and with or without a DAP or LDAP access > > layer, is a reasonable way to store certs on your own machine. [1] > > Developing a DN-schema-independent local retrieval mechanism is all > > well and good, but it doesn't solve the registration problem, and as a > > result, it doesn't help you to find a cert which you don't already > > have. > > > > The real problem with finding and using certs which are stored > > elsewhere is the reverse of what you stated, namely: > > > > cause: people fill DNs with whatever they like, and therefore > > effect: those particular DN's don't work (i.e. they don't solve > > Anders' question because they aren't valid addresses in > > a global address space.) > > > > Instead of saying "DN's don't work", with a footnote, it would > > be more accurate to say "people choose not to use working DNs". > > > > The Web works only because every Internet URL begins with > > DNS-registered name. Something related to your third approach below, > > requiring all certs and directories to use a standard DN registration > > scheme, may be extraordinarily painful, but it's better than ad-hoc > > workarounds using other certificate fields. If PKI consumers and > > providers aren't willing to standardise within a global DN space, we > > will have only islands of interoperability. [2] > > > > Dave > > > > [1] You could also just use the native filesystem, storing each cert > > as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based > > flat folder. This works as long as you keep secondary indices > > synchronised with the folder contents, or if you don't need secondary > > indices at all. > > > > [2] Blue sky thought: it might be nice if there were a "Registration > > Point (RP)" DN attribute which would be analogous to the hostname > > portion of a URL. The RP attribute would be the first RDN of a > > DN, and the RP value would be an OID identifying the registration > > authority and the schema for the remainder of the DN. In principle, > > this is no better (except for being less verbose) than current DNs, but > > in practice OIDs are better managed - people actually choose to follow > > OID registration procedures instead of just poaching in somebody else's > > space. > > > > > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > > > > > The main problem is that DN's don't work [0], so you end up with ones which > > > people have filled with whatever they feel like, odd things required by cert > > > profiles or signature laws or organisational constraints or whatever which > > > generally don't fit any known directory schema. The current approaches to > > > this problem if you're using a directory as a cert store are: > > > > > > - Continually update the directory schema to match any new DNs which appear > > > until the directory admin(s) go insane (hi Paul :-). > > > - Create aliases in the directory mapping DNs in certs to the (fixed) > > > directory schema. > > > - Force all certs to use the schema used in the directory (someone who's > > > been through this one once described it to me as "extraordinarily > > painful"). > > > - Use the directory DN to identify the cert owner and store the cert as just > > > another attribute, with the actual cert DN ignored. > > > - (There may be more, since the whole thing is badly broken there are > > > probably lots of workarounds being used. If anyone knows of others > > > please let me know) > > > > > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > > > the DN as a blob and hash it down to a fixed-length value which you use as a > > > key to look up the cert in an RDBMS or something like dbm if you don't need > > > the full RDBMS functionality [1]. This approach just plain works no matter > > > how garbled and broken the DN is. From owner-ietf-pkix Tue Jan 9 06:27:30 2001 Received: from arista.iris.com (arista.iris.com [198.112.211.42]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05306 for ; Tue, 9 Jan 2001 06:27:26 -0800 (PST) From: John_Wray@iris.com Subject: Re: Basic Cert-2-Directory mapping question To: "Bob Jueneman" Cc: , X-Mailer: Lotus Notes Release 5.0.2c February 2, 2000 Message-ID: Date: Tue, 9 Jan 2001 09:32:03 -0500 X-MIMETrack: Serialize by Router on Arista/Iris(Build V505_07112000 |July 11, 2000) at 01/09/2001 09:36:56 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Bob, Accepting the fact that the X.500 dream of a single global directory is not going to happen any time soon, DNs can still be turned into globally significant pointers into a federation of directories in the way you suggest, but it doesn't require altering the DN syntax (and therefore doesn't have to break existing implementations). All that's needed is a DN attribute that names the particular directory within which the name resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a directory access point. John "Bob Jueneman" on 01/08/2001 04:56:58 PM To: , cc: Subject: Re: Basic Cert-2-Directory mapping question This has been a train wreck about the happen for nearly ten years. It's like watching "The Fugitive" one still frame at a time. The NADF tried to address this problem and gave up, and PKIX hasn't even tried. To quote Pogo, "We have met the enemy, and they is us." The first problem is not the DN -- that's secondary. As you correctly state, the first problem is knowing the location of a directory service provider that is supposed to contain the DN, so we can at least get to the right point and start browsing around for a certificate. I don't know that we need to name a Registration Point for a DN -- that might get all tangled up in naming issues, who has the right to name someone, etc. What I proposed more than a year ago, and what I think you are in essence saying, was that DNs in certificate should really be URLs, in essentially the same fashion as CRLDistributionPoints are. I don't particularly care what the exact syntax is -- something like ldap://ldap.mycompany.com/c=us, ....cn="My Name" would do just fine, I think, but I'll let other people debate that. Once we finally locate the directory, then we can have all of the religious arguments about my RDN schema vs. yours, and why yours is wrong and mine is the only one that any right-thinking system administer could possibly support, yada, yada, yada. Unfortunately, since the contents of PKI certificates are generally viewed as supposedly providing some degree of specificity with regard to a geopolitical identification and location of an end-entity, those schemas sometimes conflict with directory structures which are often organized around completely different principles, such as more or less reflecting the network structure or topology or span of control issues. But those issues, although certainly important, could reasonably be resolved by aliases, etc., no matter how painful But if a consumer of certificates doesn't even know where the directory can be found to start looking, then schema problems won't matter. Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software >>> "David P. Kemp" 01/08/01 11:29AM >>> Peter, I thought what Anders asked was: "given an arbitrary DN, how do I find a cert stored somewhere in an arbitrary collection of independently-managed X.500 or LDAP directory servers", not: "given an arbitrary DN, how do I fetch a cert which I already have a copy of, stored on my own server." It shouldn't be at all surprising that a db or ISAM store, with or without an RDBMS layer above, and with or without a DAP or LDAP access layer, is a reasonable way to store certs on your own machine. [1] Developing a DN-schema-independent local retrieval mechanism is all well and good, but it doesn't solve the registration problem, and as a result, it doesn't help you to find a cert which you don't already have. The real problem with finding and using certs which are stored elsewhere is the reverse of what you stated, namely: cause: people fill DNs with whatever they like, and therefore effect: those particular DN's don't work (i.e. they don't solve Anders' question because they aren't valid addresses in a global address space.) Instead of saying "DN's don't work", with a footnote, it would be more accurate to say "people choose not to use working DNs". The Web works only because every Internet URL begins with DNS-registered name. Something related to your third approach below, requiring all certs and directories to use a standard DN registration scheme, may be extraordinarily painful, but it's better than ad-hoc workarounds using other certificate fields. If PKI consumers and providers aren't willing to standardise within a global DN space, we will have only islands of interoperability. [2] Dave [1] You could also just use the native filesystem, storing each cert as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based flat folder. This works as long as you keep secondary indices synchronised with the folder contents, or if you don't need secondary indices at all. [2] Blue sky thought: it might be nice if there were a "Registration Point (RP)" DN attribute which would be analogous to the hostname portion of a URL. The RP attribute would be the first RDN of a DN, and the RP value would be an OID identifying the registration authority and the schema for the remainder of the DN. In principle, this is no better (except for being less verbose) than current DNs, but in practice OIDs are better managed - people actually choose to follow OID registration procedures instead of just poaching in somebody else's space. > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > The main problem is that DN's don't work [0], so you end up with ones which > people have filled with whatever they feel like, odd things required by cert > profiles or signature laws or organisational constraints or whatever which > generally don't fit any known directory schema. The current approaches to > this problem if you're using a directory as a cert store are: > > - Continually update the directory schema to match any new DNs which appear > until the directory admin(s) go insane (hi Paul :-). > - Create aliases in the directory mapping DNs in certs to the (fixed) > directory schema. > - Force all certs to use the schema used in the directory (someone who's > been through this one once described it to me as "extraordinarily painful"). > - Use the directory DN to identify the cert owner and store the cert as just > another attribute, with the actual cert DN ignored. > - (There may be more, since the whole thing is badly broken there are > probably lots of workarounds being used. If anyone knows of others > please let me know) > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > the DN as a blob and hash it down to a fixed-length value which you use as a > key to look up the cert in an RDBMS or something like dbm if you don't need > the full RDBMS functionality [1]. This approach just plain works no matter > how garbled and broken the DN is. From owner-ietf-pkix Tue Jan 9 06:27:37 2001 Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05359 for ; Tue, 9 Jan 2001 06:27:37 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA48740; Tue, 9 Jan 2001 09:28:22 -0600 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id JAA21156; Tue, 9 Jan 2001 09:32:27 -0500 Importance: Normal Subject: Re: [tf-lsd] Re: Basic Cert-2-Directory mapping question To: tf-lsd@terena.nl Cc: Anders Rundgren , ietf-pkix@imc.org, tf-lsd@terena.nl, pki-coord@terena.nl X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "John McGarvey" Date: Tue, 9 Jan 2001 09:30:08 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 01/09/2001 09:32:27 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Janus, In describing the Microsoft case, you put your finger right on the problem. There is no guarantee that the LDAP directory to be used by a given application, and the CA that issues a certificate, adhere to the same namespace rules or are administered by the same processes or people. So the certificate DN may not correspond to any DN in the directory. This problem will often occur in eBusiness or B2B applications, when the certificates may be issued by well known public CAs, but the directory in which policies, preferences, and whitepages information is stored is maintained by a given enterprise or web hosting service. Also, there is no guarantee that the DNs in the certificates uniquely identify the same principal. Different well known CAs might use the same DN to describe different principals. If one is building a CA infrastructure and a directory infrastructure together, of course one can make the certificate DNs match the LDAP DNs. But, as it is often the case that the two are constructed separately, there needs to be a means of mapping from one to the other. Regards, John McGarvey Janus Liebregts @terena.nl on 2001/01/09 08:56:44 AM Please respond to tf-lsd@terena.nl Sent by: owner-tf-lsd@terena.nl To: Anders Rundgren cc: ietf-pkix@imc.org, tf-lsd@terena.nl, pki-coord@terena.nl, "Bosch, J.C.F.v.d." Subject: [tf-lsd] Re: Basic Cert-2-Directory mapping question Anders, as far as we have tested: you can use certs using X.521 naming in a win2k local authentication environment, the only restriction is that the issuing-CA HAS to be a MS enterprise CA and thus has to use dc-naming (in the current win2000-version). janus Anders Rundgren wrote: > > Janus, > Unforntunately your certificates will not be useful for Win2K local authentication > due to this mapping problem. Does Novell offer a more flexible use of > TTP-issued certificates without requiring the RP to use a 1-2-1 DN > versus directory mapping? > > /anders > > > I fully agree with David. > > > > I don't agree that using a standard DN registration scheme, is > > extraordinarily painful. Currently we, SURFnet (as the dutch National > > Research Network) use two simple rules for our pki-domain (Higher > > Education & Research): > > > > 1. only certify CA's using DN's as registered within our (LDAP)domain > > using the rules of our Naming Authority. > > 2. store CA-certificates & CRL's in the DN's (LDAP)entry as certified. > > > > with this we build our pki according to the ldap-namespace ACCORDING to > > SURFnet. We claim to be the Naming Authority for the C=NL namespace... > > > > Probably every country & state have their own laws about naming > > organisations, in Holland the Chambres of Commerce have such a > > (delegated) task. Every country (C= or state c=US, ST=) should have some > > sort of naming authority and name-registration is already taken place. > > But how to make available these authorative Naming databases in a (LDAP) > > way, to be the authorative name for certification.... > > > > For our community we have made available a pki-ldap cookbook which > > describes a method how to organise your DIT and how to store pki-related > > material http://ldap.gigacorp.nl/pkildap.html > > > > Janus Liebregts > > SURFnet > > > > > > > > > > "David P. Kemp" wrote: > > > > > > Peter, > > > > > > I thought what Anders asked was: > > > "given an arbitrary DN, how do I find a cert stored somewhere in an > > > arbitrary collection of independently-managed X.500 or LDAP directory > > > servers", > > > > > > not: > > > "given an arbitrary DN, how do I fetch a cert which I already have a > > > copy of, stored on my own server." > > > > > > It shouldn't be at all surprising that a db or ISAM store, with or > > > without an RDBMS layer above, and with or without a DAP or LDAP access > > > layer, is a reasonable way to store certs on your own machine. [1] > > > Developing a DN-schema-independent local retrieval mechanism is all > > > well and good, but it doesn't solve the registration problem, and as a > > > result, it doesn't help you to find a cert which you don't already > > > have. > > > > > > The real problem with finding and using certs which are stored > > > elsewhere is the reverse of what you stated, namely: > > > > > > cause: people fill DNs with whatever they like, and therefore > > > effect: those particular DN's don't work (i.e. they don't solve > > > Anders' question because they aren't valid addresses in > > > a global address space.) > > > > > > Instead of saying "DN's don't work", with a footnote, it would > > > be more accurate to say "people choose not to use working DNs". > > > > > > The Web works only because every Internet URL begins with > > > DNS-registered name. Something related to your third approach below, > > > requiring all certs and directories to use a standard DN registration > > > scheme, may be extraordinarily painful, but it's better than ad-hoc > > > workarounds using other certificate fields. If PKI consumers and > > > providers aren't willing to standardise within a global DN space, we > > > will have only islands of interoperability. [2] > > > > > > Dave > > > > > > [1] You could also just use the native filesystem, storing each cert > > > as a file in an RDN-based folder heirarchy or in a DN or hash(DN) -based > > > flat folder. This works as long as you keep secondary indices > > > synchronised with the folder contents, or if you don't need secondary > > > indices at all. > > > > > > [2] Blue sky thought: it might be nice if there were a "Registration > > > Point (RP)" DN attribute which would be analogous to the hostname > > > portion of a URL. The RP attribute would be the first RDN of a > > > DN, and the RP value would be an OID identifying the registration > > > authority and the schema for the remainder of the DN. In principle, > > > this is no better (except for being less verbose) than current DNs, but > > > in practice OIDs are better managed - people actually choose to follow > > > OID registration procedures instead of just poaching in somebody else's > > > space. > > > > > > > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > > > > > > > The main problem is that DN's don't work [0], so you end up with ones which > > > > people have filled with whatever they feel like, odd things required by cert > > > > profiles or signature laws or organisational constraints or whatever which > > > > generally don't fit any known directory schema. The current approaches to > > > > this problem if you're using a directory as a cert store are: > > > > > > > > - Continually update the directory schema to match any new DNs which appear > > > > until the directory admin(s) go insane (hi Paul :-). > > > > - Create aliases in the directory mapping DNs in certs to the (fixed) > > > > directory schema. > > > > - Force all certs to use the schema used in the directory (someone who's > > > > been through this one once described it to me as "extraordinarily > > > painful"). > > > > - Use the directory DN to identify the cert owner and store the cert as just > > > > another attribute, with the actual cert DN ignored. > > > > - (There may be more, since the whole thing is badly broken there are > > > > probably lots of workarounds being used. If anyone knows of others > > > > please let me know) > > > > > > > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > > > > the DN as a blob and hash it down to a fixed-length value which you use as a > > > > key to look up the cert in an RDBMS or something like dbm if you don't need > > > > the full RDBMS functionality [1]. This approach just plain works no matter > > > > how garbled and broken the DN is. From owner-ietf-pkix Tue Jan 9 06:39:53 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA06018 for ; Tue, 9 Jan 2001 06:39:53 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA03605; Tue, 9 Jan 2001 09:44:46 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <004f01c07a0b$b481ac80$0201a8c0@vincent.se> References: <97899599117616@kahu.cs.auckland.ac.nz> <004f01c07a0b$b481ac80$0201a8c0@vincent.se> Date: Tue, 9 Jan 2001 09:37:25 -0500 To: "Anders Rundgren" From: Stephen Kent Subject: Re: Basic Cert-2-Directory mapping question Cc: "PKIX-List" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Anders, >Guys! >The response on this "basic" question has simply been overwhelming! > >Even if you can force CAs to obey certain rules regarding DNs, I still believe >that this inability to use certificates created in "one regime", as >credentials in >another Win2K or NetWare "regime" calls for *some* kind of action. Not necessarily. Personally, I'm comfortable having multiple certs issued by different CAs, each authoritative for a distinct PKI. Large, isolated PKIs are OK, if one has a clear plan for why they will remain isolated. SET, though a failure in many respects, is a good example of such an isolated PKI. Also, although we have not mentioned it in this exchange, PKIX has the AIA extension, and will add back the SIA extension, which provide explicit pointers to directories once you have a target certificate, e.g., for retrieval of CA certs and CRLs. Many security protocols provide an ability to send certs as part of the protocol, which alleviates the need for blind searching for certs. >At least those who are into TTPs (commercial or not) should be interested. yes, TTPs who argue for "one person, one cert" have an interest in this issue, but that's not the only game in town, and if the problem is mostly a directory issue, then the discussion belongs in a directory WG, not in PKIX. Steve From owner-ietf-pkix Tue Jan 9 07:12:15 2001 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA07040 for ; Tue, 9 Jan 2001 07:12:15 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Jan 2001 08:16:31 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 09 Jan 2001 08:16:33 -0700 From: "Bob Jueneman" To: Cc: Subject: Re: Basic Cert-2-Directory mapping question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA07043 John, as I said, I don't care much what the syntax is. I don't mean to suggest that such details aren't important, but they wouldn't make or break the Internet. There is a community of applications (like browsers, etc.) that are used to dealing with URLs, but your suggestion of a "super-top" class could also be made to work. Your suggestion would also have the implicit implication (I guess that's redundant) that the lower levels of the RDN tree are subordinate to, and defined within, the top level directory., and that might be desirable. What we need, and have needed for ten years, is a STANDARD! Bob Aside to David Kemp -- mail sent to your return address of dpkemp@stingray.missi.ncsc.mil bounces with "User unknown". >>> 01/09/01 07:32AM >>> Bob, Accepting the fact that the X.500 dream of a single global directory is not going to happen any time soon, DNs can still be turned into globally significant pointers into a federation of directories in the way you suggest, but it doesn't require altering the DN syntax (and therefore doesn't have to break existing implementations). All that's needed is a DN attribute that names the particular directory within which the name resides. e.g. instead of "c=us;..;cn=My Name" you'd have "dir=My Directory;c=us;...;cn=My Name", where "My Directory" is the URL of a directory access point. John "Bob Jueneman" on 01/08/2001 04:56:58 PM To: , cc: Subject: Re: Basic Cert-2-Directory mapping question This has been a train wreck about the happen for nearly ten years. It's like watching "The Fugitive" one still frame at a time. The NADF tried to address this problem and gave up, and PKIX hasn't even tried. To quote Pogo, "We have met the enemy, and they is us." The first problem is not the DN -- that's secondary. As you correctly state, the first problem is knowing the location of a directory service provider that is supposed to contain the DN, so we can at least get to the right point and start browsing around for a certificate. I don't know that we need to name a Registration Point for a DN -- that might get all tangled up in naming issues, who has the right to name someone, etc. What I proposed more than a year ago, and what I think you are in essence saying, was that DNs in certificate should really be URLs, in essentially the same fashion as CRLDistributionPoints are. I don't particularly care what the exact syntax is -- something like ldap://ldap.mycompany.com/c=us, ....cn="My Name" would do just fine, I think, but I'll let other people debate that. Once we finally locate the directory, then we can have all of the religious arguments about my RDN schema vs. yours, and why yours is wrong and mine is the only one that any right-thinking system administer could possibly support, yada, yada, yada. Unfortunately, since the contents of PKI certificates are generally viewed as supposedly providing some degree of specificity with regard to a geopolitical identification and location of an end-entity, those schemas sometimes conflict with directory structures which are often organized around completely different principles, such as more or less reflecting the network structure or topology or span of control issues. But those issues, although certainly important, could reasonably be resolved by aliases, etc., no matter how painful But if a consumer of certificates doesn't even know where the directory can be found to start looking, then schema problems won't matter. Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software >>> "David P. Kemp" 01/08/01 11:29AM >>> Peter, I thought what Anders asked was: "given an arbitrary DN, how do I find a cert stored somewhere in an arbitrary collection of independently-managed X.500 or LDAP directory servers", not: "given an arbitrary DN, how do I fetch a cert which I already have a copy of, stored on my own server." It shouldn't be at all surprising that a db or ISAM store, with or without an RDBMS layer above, and with or without a DAP or LDAP access layer, is a reasonable way to store certs on your own machine. [1] Developing a DN-schema-independent local retrieval mechanism is all well and good, but it doesn't solve the registration problem, and as a result, it doesn't help you to find a cert which you don't already have. The real problem with finding and using certs which are stored elsewhere is the reverse of what you stated, namely: cause: people fill DNs with whatever they like, and therefore effect: those particular DN's don't work (i.e. they don't solve Anders' question because they aren't valid addresses in a global address space.) Instead of saying "DN's don't work", with a footnote, it would be more accurate to say "people choose not to use working DNs". The Web works only because every Internet URL begins with DNS-registered name. Something related to your third approach below, requiring all certs and directories to use a standard DN registration scheme, may be extraordinarily painful, but it's better than ad-hoc workarounds using other certificate fields. If PKI consumers and providers aren't willing to standardise within a global DN space, we will have only islands of interoperability. [2] Dave [1] You could also just use the native filesystem, storing each cert as a file in an RDN-based folder heirarchy or in a DN or hash(DN)-based flat folder. This works as long as you keep secondary indices synchronised with the folder contents, or if you don't need secondary indices at all. [2] Blue sky thought: it might be nice if there were a "Registration Point (RP)" DN attribute which would be analogous to the hostname portion of a URL. The RP attribute would be the first RDN of a DN, and the RP value would be an OID identifying the registration authority and the schema for the remainder of the DN. In principle, this is no better (except for being less verbose) than current DNs, but in practice OIDs are better managed - people actually choose to follow OID registration procedures instead of just poaching in somebody else's space. > From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > > The main problem is that DN's don't work [0], so you end up with ones which > people have filled with whatever they feel like, odd things required by cert > profiles or signature laws or organisational constraints or whatever which > generally don't fit any known directory schema. The current approaches to > this problem if you're using a directory as a cert store are: > > - Continually update the directory schema to match any new DNs which appear > until the directory admin(s) go insane (hi Paul :-). > - Create aliases in the directory mapping DNs in certs to the (fixed) > directory schema. > - Force all certs to use the schema used in the directory (someone who's > been through this one once described it to me as "extraordinarily painful"). > - Use the directory DN to identify the cert owner and store the cert as just > another attribute, with the actual cert DN ignored. > - (There may be more, since the whole thing is badly broken there are > probably lots of workarounds being used. If anyone knows of others > please let me know) > > A much better approach IMNSHO, and the one I look at in my paper, is to treat > the DN as a blob and hash it down to a fixed-length value which you use as a > key to look up the cert in an RDBMS or something like dbm if you don't need > the full RDBMS functionality [1]. This approach just plain works no matter > how garbled and broken the DN is. From owner-ietf-pkix Tue Jan 9 07:37:46 2001 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA11168 for ; Tue, 9 Jan 2001 07:37:46 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Jan 2001 08:42:10 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 09 Jan 2001 08:42:03 -0700 From: "Bob Jueneman" To: , Cc: Subject: Re: Basic Cert-2-Directory mapping question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA11169 Peter, it's obvious that your talents are being wasted. You could easily be the Michael Crichton of the PKI industry, and go on to fame and fortune. I can see it now -- first a book, which lays out in layman's terms what ASN.1 is really all about, then a mild little spin -- nothing too far fetched or provably wrong -- and then the story line commences. Suddenly, certificates are stretching endlessly throughout all time, the inevitable consequence of "nonrepudiation" being stretched, not too implausibly, both forwards and backwards. Then the movie begins, with a subterranean bass that requires Dolby 5.1 and at least 40,000 watts of powered subwoofer to do it justice. Without warning (well, maybe a bit of Carnival of the Animals leitmotiv), an innocent MPEG movie of a cat playing with its master, embedded in an antique certificate DN like a mosquito in a bit of amber, is morphed back through time to the ancestral saber-tooth tiger, devouring its prey in the carbonaceous (as opposed to siliconaceous) Internet jungle, complete with T3 vines and monolithic (one rock) servers. Man, that ASN.1 is really, really powerful stuff! Who needs XML?! Bob >>> Peter Gutmann 01/09/01 08:35PM >>> Stephen Kent writes: >I think your analysis shows that we have a lot of folks playing CA who are >not "qualified" to do so. (Wibbly-wobbly effect, fade to shot of John Cleese being turned on a spit by some nuns) JOHN CLEESE: And now for something completely different... (Fairly empty generic modern room. End entity being rushed into the room on a dolly. PKI architects are flipping through standards documents) PKI ARCHITECT 1: commonName qualified with a serialNumber in the same RDN! PKI ARCHITECT 2: firstName + surname + generationQualifier (if required) + dnQualifier! (Sysadmin enters and interrupts them) SYSADMIN: The end entity is ready. PKI ARCHITECT 1: Good, take her into the PKI frightening room. SYSADMIN: Right. PKI ARCHITECT 2: I say, it's a bit barren in here isn't it? PKI ARCHITECT 1: Yes, more junk please sysadmin. The smart cards, the Safekeyper, and the biometrics. SYSADMIN: Yes, most certainly. PKI ARCHITECT 1: And get the machine that issues certificates! (Sysadmin wheels in a cart containing a PC which has "Intel Inside" and "Designed for Microsoft Windows" stickers on it) END ENTITY: What's that for? PKI ARCHITECT 1: That's the machine that issues certificates (Machine goes PING and pops up a "Save certificate as..." dialog) PKI ARCHITECT 1: You see, that means the end entity has been certified! PKI ARCHITECT 2: And that is the most expensive machine in the whole building! PKI ARCHITECT 1: Yes, it cost over three quarters of a million pounds. PKI ARCHITECT 2: Aren't you lucky?! SYSADMIN: The CEO is here doctor. PKI ARCHITECT 1: Switch everything on! (Bleep... whirrr... bing... rumble rumble) CEO: Ah very impressive, very impressive, and what are you doing this morning? PKI ARCHITECT 2: It is a certification. CEO: Ahhh,.. and what sort of thing is that? PKI ARCHITECT 2: Well, that's where we certify uncontestably and undeniably that someone we've never met before who lives on the other side of the planet and who we know only as a (possibly forged) email address really is who they claim to be and can be trusted to write good cheques, buy alcohol, sign contracts, and run a dot-com selling PKI services. CEO: Wonderful what you can do nowadays. (PING) Ahh, I see that you have the machine that issues certificates. This is my favorite. You see we leased it back from the company we sold it to and that way it comes out of the monthly current budget and not the capital account. (Applause) Thank you, thank you, we try to do our best, well do carry on. (CEO leaves) PKI ARCHITECT 1: Lovely, lovely, jolly good, that's better, much much better. PKI ARCHITECT 2: Yes, that's more like it. PKI ARCHITECT 1: Uhh... still something missing though. PKI ARCHITECT 1+2:END ENTITY! PKI ARCHITECT 2: Yes, where's the end entity? PKI ARCHITECT 1: Anyone seen the end entity? SYSADMIN: Ahhh... here she is! PKI ARCHITECT 1: Bring her over here. PKI ARCHITECT 2: Mind the machine. PKI ARCHITECT 1: Hello, now don't you worry. PKI ARCHITECT 2: We'll soon have you certified! PKI ARCHITECT 1: Leave it all to us, you'll never know what hit you. END ENTITY: Will it be a nonRepudiation certificate? PKI ARCHITECT 1: Now I think it's a little early to start imposing roles on it, don't you? Now a word of advice, you may find that you suffer for some time a totally irrational feeling of depression, PKID as we call it. So, it's lots of happy pills for you and you can find out all about the certification when you get home. It's available on Betamax, VHS, and Super-8. (Reporters and photographers enter the PKI frightening room) PKI ARCHITECT 1: Who are you? NOTARY PUBLIC: I am the end entity's notary public. PKI ARCHITECT 1: I am sorry, only people involved are allowed in here. END ENTITY: What do I do? PKI ARCHITECT 2: Yes? END ENTITY: What do I Do? PKI ARCHITECT 2: Nothing dear, you're not "qualified"! (Machine that issues certificates blue screens, camera zooms in to reveal text that says "And now for something completely different...") Peter :-). From owner-ietf-pkix Tue Jan 9 07:44:26 2001 Received: from ns.celocom.se (firewall-user@ns.celocom.se [212.209.40.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12615 for ; Tue, 9 Jan 2001 07:44:25 -0800 (PST) Received: by ns.celocom.se; id QAA12122; Tue, 9 Jan 2001 16:49:20 +0100 (CET) Received: from unknown(10.10.10.1) by ns.celocom.se via smap (V5.0) id xma012102; Tue, 9 Jan 01 16:48:48 +0100 Received: from celocom.com (stan.celocom.se [10.10.10.129]) by zap.celocom.se (8.8.7/8.8.7) with ESMTP id QAA27903; Tue, 9 Jan 2001 16:48:47 +0100 Message-ID: <3A5B32DF.6AA8A7F2@celocom.com> Date: Tue, 09 Jan 2001 16:48:47 +0100 From: Oscar Jacobsson Organization: Celo Communications X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: ietf-pkix@imc.org Subject: Re: Basic Cert-2-Directory mapping question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Jueneman wrote: > What we need, and have needed for ten years, is a STANDARD! Apart from the fact that RFC 2377 is "only" Informational, are there any perceived problems with the naming plan it proposes that I'm unaware of? I should probably add that I've yet to attempt to implement an infrastructure using this naming scheme yet. :-) Cheers! //oscar From owner-ietf-pkix Tue Jan 9 07:52:06 2001 Received: from rom.antech.de (dns.antech.de [194.45.12.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13881 for ; Tue, 9 Jan 2001 07:52:05 -0800 (PST) Received: from scherbius.secorvo.de (kasiski.secorvo.de [194.45.12.203]) by rom.antech.de (8.9.3/8.9.3) with ESMTP id QAA13126; Tue, 9 Jan 2001 16:46:06 +0100 Message-Id: <200101091546.QAA13126@rom.antech.de> From: "Stefan Kelm" Organization: Secorvo Security Consulting GmbH To: pgut001@cs.auckland.ac.nz, ietf-pkix@imc.org Date: Tue, 9 Jan 2001 16:54:32 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Basic Cert-2-Directory mapping question Reply-to: kelm@secorvo.de Priority: normal In-reply-to: <97899599117616@kahu.cs.auckland.ac.nz> X-mailer: Pegasus Mail for Win32 (v3.12b) Peter, > >finally, the IETF has had a standard means of encoding a DNS name as a DN for > >several years, which suggests that there is at least one scheme that would > >work. > > I assume you mean the RFC 2247 domainComponent? It's a nice theory, but since > anyone who needs a URL/FQDN will use a GeneralName where it's available (which > is in most cases when it's required) and where only a DN is available will > stuff it into a CN like everyone else does and like everyone's software > expects, I can't see it ever going beyond being a nice theory (I have a vague > memory of actually having seen a solitary DC in a cert somewhere, but a quick > check of my collection has failed to locate one... does anyone know of > examples of these being used? How does the average third-party app handle > them?). we've used certificates with DC attributes (encoded as IA5STRING) with customers. Needless to say that applications do have problems; most will accept the certificates but will not display the full DN, esp. not the DC attributes... :) Cheers, Stefan. ------------------------------------------------------- Dipl.-Inform. Stefan Kelm Security Consultant Secorvo Security Consulting GmbH Albert-Nestler-Strasse 9, D-76131 Karlsruhe Tel. +49 721 6105-461, Fax +49 721 6105-455 E-Mail kelm@secorvo.de, http://www.secorvo.de ------------------------------------------------------- PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B From owner-ietf-pkix Tue Jan 9 08:45:58 2001 Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16375 for ; Tue, 9 Jan 2001 08:45:58 -0800 (PST) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 09 Jan 2001 09:50:23 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Tue, 09 Jan 2001 09:50:18 -0700 From: "Bob Jueneman" To: , Subject: Re: Basic Cert-2-Directory mapping question Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id IAA16376 >>>> "Anders Rundgren" 01/09/01 12:13AM >>> >Guys! >The response on this "basic" question has simply been overwhelming! > >Even if you can force CAs to obey certain rules regarding DNs, I still believe >that this inability to use certificates created in "one regime", as credentials in >another Win2K or NetWare "regime" calls for *some* kind of action. > >At least those who are into TTPs (commercial or not) should be interested. > >/anders > Anders, I won't attempt to speak for Microsoft -- Bill has more money than I do, and can speak for himself. But although I certainly share some of your frustration, it isn't clear as yet that most of our customers have this problem, although perhaps we wish they did. Whether someone within the enterprise is trying to log on to Win2K, NetWare, or our NDS/eDirectory, 95% to 99% of the time they are using access control solutions established BY the enterprise FOR the enterprise. In that type of closed environment, it simply doesn't matter all that much what the directory schema or the PKI schema looks like, as they will be designed to match each other. Notice that this really isn't a "closed PKI" as Steve discusses -- it's even more closed than that, because the access control is almost entirely within ONE enterprise, and not multiple enterprises, much less the much broader retail consumer or residentialPerson marketplace. Now, I'm certainly not arguing that it wouldn't be interesting to talk about extranet access control, and PKI-based authorizations that extend beyond the boundaries of one organization. It would be interesting, and I and others have been talking about that for what seems like eons. But by and large, it isn't happening. Is this, as some would claim, due to the fact that we haven't solved the directory naming problem? No, the problem is deeper than that. The problem is one of TRUST. And I would claim, with some regret, that PKI isn't about TRUST, it is about IDENTITY. Unfortunately, when it comes to making an access control decision, it isn't sufficient to have a chain of certificate stretching back to some ubiquitous issuer of low-cost certificates which attests to the fact that the holder of a given private key is in fact cn="Village Idiot #13", even if he really is. If I'm the system administrator, I don't care who someone IS, I want to know what that person is permitted to DO. At least at present, the way that people are controlling those decisions is to pre-enroll that individual into an authoritative directory or database, and then assign or share some secret with that individual which can be used to authenticate that person as the same individual that was authorized, assuming he hasn't shared that secret with someone else. Granted, there are nuances of security and control, but the bottom line is that it isn't the person's DN that matters, assuming that DN can be found somehow. The only thing that really matters is the shared secret, and the fact that the person who knows that secret has been granted certain permissions or authority. Whether that secret is a password, a private key, or some token device is of secondary importance to the fact of pre-enrollment and the granting of access authority. So the lack of a universal naming solution, although irritating to those of us in the profession, hasn't yet reach the point of being a crisis with our customers, because those customers either don't allow external users into their system at all, or they base their decisions on other things than identity, such as whether or not the person has a valid credit card account, and it isn't maxed out. Note that I have been talking exclusively about access control, and not legally-binding transactions or other aspects of a more global use of PKI, where identity may (someday) play a larger role. But even in that context, I would claim that trust comes first, and is anchored by identity, and not the other way around. Regards, Bob Robert R. Jueneman Security Architect Novell, Inc. -- the leading provider of Net services software. From owner-ietf-pkix Tue Jan 9 13:30:53 2001 Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA00165 for ; Tue, 9 Jan 2001 13:30:52 -0800 (PST) Received: from survis.surfnet.nl ([192.87.108.3] helo=surfnet.nl) by survis.surfnet.nl with ESMTP (exPP) id 14G6Qm-0001Qi-00; Tue, 9 Jan 2001 22:35:48 +0100 Message-ID: <3A5B8452.3B84568A@surfnet.nl> Date: Tue, 09 Jan 2001 22:36:18 +0100 From: Janus Liebregts Organization: SURFnet bv X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Jueneman CC: ietf-pkix@imc.org, anders.rundgren@telia.com, tf-lsd@terena.nl, pki-coord@terena.nl Subject: Re: Basic Cert-2-Directory mapping question References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Jueneman wrote: > > >>>> "Anders Rundgren" 01/09/01 12:13AM >>> > >Guys! > >The response on this "basic" question has simply been overwhelming! > > > >Even if you can force CAs to obey certain rules regarding DNs, I still believe > >that this inability to use certificates created in "one regime", as credentials in > >another Win2K or NetWare "regime" calls for *some* kind of action. > > > >At least those who are into TTPs (commercial or not) should be interested. > > > >/anders > > > > Anders, I won't attempt to speak for Microsoft -- Bill has more money than I > do, and can speak for himself. > > But although I certainly share some of your frustration, it isn't clear as yet > that most of our customers have this problem, although perhaps we wish they > did. > > Whether someone within the enterprise is trying to log on to Win2K, NetWare, > or our NDS/eDirectory, 95% to 99% of the time they are using access control > solutions established BY the enterprise FOR the enterprise. > > In that type of closed environment, it simply doesn't matter all that much what > the directory schema or the PKI schema looks like, as they will be designed to > match each other. > > Notice that this really isn't a "closed PKI" as Steve discusses -- it's even more closed > than that, because the access control is almost entirely within ONE enterprise, > and not multiple enterprises, much less the much broader retail consumer > or residentialPerson marketplace. > > Now, I'm certainly not arguing that it wouldn't be interesting to talk about > extranet access control, and PKI-based authorizations that extend beyond the > boundaries of one organization. It would be interesting, and I and others have > been talking about that for what seems like eons. > > But by and large, it isn't happening. > > Is this, as some would claim, due to the fact that we haven't solved the directory > naming problem? > > No, the problem is deeper than that. > > The problem is one of TRUST. > > And I would claim, with some regret, that PKI isn't about TRUST, it is about > IDENTITY. > > Unfortunately, when it comes to making an access control decision, it isn't > sufficient to have a chain of certificate stretching back to some ubiquitous > issuer of low-cost certificates which attests to the fact that the holder of > a given private key is in fact cn="Village Idiot #13", even if he really is. > > If I'm the system administrator, I don't care who someone IS, I want to > know what that person is permitted to DO. > > At least at present, the way that people are controlling those decisions is to > pre-enroll that individual into an authoritative directory or database, and then > assign or share some secret with that individual which can be used to > authenticate that person as the same individual that was authorized, assuming > he hasn't shared that secret with someone else. > > Granted, there are nuances of security and control, but the bottom line is > that it isn't the person's DN that matters, assuming that DN can be found > somehow. The only thing that really matters is the shared secret, and > the fact that the person who knows that secret has been granted certain > permissions or authority. > > Whether that secret is a password, a private key, or some token device > is of secondary importance to the fact of pre-enrollment and the granting of > access authority. > > So the lack of a universal naming solution, although irritating to those of us > in the profession, hasn't yet reach the point of being a crisis with our customers, > because those customers either don't allow external users into their system at > all, or they base their decisions on other things than identity, such as whether or > not the person has a valid credit card account, and it isn't maxed out. > > Note that I have been talking exclusively about access control, and not > legally-binding transactions or other aspects of a more global use of PKI, > where identity may (someday) play a larger role. But even in that context, > I would claim that trust comes first, and is anchored by identity, and not > the other way around. > > Regards, > > Bob > > Robert R. Jueneman > Security Architect > Novell, Inc. -- the leading provider of Net services software. Bob, when taking privacy aspects into account, for several services, you even don't want to give your identity as a credential for access control. For the access control SERVICE trust comes first anchored by identity. For the access control USER trust comes first, anchored by guaranteeing the service and privacy. Indeed in the closed enterprise environment privacy is a non issue. In an inter business environment privacy isn't really an issue, you want to have a guarantee which role a person has. I think both can be addresses with the Privilege Management infrastructure using attribute certificates, for the time being access control providers misuse the identity certificate for giving privileges! Where identity really is an issue, are those type of actions where in real life you have to show your passport or similar paper or where a handwritten signature is required. I would claim that the LEVEL of trust is dependable of the SERVICE and on which side of the service you are. The current LEVEL of trust of access control solutions (established BY the enterprise FOR the enterprise) has to be a little bit higher as the username/password scheme has, for the user (employee) trust is a non issue. Access control solutions established by the enterprise for the public have other requirements, here trust is really an issue. I agree on some action about: 1. defining (attribute) certificate profiles for access control 2a. defining some sort of Attribute Authority or credential Service for generating the certificates based on a identity certificate and taken into account of the privacy wishes of the identity. 2b or defining some sort of gateway or proxy which can be fed by an identity certificate and spits out some sort of other credential, based on the identity's wishes. And in my view, as I would build a pki for our domain, the origin of this information is controlled by the identity, using his bare identity certificate, which is as basic as can be. All the other attributes are stored in the identity's corresponding ldap-entry using the same DN. One of them could be the access control attribute (certificate), maybe one want to generate this privilege on the fly. I think identity certificates are usable as we do today, not for win2k but who cares ;-) btw the EU has released a eye-opening working document on privacy issues on the Internet: http://europa.eu.int/comm/internal_market/en/media/dataprot/wpdocs/index.htm regards, janus From owner-ietf-pkix Tue Jan 9 15:48:44 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA03780 for ; Tue, 9 Jan 2001 15:48:43 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA15943; Tue, 9 Jan 2001 18:53:33 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200101081827.TAA16605@emeriau.edelweb.fr> References: <200101081827.TAA16605@emeriau.edelweb.fr> Date: Tue, 9 Jan 2001 18:51:39 -0500 To: Peter Sylvester From: Stephen Kent Subject: RE: DPD & DPV requirements - Let us Recurse Cc: ietf-pkix@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Peter, > > >What do you mean by revocation status not quite perfect? A server >makes a desision, and tells what it had looked at, it may happen >that another server verifier looks at the same data in a different >way, and comes to another conclusion; this tru independant of >whether the first returns its justifications or not. One entity >might validate a cert chain, another might not, etc. Returning >as much as possible data about why one decision has been made >does not change that. What if a server has a CRL for a along the path but the CRL is old, and the server cannot get a current one? The simple answer is that the validity of the target cert is unknown, but that may not be a totally satisfying answer. You are correct that we face this problem already for DPV (for DPD we could return what we have and let the client work it out) irrespective of whether we have to return justifications. As we move into "explaining" an evaluation, I was thinking that we might want to be more sophisticated about the whole process, but that was sloppy on my part. You're right! >If a client has a user interface to explain a server decision, >it seems necessary anyway to display certificates, elements on >a CRL, OCSP reponses, PKIStatus data. > >We already have the problem of user interfaces of certificate >and CRL displays, and also of how to display responses from >a OCSP server, or from the new services to be standardized. >But do we actually care? But: I don't see in other pkix standards a >description of about how a certificate chain has to be presented >or even a single certificate. No, the last RFC to broach the subject of cert path info presentation was 1422, for PEM! If we return status, cert chains and revocation status, then we get to ignore this. But, if we return what purports to be an "explanation" of why a cert is valid, then I think we have opened up a can of worms with regard to user interface issues, because the purported customer for the explanation. This is especially true for DPV and non-PKI aware clients. >What seems useful to me is to specify a list of elements that may >be supposed to be presented to users. Such a list should be a simple >as possible, contain a small number of different data type that >allow to express a large set of situations, so that we don't have >to add new stuff each 6 months or 3 years. We have already *MANY* >standards that return 'status information' in different ways. >One question here would be: Is it more appropriate to use a >new textual format like in SCVP or something like PKIStatus as >used in several standards maybe accompanied by OCSP responses? I think the answer has to be driven by the context in which the response is to be used. For machine consumption a binary status representation is appropriate, but for a human user, text is preferable. However, in the latter case, I think we are entering a very complex arena that, as you noted, we have avoided in the past, re HMI for PKI info. Steve From owner-ietf-pkix Tue Jan 9 17:07:31 2001 Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05524 for ; Tue, 9 Jan 2001 17:07:30 -0800 (PST) Received: from libero.it (193.70.192.41) by smtp1.libero.it (5.5.015.5) id 3A531603004F2B4F for ietf-pkix@imc.org; Wed, 10 Jan 2001 02:11:58 +0100 Date: Wed, 10 Jan 2001 02:10:45 +0100 Message-Id: Subject: unsubscribe MIME-Version: 1.0 X-Priority: 1 (Highest) Content-Type: text/plain From: "vinicia.leone@libero.it" To: ietf-pkix@imc.org X-XaM3-API-Version: 1.1.9.1.31 X-SenderIP: 213.45.249.245 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id RAA05525 unsubscribe vinicia.leone@libero.it From owner-ietf-pkix Tue Jan 9 18:52:17 2001 Received: from poptop.llnl.gov (poptop.llnl.gov [128.115.41.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA07064 for ; Tue, 9 Jan 2001 18:52:17 -0800 (PST) Received: from catalyst (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA17063; Tue, 9 Jan 2001 18:56:15 -0800 (PST) Message-Id: <4.2.2.20010109185955.00ac0260@poptop.llnl.gov> X-Sender: e048786@poptop.llnl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 09 Jan 2001 19:01:57 -0800 To: Janus Liebregts From: Tony Bartoletti Subject: Re: Basic Cert-2-Directory mapping question Cc: ietf-pkix@imc.org In-Reply-To: <3A5B8452.3B84568A@surfnet.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:36 PM 1/9/01 +0100, Janus Liebregts wrote: >btw the EU has released a eye-opening working document on privacy issues >on the Internet: >http://europa.eu.int/comm/internal_market/en/media/dataprot/wpdocs/index.htm Thanks Janus! A readable, educational and enlightened document! ___tony___ Tony Bartoletti 925-422-3881 Information Operations, Warfare and Assurance Center Lawrence Livermore National Laboratory Livermore, CA 94551-9900 From owner-ietf-pkix Wed Jan 10 00:05:32 2001 Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26342 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST) Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id DA94E67C7D for ; Wed, 10 Jan 2001 09:08:57 +0100 (CET) Sender: michael@ms.inka.de Message-ID: <3A5C1899.E1BDA21D@stroeder.com> Date: Wed, 10 Jan 2001 09:08:57 +0100 From: Michael =?iso-8859-1?Q?Str=F6der?= Organization: stroeder.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Basic Cert-2-Directory mapping question References: <97888367312331@kahu.cs.auckland.ac.nz> <002001c078d1$ebab1650$0201a8c0@vincent.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders Rundgren wrote: > > BOF-like feasibility study to see if DNs must continue > to be broken until the end of time? The main problem is that the world is not hierarchical or more precise: There are so many possibilities even within small organizations to divide them into a hierarchy. Not to speak of connecting the names spaces of different organizations... Most X.500 directory books suffer from not accepting this. Ciao, Michael. From owner-ietf-pkix Wed Jan 10 00:05:32 2001 Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26341 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST) Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id A721A680E2 for ; Wed, 10 Jan 2001 09:09:03 +0100 (CET) Sender: michael@ms.inka.de Message-ID: <3A5C189F.56D05B6C@stroeder.com> Date: Wed, 10 Jan 2001 09:09:03 +0100 From: Michael =?iso-8859-1?Q?Str=F6der?= Organization: stroeder.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: Re: Basic Cert-2-Directory mapping question References: <97899599117616@kahu.cs.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > > Stephen Kent writes: > > >I have not read your paper, but the assertion that DNs don't work, without > >substantiation, seems a bit strong. > > [.. Very many valid points by Peter deleted..] Peter, I completely agree with you. IMHO one of the main problems with PKIX is that there's so much X.500 in it. ;-) (I enjoyed your writing about T.61...) > The sole meaningful piece of information in any of my certs is my email > address Agreed again. And IMHO the e-mail address combined with fast searching (the real advantage of directory servers) is the only working solution for a person's entry today. > That's the point I made in the analysis in my > paper, noone (well, almost noone :-) actually uses a DN in the way X.500 says > it's supposed to be used. And if you try it's sometimes even hard to find the "right" value for the CN person's attribute of a person's entry. BTW: Ed Gerck wrote a nice paper about these naming problems too (available around '98 if I remember correctly). > >finally, the IETF has had a standard means of encoding a DNS name as a DN for > >several years, which suggests that there is at least one scheme that would > >work. > > (I have a vague > memory of actually having seen a solitary DC in a cert somewhere, but a quick > check of my collection has failed to locate one... ;-) > does anyone know of examples of these being used? Yes. > How does the average third-party app handle > them?). OpenSSL can handle them. Netscape Messenger seems to be able to use them. web2ldap displays them... Ciao, Michael. From owner-ietf-pkix Wed Jan 10 00:05:33 2001 Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26343 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST) Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 1034167C5B for ; Wed, 10 Jan 2001 09:08:50 +0100 (CET) Sender: michael@ms.inka.de Message-ID: <3A5C1891.834ED21D@stroeder.com> Date: Wed, 10 Jan 2001 09:08:49 +0100 From: Michael =?iso-8859-1?Q?Str=F6der?= Organization: stroeder.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Basic Cert-2-Directory mapping question References: <97888367312331@kahu.cs.auckland.ac.nz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Kent wrote: > > I have not read your paper, but the assertion that DNs don't work, > without substantiation, seems a bit strong. Certainly when people > create arbitrary DNs, without regard to the semantics of directory > structure, bad things happen. Please review some discussion threads on LDAP-related lists about directory tree design........................never-ending story. Suggestions are ranging from traditional X.521 naming to flat-tree name space under a dc=domain,dc=domain root. > Also, it is fair to say that the grand, > nations as top level directory operators model that X.500 envisioned > has not happened, Even if it would have happened X.521 tree naming would simply suck. Think of multi-national companies which are not eager revealing their directory structure to the public. Not to speak of the different country-dependent rules for the registration process... > finally, the IETF has had a standard means of encoding a DNS name as > a DN for several years, which suggests that there is at least one > scheme that would work. I agree that DNS-based naming (often called dc naming in the LDAP world) is a way of at least find a division for global and organizational name space. System admins are used to it and they have to sub-divide their organizations into DNS sub domains anyway (which is a pretty hard job though). But who of you on the list has a mail address name@sub.domain.com or even name@sub2.sub1.domain.com? Will you agree with your admin if you're assigned such an e-mail address? No, you will ask him for a shorter one. Or you will go to a cheap free mail service to get a shorter one. Or register your name as domain (me too ;-). => People are used to flat name spaces. X.500 DNs does not work. Ciao, Michael. From owner-ietf-pkix Wed Jan 10 00:05:31 2001 Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26337 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST) Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id 5843C67C80 for ; Wed, 10 Jan 2001 09:09:01 +0100 (CET) Sender: michael@ms.inka.de Message-ID: <3A5C189C.97077CB7@stroeder.com> Date: Wed, 10 Jan 2001 09:09:00 +0100 From: Michael =?iso-8859-1?Q?Str=F6der?= Organization: stroeder.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Basic Cert-2-Directory mapping question References: <200101081828.NAA17320@stingray.missi.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "David P. Kemp" wrote: > > The Web works only because every Internet URL begins with > DNS-registered name. For most users the web works like this: www.mycompany.com This is a completely flat name space. And yes, I know that one can even create valid URLs like http://host1.subdomain.domain.net... ;-) Ciao, Michael. From owner-ietf-pkix Wed Jan 10 00:05:31 2001 Received: from junker.ms.inka.de (pD901CD06.dip.t-dialin.net [217.1.205.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26338 for ; Wed, 10 Jan 2001 00:05:29 -0800 (PST) Received: from stroeder.com (localhost [127.0.0.1]) by junker.ms.inka.de (Postfix) with ESMTP id C8A0E680E3 for ; Wed, 10 Jan 2001 09:09:05 +0100 (CET) Sender: michael@ms.inka.de Message-ID: <3A5C18A1.8757F062@stroeder.com> Date: Wed, 10 Jan 2001 09:09:05 +0100 From: Michael =?iso-8859-1?Q?Str=F6der?= Organization: stroeder.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.18 i686) X-Accept-Language: de-DE, de, en MIME-Version: 1.0 To: "ietf-pkix@imc.org" Subject: Re: Basic Cert-2-Directory mapping question References: <3A5B32DF.6AA8A7F2@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oscar Jacobsson wrote: > > Bob Jueneman wrote: > > What we need, and have needed for ten years, is a STANDARD! > > Apart from the fact that RFC 2377 is "only" Informational, are there any > perceived problems with the naming plan it proposes that I'm unaware of? > I should probably add that I've yet to attempt to implement an > infrastructure using this naming scheme yet. :-) ldap://root.openldap.org Ciao, Michael. From owner-ietf-pkix Wed Jan 10 01:17:50 2001 Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06523 for ; Wed, 10 Jan 2001 01:17:50 -0800 (PST) Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <0G6X00301WPO4Z@ext-mail.valicert.com> for ietf-pkix@imc.org; Wed, 10 Jan 2001 01:22:36 -0800 (PST) Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <0G6X0031AWPN05@ext-mail.valicert.com>; Wed, 10 Jan 2001 01:22:36 -0800 (PST) Received: by exchange.valicert.com with Internet Mail Service (5.5.2650.21) id ; Wed, 10 Jan 2001 01:18:35 -0800 Content-return: allowed Date: Wed, 10 Jan 2001 01:18:34 -0800 From: Ambarish Malpani Subject: RE: OCSP authorized responder clarification. To: "'Dr S N Henson'" , PKIX-List Message-id: <613B3C619C9AD4118C4E00B0D03E7C3E6EBDBA@exchange.valicert.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Hi Steve, You are absolutely right - the CA needs to directly authorize the OCSP responder to respond on its behalf. The fact that the root authorized you to respond doesn't allow you to respond for all CAs certified by that root in the CA delegated trust model of OCSP. Regards, Ambarish --------------------------------------------------------------------- Ambarish Malpani Architect 650.567.5457 ValiCert, Inc. ambarish@valicert.com 339 N. Bernardo Ave. http://www.valicert.com Mountain View, CA 94043 > -----Original Message----- > From: Dr S N Henson [mailto:drh@celocom.com] > Sent: Monday, January 08, 2001 4:34 AM > To: PKIX-List > Subject: OCSP authorized responder clarification. > > > In RFC2560 4.2.2.2 the certificate signing an OCSP request is valid if > it: > > > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage > > extension and is issued by the CA that issued the certificate in > > question." > > A certain CA issues end user certificates signed by an intermediate CA > which is in turn signed by the root CA. > > The responder certificate is signed by the root CA. Does this, as > appears to be the case, mean that the above condition does not apply > because the OCSP reponder certificate is not signed by the > intermediate > CA? > > Alternatively is the condition satisfied because they both > have the same > root CA? > > Steve. > -- > Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ > Personal Email: shenson@drh-consultancy.demon.co.uk > Senior crypto engineer, Celo Communications: http://www.celocom.com/ > Core developer of the OpenSSL project: http://www.openssl.org/ > Business Email: drh@celocom.com PGP key: via homepage. > From owner-ietf-pkix Wed Jan 10 02:32:58 2001 Received: from gadolinium.btinternet.com (gadolinium.btinternet.com [194.73.73.111]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14673 for ; Wed, 10 Jan 2001 02:32:57 -0800 (PST) Received: from [195.99.54.165] (helo=vaio) by gadolinium.btinternet.com with smtp (Exim 3.03 #83) id 14GIdh-0001ue-00 for ietf-pkix@imc.org; Wed, 10 Jan 2001 10:37:57 +0000 Message-ID: <003201c07af2$226088c0$a53663c3@vaio> Reply-To: "Liaquat Khan" From: "Liaquat Khan" To: "PKIX-List" References: <613B3C619C9AD4118C4E00B0D03E7C3E6EBDBA@exchange.valicert.com> Subject: Re: OCSP authorized responder clarification. Date: Wed, 10 Jan 2001 10:43:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Just to confirm that the GTA has come to the same conclusion. As such, the CA which has given authorisation to the OCSP responder is also the one that issues the OCSP responder with the certificate for its public key. Within the GTA model, a particular OCSP responder's public key could be certified by more than one CA. Directly certifying an OCSP responder has the advantage that one OCSP responder cannot potentially 'spoof' another OCSP responder within the same infrastructure. A root certifying all OCSP responders within an infrastructure could potentially open up this security concern. Regards, Liaquat ----- Original Message ----- From: "Ambarish Malpani" To: "'Dr S N Henson'" ; "PKIX-List" Sent: Wednesday, January 10, 2001 9:18 AM Subject: RE: OCSP authorized responder clarification. > > Hi Steve, > You are absolutely right - the CA needs to directly authorize > the OCSP responder to respond on its behalf. The fact that the > root authorized you to respond doesn't allow you to respond for all > CAs certified by that root in the CA delegated trust model of OCSP. > > Regards, > Ambarish > > > > --------------------------------------------------------------------- > Ambarish Malpani > Architect 650.567.5457 > ValiCert, Inc. ambarish@valicert.com > 339 N. Bernardo Ave. http://www.valicert.com > Mountain View, CA 94043 > > > > -----Original Message----- > > From: Dr S N Henson [mailto:drh@celocom.com] > > Sent: Monday, January 08, 2001 4:34 AM > > To: PKIX-List > > Subject: OCSP authorized responder clarification. > > > > > > In RFC2560 4.2.2.2 the certificate signing an OCSP request is valid if > > it: > > > > > 3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage > > > extension and is issued by the CA that issued the certificate in > > > question." > > > > A certain CA issues end user certificates signed by an intermediate CA > > which is in turn signed by the root CA. > > > > The responder certificate is signed by the root CA. Does this, as > > appears to be the case, mean that the above condition does not apply > > because the OCSP reponder certificate is not signed by the > > intermediate > > CA? > > > > Alternatively is the condition satisfied because they both > > have the same > > root CA? > > > > Steve. > > -- > > Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ > > Personal Email: shenson@drh-consultancy.demon.co.uk > > Senior crypto engineer, Celo Communications: http://www.celocom.com/ > > Core developer of the OpenSSL project: http://www.openssl.org/ > > Business Email: drh@celocom.com PGP key: via homepage. > > > From owner-ietf-pkix Wed Jan 10 09:44:10 2001 Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19042 for ; Wed, 10 Jan 2001 09:44:09 -0800 (PST) Received: from [171.78.30.107] (comsec.bbn.com [171.78.30.107]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA00706; Wed, 10 Jan 2001 12:49:07 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <3A59B018.90B0ACB@bull.net> References: <009601c06682$4bafd4d0$0201a8c0@vincent.se> <013101c066c3$d63b4bc0$0201a8c0@vincent.se> <004401c06739$f7b9f550$0201a8c0@vincent.se> <3A51B25D.A449FC37@bull.net> <3A59B018.90B0ACB@bull.net> Date: Wed, 10 Jan 2001 12:43:40 -0500 To: Denis Pinkas From: Stephen Kent Subject: Re: DPD & DPV requirements Cc: PKIX-List Content-Type: multipart/alternative; boundary="============_-1232973474==_ma============" --============_-1232973474==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable Denis, >Steve, > >See my responses embbeded with your comments. > >=20 > Denis, >=20 > >=20 > Steve, >=20 > >=20 > First of all, many thanks for posting this long document. >=20 > >=20 > I will not respond using directly your text, since my arguments >=20 > are fairly different. I will however re-use some of your argumen= ts. >=20 > >=20 > Let us use the concept of "validation policy", that you=20 >introduce, which is >=20 > all the set of rules to be followed when validating a=20 >certificate. It will >=20 > usually not simply be the rules mentioned in RFC 2459, but=20 >these rules with >=20 > additional conditions. Note that in the context of=20 >electronic signatures, a >=20 > "signature policy" is a specific example of a "validation policy= ". >=20 > > >[Steve] > >We need to be explicit about what are the parameters that control path >validation. The 2459 validation algorithm has a well-defined set, but if >there are others, we need to have them specified and agreed upon. One >conversation that took place in San Diego noted that one could imagine a lo= t >of parameters that a user might want to express re path validation, but >which have not been standardized, and for which we do not have general >agreement. A very rich list of this sort, and the associated complexity tha= t >would accompany an enhanced validation algorithm that used thise parameters= , >was thought to be out of scope for now, more an R&D topic vs. a topic for >standardization. So we have to be careful here. > > >[Denis] > >The current validation algorithm described in RFC 2459 is fine but too >restritive. It works fine with a single root key in the case where there ar= e >no naming constraints nor Certification Policy constraints, or in the case >where there are are included in the (root) self-signed certificates. I have >worked with Tim Polk so that in the "son-of-RFC2459" we will have the >description of an enhanced path validation algorithm that will take care of >multiple roots, each one associated with different naming constraints or >Certification Policy constraints - which will not necessarilly be included >in the root self-signed certificates. Self-signed certs are not the only way to deal with multiple roots,=20 and it often seems to me that they are a poor way, when we want to=20 make use of features like naming constraints. Why not just have cross=20 certs issued to other "roots" by a local CA and embed the naming (and=20 policy?) constraints into those cross certs? > >So we would need to support two options, which are not mutually exclusive: > >=20 1) define with a great level of accuracy each of the parameters, or >=20 2) provide an OID which is a global reference to all these parameters. > > >=20 > DPV >=20 > =3D=3D=3D >=20 > >=20 > Let us start with DPV first. A DPV client will not=20 >necessarily be either >=20 > PKI-aware, nor ASN.1 aware. I thus see two flavors for a DPV pro= tocol: >=20 > >=20 > 1) one not using ASN.1 (e.g. using XML), >=20 > 2) one using ASN.1. >=20 > >=20 > In both cases the client only supplies an unambiguous reference= of the >=20 > certificate (CA name, serial number and a hash of the=20 >certificate) or the >=20 > certificate itself and specifies the rules to be followed to=20 >validate the >=20 > certificate: an identification of a pre-defined "validation=20 >policy" (e.g. an >=20 > OID and/or a URL to find the policy and a hash of that=20 >validation policy). >=20 > > >[Steve] > >Given the problems we have had in OCSP (v1) re referring to a target cert, = I >am not comfortable specifying a target cert other than by providing a copy >of that cert to the server. > > >[Denis] > > >In a signed CMS message, you may only have the EESCertID, without the >certificate itself. > >=20 ESSCertID ::=3D SEQUENCE { >=20 certHash Hash, >=20 issuerSerial IssuerSerial OPTIONAL >=20 } > >=20 Hash ::=3D OCTET STRING -- SHA1 hash of entire certificate > >=20 IssuerSerial ::=3D SEQUENCE { >=20 issuer GeneralNames, >=20 serialNumber CertificateSerialNumber >=20 } > >The idea is to be able to use ESSCertID without the need to fetch the >certificate itself. I see your example, but I also stand by my observation that providing=20 anything other than the target cert per se has potential problems and=20 adds complexity to the server. We'll have to decide whether we want=20 to impose such adde complexity on servers, and whether we can provide=20 clean, algorithmic means of dealing with this complexity. >=20 > As a result, the client expects a signed response which= reproduces the >=20 > requested parameters and includes a status. The status is not si= mply: >=20 > "passed validation", "failed validation", or "don't' know"=20 >but can also be >=20 > "incomplete validation", meaning that some revocation status=20 >information is >=20 > not yet available at the time of processing and a later attempt = might >=20 > succeed. >=20 > > >[Steve] > >Incomplete validation is a reasonable response. Yes, it will have to be one of the responses, hopefully with an=20 explanation of what caused the response to be incomplete. > >[Denis] > >:-) > >[Steve] > >maybe we should include the >set of parameters used for the validation, including ones not supplied by >the client, e.g., defaults, or overrides imposed by the server, or the >values bound to a policy that was specified. > >[Denis] > >We are not on the same track here. I am assuming that a DPV client is PKI >ignorant. You are making the assumption that the client MAY simply some >elements of the certification path, where I make the assumption that the >single element that MAY be supplied in a DPV request is the leaf >certificate. For all the other elements of a certification path, the server >is supposed to have access to the various repositories. The response >contains a blob of what has been used, that can be blinding copied and >stored. A DPV client MAY be not PKI-aware, but that is not the only case we=20 agreed to address. I'll need to see more comments from WG members to=20 persuade me that we wish to restrict DPV interactions to clients that=20 are presumed to be PKI-ignorant, to use your term. > >=20 > The response must include the time at which the validation has b= een >=20 > performed. Allowing to test a certificate "in the past",=20 >would place some >=20 > requirements that cannot always be accomplished by a=20 >standard PKI: currently >=20 > we do not mandate CAs to maintain revocation information=20 >beyond the end of >=20 > the validity period of a certificate. We should not change=20 >that rule. So I >=20 > am very reluctant to autorise validation in the past, e.g.=20 >10 years later. >=20 > > >[Steve] > >Good points; we should include the time of the response. I added the "in th= e >past" requirement based on its inclusion in SCVP, but there clearly limits >to one's ability to support that feature. However, if the server is uable t= o >verify a cert relative to a prior time, based on unavailability of some >revocation data, it can always state that in a response. One might add a >requirement to allow the server to be configured to reject requests for >validation that cite a time/date prior to some confugured value. > > >[Denis] > >Since archiving of recocation information is not mandated to the CAs, such = a >function would need to be provided by some other trusted service provider. >We should be very careful before allowing the provision of such a new >service. I believe that the PKI is already sufficiently complex so that we >make our best efforts not to introduced additional Trusted Service Provider= s >(that could be avoided). The only case to be supported should be the >"current time" and some time "soon after the end of validity of a >certificate" (i.e. a few weeks, in case someone being on holidays would lik= e >to check, when coming back from holidays, if a received message, was signed >by a revoked certificate or not). There was some sentiment for having the "was it valid then" function=20 as provided in SCVP, but if there is not continued support we could=20 delete it. I want to get more feedback on this issue. >=20 > If a client is interested in a later proof, then it should= obtain that >=20 > information from the server at the time the information is=20 >still available. >=20 > This means that a client should have the possibility to ask=20 >the server to >=20 > optionally return an opaque blob that contains all what has=20 >been used to >=20 > validate the certificate (i.e. a certification path and all=20 >the CRLs or >=20 > OCSPs needed for each certificate from the path). >=20 > > >[Steve] > >We have this requirement already, with a time stamp option. > >[Denis] > >We should remove the time stamp option. Yes, we could. >=20 > A question arises from the requirements 1.5 and 1.6 that you=20 >listed: should >=20 > that opaque blob be time-stamped ? If there is a fear that some= of the >=20 > issuing keys used in the certification path might later on=20 >be compromised, >=20 > then this can be useful. This case should be very seldom and=20 >hence this >=20 > service would not always be required. In addition, why=20 >should that service >=20 > be embedded in this protocol ? This could be obtained using=20 >directly the >=20 > TSP, leaving more possibilities: free choice of the TSAs,=20 >time stamp of the >=20 > full blob, time stamp of the certification chain only, time=20 >stamp on both >=20 > the certification chain and the revocation information. Thus=20 >I do not favor >=20 > to piggy-back the two services. >=20 > > >[Steve] > >Yes, one could keep the services separate. I am not hard over on this, and >can be persuaded to remove the requirement, or to make server support for i= t >optional. > > >[Denis] > >If you are not hard on this issue, let us remove the time stamping option. > >:-) I'll remove it if I hear from a few more people who agree that it is=20 best provided as a separate call to a TSA. >=20 > In order to simplify the protocol and allow for PKI-ignorant=20 >clients, the >=20 > client should NOT be allowed to provide any other element than t= he >=20 > certificate, that might help to construct the path or the revoca= tion >=20 > information. >=20 > > >[Steve] > >I don't see the rationale for this. We already have application protocols >where a client that is not PKI-aware might acquire cert paths and/or >revocation data that it could pass on to a DPV server. So, I don't think yo= u >have made a good argument here for not allowing such data to be transm