Subject: roadmap

From: Peter Sylvester <[email-masked]>
Date: Fri, 19 Apr 2002 19:36:21 +0200 (MET DST)

Since I have not had a response from the editors of the roadmap, I'll
repeat some questions thta I have with the raodmap, propose some
textual changes, and some small nit-picking. 

I wonder which writing of Als name is correct. 

PKIX Working Group                                        A. Aresenault

OCSP and CMP are mentioned as 'draft standard', I guess this
should be 'proposed standard'

In order to more correctly reflect history I propose on page 7:

   protocol. [OCSP] was developed to address concerns that not all 
   relying parties want to go through the process checking CRLs from 
   every CA in the certification path. It defines an on-line mechanism 
   to determine the status of a given certificate, which may provide 
   more timely revocation information than is possible with CRLs. 

   [DVCS] also contains a service to determine the validity of 
   public key certificate using a TTP permitting to present the result
   of the verification as evidence in a non repudiation context.

   Another approach allowing relying parties to off-load all of
   their certification verification to another entity is the
   Simple Certification Verification Protocol (SCVP), for which a
   draft exist actually [SCVP]. 

I repeat my question to give a reference indicating where SCVP
has been selected as "THE" protocol. 

?   After considerable debate, 
?   the WG selected SCVP as the PKIX protocol for delegated path 
?   validation and delegated path discovery. A requirements document has 
?   been developed, and is currently under WG review. [DPREQ] Upon 
?   completion of [DPREQ], the SCVP protocol will be completed. 

?   specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating 
?   (though in [TSP] request for a time stamp are not required to use 
?   [CMS]). 

encapsulating what? 

   Both [DVCS] and [TSP] define CMS contenttypes to transport protocol
   information. [TSP] optionally uses CMS SignedData and an encapsulatin
   security envelope as an option for the requests, and mandatory for
   the resulting tokens. [DVCS] allow the optional usage of CMS security 
   envelopes permitting to authenticate requests and responses. 

           A draft for extending trust in tokens in time was developed 
   to use [DCVS] to maintain the trust in a token issued by a non- 
           DVCS
   repudiation Trusted Third Party (NR TTP) after the key initially used 
   to establish trust in the token expires; however, this draft has 
   expired. The [TRNRS] draft was developed to describe those features 
   of a service which processes signed documents that must be present in 
   order for that service to constitute a "technical non- repudiation" 
   service. 

I have the feeling that something is wrong in the following: 

     - PKC holders that are issued certificates and can sign digital 
       documents and encrypt documents; 
      
     - Clients that validate digital signatures and their certification 
       paths from a known public key of a trusted CA; 

Is an OCSP or DPV service part of a PKI? 

In a previous mail I have proposed an updated descrition of DVCS
reflecting the actual status of RFC 3029. 

     DESCRIPTION: This specification builds on the Online Certificate 
     Status Protocol (OSCP) framework's extensibility by defining an 
                      OCSP 

"The lifetime of the object being singed."
                                  signed.

In the acknowledge list there is "Ed Greck', it should be 'Ed Gerck'
as far as I remember.

Very interesting alphabetic order :-)

please use ASCII characters instead of "ö" several occurences in
the References list. 

some examples:

   [TECHNR] Gindin, T., ôInternet X.509 Public Key Infrastructure 
   Technical Requirements for a non-Repudiation Service,ö <draft-ietf- 
   pkix-technr-01.txt>, July 2000. 

   [TPCMP] Kapoor , A., Tschal, R., ôTransport Protocols for CMP,ö