headers
Hoyt L. Kesterson II | 2 Aug 2002 08:09
Picon
Favicon

announcement of x500 meeting


The directory group will be meeting 16-20 September 2002 at the 
facilities of the National Institute of Standards and Technology. The 
meeting announcement is at 
ftp://ftp.bull.com/pub/OSIdirectory/NIST2002/6N12267announcement.pdf.

We will resolve ballot comments on the Friend Attribute PDAM and the 
Distributed Paged Results PDAM. The ballot period closes 10 August 
2002. We will advance the Working Documents on enhancements to 
certificates, on LDAP alignment, and on Related Entries.

The PDAMs and the Working Documents can be found at

    ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output

We will also be resolving comments against Draft Technical Corrigenda 
that are correcting defects against X.509/9594-8. The ballot period 
on these DTCs ends 15 September 2002. They can be found at

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing15September2002

      hoyt
Permalink | Reply | 0 comments |
headers
Paul Hoffman / IMC | 28 Aug 2002 01:38
Picon

Nomcom call for volunteers


Forwarded for Phil Roberts <PRoberts <at> MEGISTO.com>:

The members of the IESG and IAB and the IETF chair are selected
by a nominations committee made up of volunteers from the
IETF community.  The nominations committee is now in the process
of being formed and volunteers are being accepted until Sep 6.
Please see (http://www.ietf.org/nomcom/msg19765.html)
for information if you are interested in volunteering
to be on the nominations committee.
Permalink | Reply | 0 comments |
headers
carol | 29 Aug 2002 03:16
Picon

Ocsp Responder and AuthorityInfoAccessSyntax Question


Hello everybody,

   In our CA system, their are several ocsp responders. One can ask two ocsp responders
   for the status of a certficate, for example http://global and http://local . 
   In such situation, what should be the AuthorityInfoAccess extension like?

   case 1: only one AccessDescription node in AuthorityInfoAccessSyntax

     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://global;http://local

   case 2: set two  AccessDescription nodes in AuthorityInfoAccessSyntax
     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://global

     AccessMethod  : id-at-ocsp
     AccessLocation(URI): http://local

   Which of the above is more preferable? Or is there any standard/suggestion
   for such situation?

   Thanks a lot for any answer.

 wcarol
Permalink | Reply | 1 comment |
headers
Peter Gutmann | 1 Aug 2002 05:01
Picon
Picon
Picon
Favicon

Re: TSP interoperability testing (RFC 3161)


Denis Pinkas <Denis.Pinkas <at> bull.net> writes:

>At the Yokohama meeting, during my presentation on RFC3161bis, I advertised
>that despite the existence of about 10 different implementations of RFC 3161,
>interoperability testing of TSP had not yet been done.

Actually Peter Sylvester has done a fair bit of this with his TSA and assorted
clients... in fact I think there's been quite a bit of informal testing, just
no big grand unified test.

Peter.
Permalink | Reply | 0 comments |
headers
Peter Sylvester | 1 Aug 2002 14:51
Picon
Picon
Favicon

Re: TSP interoperability testing (RFC 3161)


> 
> >At the Yokohama meeting, during my presentation on RFC3161bis, I advertised
> >that despite the existence of about 10 different implementations of RFC 3161,
> >interoperability testing of TSP had not yet been done.
> 
> Actually Peter Sylvester has done a fair bit of this with his TSA and assorted
> clients... in fact I think there's been quite a bit of informal testing, just
> no big grand unified test.

Indeed, since October 1st 2000, see http:://timestamping.edelweb.fr
Permalink | Reply | 5 comments |
headers
Pawling, John | 1 Aug 2002 17:46

v1.4 Enhanced SNACC Freeware Now Available


All,

Getronics Government Solutions has delivered the v1.4 eSNACC
Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library
source code compilable for Linux, Sun Solaris 2.8 and Microsoft (MS) 
Windows NT/98/2000/XP.  The eSNACC software is freely available to
everyone from: <http://www.getronicsgov.com/hot/snacc_home.htm>.

The eSNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, Getronics improved the eSNACC C++ 
library to implement the Distinguished Encoding Rules (DER), 
support large ASN.1 INTEGERs, and improve memory usage.    

v1.4 eSNACC enhancements (compared to v1.3 R10 release):

1) Enhanced AsnInt class to support string form of large 
integers (binary & hex strings).   

2) Enhances AsnInt so that it does not use AsnOcts or 
CSM_Buffer. 

3) Remove CSM_Buffer as base class for AsnInt and all of 
the string classes.  Also deleted the xxxStringSNACC 
classes (i.e., BMPStringSNACC).  

4) Added the remaining asn-useful types (UTCTime, 
GeneralizedTime, etc.) into eSNACC C and C++ libraries as
native built-in types.  This removes the unnecessary
complexity of having to build a boot compiler prior to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pawling, John | 1 Aug 2002 19:24

v2.1 Certificate Management Library (CML) Now Available


All,

Getronics Government Solutions has delivered the Version 2.1 
Certificate Management Library (CML) for Microsoft Windows, 
Sun Solaris and Linux.  The v2.1 CML and documentation is 
freely available at:
<http://www.getronicsgov.com/hot/cml_home.htm>.  

Applications requiring Public Key Infrastructure (PKI) security 
services can use the CML to meet their X.509 certificate and 
Certificate Revocation List (CRL) processing requirements.  
The v2.1 CML is described in the v2.1 CML Application Programming
Interface (API) document.  It implements the 2000 X.509 Recommendation
certification path verification processing rules and SDN.706 profile.
It meets the majority of the IETF PKIX RFC 3280 Certificate/CRL Profile
requirements.  There are some unsupported features such as 
Delta CRLs.  The v2.1 CML Abstract Syntax Notation One (ASN.1)
decodes X.509 Certificates and CRLs.  It requires the v1.4
Enhanced SNACC ASN.1 software that is freely available from:
<http://www.getronicsgov.com/hot/snacc_home.htm>.

The CML provides robust certificate path building capabilities such
as using cross certificates.  The CML uses the accompanying Storage 
and Retrieval Library (SRL) (optionally) to provide local certificate
and CRL storage management functions.  The SRL (optionally) provides 
remote directory retrieval capabilities using the Lightweight
Directory Access Protocol (LDAP).

The CML has been thoroughly tested including validating X.509
(Continue reading)

Permalink | Reply | 0 comments |
headers
Adrian McCullagh | 2 Aug 2002 05:04
Picon

Re: draft-ietf-pkix-warranty-ext-01


Hi Denis and others,

In your last email on this topic you wrote:

     "The Certificate Warranty qualifier contains a direct pointer to a
subpart
   of the Certification Practice Statement (CPS) published by the CA.  The
   pointer is in the form of a URI.  Processing requirements for this
   qualifier are a local matter."

I do not think this is a good idea from both a commercial perspective and a
legal perspective.

Firstly, I believe that it is doubtful that a relying party will read a
CPS.  Mainly because nearly all of the CPS's that I have encountered have
been very enstensive and frankly are a difficult to read.  Basically they
are not what I would call consumer friendly.

Secondly, notwithstanding the Uniform Commercial Code, the burying of
certificate warranty provisions in a CPS could result in a Court holding
that the warranty limit can not be relied upon.  It really defeats the
exercise of extending the financial trust factor.

I agree that a URL pointer to the warranty provisions would be advantageous
which could (note I said could not would, I am undecided on this point at
this time) force the relying party to the url and maybe an acceptance
button on the website.

This last point needs to be thought out as it is creating an extra layer of
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hoyt L. Kesterson II | 2 Aug 2002 08:09
Picon
Favicon

announcement of x500 meeting


The directory group will be meeting 16-20 September 2002 at the 
facilities of the National Institute of Standards and Technology. The 
meeting announcement is at 
ftp://ftp.bull.com/pub/OSIdirectory/NIST2002/6N12267announcement.pdf.

We will resolve ballot comments on the Friend Attribute PDAM and the 
Distributed Paged Results PDAM. The ballot period closes 10 August 
2002. We will advance the Working Documents on enhancements to 
certificates, on LDAP alignment, and on Related Entries.

The PDAMs and the Working Documents can be found at

    ftp://ftp.bull.com/pub/OSIdirectory/Geneva2002Output

We will also be resolving comments against Draft Technical Corrigenda 
that are correcting defects against X.509/9594-8. The ballot period 
on these DTCs ends 15 September 2002. They can be found at

 
ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DraftTechnicalCorrigenda/Closing15September2002

      hoyt
Permalink | Reply | 0 comments |
headers
Sunil Agrawal | 2 Aug 2002 21:17
Picon
Favicon

Certificate Path Validation


Dear PKIX WG:

I need some help on Certificate Path Validation.

If my trust anchor is a non self signed certificate, what should be the 
contents
of the initial permitted_subtrees.

permitted_subtrees is defined as "a set of root names for each name type 
(e.g.,
X.500 distinguished names, email addresses, or ip addresses) defining a set of
subtrees within which all subject names in subsequent certificates in the 
certification
path MUST fall".

The RFC 3280, section 6.1.2, subsection b, says

"the initial value for the set for Distinguished Names is the set of all 
Distinguished
names;"

So is the RFC recommending ignoring the Name constraints extension (if 
present) in
the CA certificates that are higher in the hierarchy that the trust anchor ?

Is the recommendation same for excluded_subtrees and other policies?

TIA,
Sunil
(Continue reading)

Permalink | Reply | 2 comments |

Gmane