headers
Hoyt L. Kesterson II | 1 Oct 2001 04:42
Picon
Favicon

announcement of the rescheduled directory meeting in Flagstaff


hello all

The announcement of the rescheduled Flagstaff meeting is at

     ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/announcementRev3.pdf

The major differences in the announcement are;

The date is 12 - 16 November 2001

The agenda is changed - e.g., work on X.509/part 8 is now on 12 and 13 November

Reservations must be made by 20 October. The room rate is lowered to 
$90 but it will be colder.

Additional input documents are identified.

Travel directions from Las Vegas to the hotel are included. Several 
people found that it was less expensive to book a flight to Las Vegas 
than to Phoenix.

As before, the input documents for this meeting can be found at

   ftp://ftp.bull.com/pub/OSIdirectory/Flagstaff2001/InputDocuments/  and

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

    hoyt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Takeshi AKUTSU | 2 Oct 2001 16:23
Picon

question about the DN Qualifier


Dear all,

I have a question about DN Qualifier.

RFC2459 states 
   Implementations of this specification MUST be prepared to 
   receive the following standard attribute types in issuer
   names: country, organization, organizational-unit, 
   distinguished name qualifier, state or province name,  
   and common name (e.g., "SusanHousley").

but I don't understand how the DN Qualifier is used.

I put the following description of X.520(draft). 
I confuse the DSA part.
How can I use the DN Qualifier? 
Is there any good example how to use it?

-----------------
5.2.8	DN Qualifier 

The DN Qualifier attribute type specifies disambiguating information
to add to the relative distinguished name of an entry. It is intended
to be used for entries held in multiple DSAs which would otherwise
have the same name, and that its value be the same in a given DSA for
all entries to which this information has been added.
-----------------

Sincerely,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernd Matthes | 2 Oct 2001 19:21
Favicon

Re: New test TSA available

Peter Gutmann wrote:
> 
> There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS 140-1
> level 4 device (it's just a demo which runs single-threaded, so if you throw
> a huge number of concurrent requests at it you may get some refused
> connections, although I doubt it'll be a big issue for now).  There will also
> be an OCSP responder at ocsp.cryptoapps.com and a CMP server at
> cmp.cryptoapps.com in the near future running on the same hardware, at the
> moment I think the ports are still blocked so you won't be able to get to them.
> 
> Peter.

Hi Peter!

I tried Your TSA.
I could connect and got a response.
In parsing the response I got an ASN.1 error.
Here is Yours: 
   0 30 1706: SEQUENCE {
   4 30    3: . SEQUENCE {
   6 02    1: . . INTEGER 0
            : . . }
   9 30 1697: . SEQUENCE {
  13 06    9: . . OBJECT IDENTIFIER pkcs7signedData (1 2 840 113549 1 7
2)
  24 A0 1682: . . [CONTEXT-SPECIFIC 0] {
  28 30 1678: . . . SEQUENCE {
  32 02    1: . . . . INTEGER 1
  35 31   11: . . . . SET {
  37 30    9: . . . . . SEQUENCE {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 3 Oct 2001 09:05
Picon
Picon
Picon
Favicon

Re: New test TSA available


>In parsing the response I got an ASN.1 error.

It's already fixed (I was using the PKCS #7 rather than CMS interpretation),
but because it's a pain to update the system it's running on it's still using
old code.  I'll have to reload the system at some point...

Peter.
Permalink | Reply | 1 comment |
headers
Rachel | 6 Oct 2001 04:29
Picon

Key Recovery in PKIX CMP


Hi all,

I have some questions here regarding the PKI messages used for key recovery purposes.
They are Key Recovery Request and Key Recovery Response messages.
According to RFC2510 and RFC2511, the key recovery request is of type CertReqMessages and
KeyRecRepContent respectively.  My questions are:

1) Why the key recovery request is made identical as cert request format ? I can't see both of them
have the same nature.Cert request is used when someone want to register for his new key pair.  In
order to complete that, one has to send in the CertTemplate with all those necessary fields filled
in, also, he has to provide Proof-of-Possession about his key pair.  Now, if we look at the typical
procedure for a key recovery system (or key escrow system), anyone (the owner of the key, a third
party) can issue a request for the recovery of the key.  In this context, does the key recovery
requester need to send in the cert template again ?  Also, how can an authorised third party
presents his POP of the key to be recovered (although he is not the owner, but he has the right to
do so) ??

2) The 2nd question is about the key recovery response PKI message.  Does anyone know why
newSigCert, caCerts and keyPairHist is returned to the recovery requester ?  And can you explain the
scenario is which the new signature certificate should be returned and why ?  The RFC I have do not
cover that, I mean the explanation on the existance of a particular field.

Hope to hear from you soon.  Thanks in advance.

regards,
Rachel
UTM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 9 Oct 2001 16:40
Picon
Picon
Picon
Favicon

Re: New test TSA available


Bernd Matthes <bernd.matthes <at> gemplus.com> writes:

>But the next question: You send the root of the TSA cert in certificates
>field. My verify function complains that a self sign cert is in cert chain.
>Should I tolerate this or is the complaint ok? I'm not sure.

Given the open-ended interpretation of what you can put in there, I'm sure it
could be argued that stuffing PGP certs in there is valid.  For my part, I just
put the whole chain in and let the relying party pepper and salt it as they
please.

Peter.
Permalink | Reply | 0 comments |
headers
Bernd Matthes | 9 Oct 2001 15:56
Favicon

Re: New test TSA available

Peter Gutmann wrote:
> 
> >In parsing the response I got an ASN.1 error.
> 
> It's already fixed (I was using the PKCS #7 rather than CMS interpretation),
> but because it's a pain to update the system it's running on it's still using
> old code.  I'll have to reload the system at some point...
> 
> Peter.

Hi Peter!

Today I've test again Your TSA server. It looks good.

But the next question: You send the root of the TSA cert
in certificates field. My verify function complains 
that a self sign cert is in cert chain. 
Should I tolerate this or is the complaint ok?
I'm not sure.

with kind regards
--

-- 
Bernd Matthes               Celo Communications GmbH
Senior Software Engineer          - a Gemplus Company
Dipl.-Ing.(FH)              mailto:bernd.matthes <at> gemplus.com
------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption,
lack of adoption results in death. Death not good."
Attachment (smime.p7s): application/x-pkcs7-signature, 2030 bytes
Permalink | Reply | 0 comments |
headers
Magnus Nystrom | 11 Oct 2001 22:46

Re: Polling in CMP


Amit,

Thanks for your comments.

On Mon, 17 Sep 2001, Amit Kapoor wrote:

> Hi Magnus, Gareth,
>
>      A quick glance seems the proposal is inline with the original
> discussion. However, I would like to expand the scope of polling a
> little bit.  One of the other problems we have been dealing with is
> that issuance of certificates sometimes require a back and forth
> question & answer session between the end entity and the server
> for identity authentication.  The current interoperable subset of
> the CMP protocol assumes

> (a) all the information needed by the server is in the original
> request or
> (b) the server does out of band verification if information needed
> is not sufficient.
>
>      I believe this requirement is generic enough to require
> interoperable support and should go into the CMP protocol.  Based on
> the use of the proposed CMP poll request & response, it looks like a
> good choice. Would like to hear your thoughts......

This is probably rather a question for the ir/ip pair, or cr/cp,
perhaps in conjunction with enhancements to PKIStatus. In any event, I
rather not mix the polling functionality with interactions between the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fantou Patrick | 16 Oct 2001 17:04
Picon

AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Two small things:

1. pseudonym should be supported in issuer and subject names,
 but the oid for pseudonym is missing in this document (id-at-pseudonym : id-at 65 from X.520 2000)

2. Clause 4.2.2.1 Authority Information Access says that RFC 2560 defines the access descriptor for OCSP,
but in fact id-ad-ocsp (id-ad 1) is defined in this draft and RFC 2560 imports it 
and uses it as base for the OCSP OID arc.

Regards
Patrick

> -----Ursprüngliche Nachricht-----
> Von: Internet-Drafts <at> ietf.org [mailto:Internet-Drafts <at> ietf.org]
> Gesendet: Dienstag, 16. Oktober 2001 13:08
> Cc: ietf-pkix <at> imc.org
> Betreff: I-D ACTION:draft-ietf-pkix-new-part1-09.txt
> 
> 
> 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 Certificate 
>                           and CRL Profile
> 	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
> 	Filename	: draft-ietf-pkix-new-part1-09.txt
(Continue reading)

Permalink | Reply | 1 comment |
headers
Housley, Russ | 16 Oct 2001 21:30

Re: AW: I-D ACTION:draft-ietf-pkix-new-part1-09.txt


Patrick:

>1. pseudonym should be supported in issuer and subject names,
>  but the oid for pseudonym is missing in this document (id-at-pseudonym : 
> id-at 65 from X.520 2000)

Section 4.1.2.4 lists pseudonym as one of the attributes that SHOULD be 
supported.  However, pseudonym is missing from the ASN.1 module.  We need 
to add:

    -- Naming attributes of type X520Pseudonym

    id-at-localityName      AttributeType ::= { id-at 65 }

    X520Pseudonym ::= CHOICE {
       teletexString     TeletexString   (SIZE (1..ub-pseudonym)),
       printableString   PrintableString (SIZE (1..ub-pseudonym)),
       universalString   UniversalString (SIZE (1..ub-pseudonym)),
       utf8String        UTF8String      (SIZE (1..ub-pseudonym)),
       bmpString         BMPString       (SIZE (1..ub-pseudonym)) }

    ub-pseudonym INTEGER ::= 128

>2. Clause 4.2.2.1 Authority Information Access says that RFC 2560 defines 
>the access descriptor for OCSP, but in fact id-ad-ocsp (id-ad 1) is 
>defined in this draft and RFC 2560 imports it and uses it as base for the 
>OCSP OID arc.

You are quite right.  I will propose replacement text after coordinating
(Continue reading)

Permalink | Reply | 0 comments |

Gmane