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-CRL