Simonetti David | 1 Feb 1998 19:53

Re: Key Usage

Rodney,

I had forwarded the following shortly after the Washington meeting.  The minimal
response I received was favorable, but I never received an absolute response from
the PKIX-1 authors...

Tim (et al),

As you stated at the meeting last week with respect to the key usage profile, I
agree that PKIX should not restrict the bit combinations.  However, I think the
previous discussions on this topic proved obvious that there are multiple
interpretations of these bits.

In an attempt to clarify the meaning of several of the bits, I suggest
the following editorial changes to PKIX-1:

Section 4.2.1.3, paragraph beginning with "The digitalSignature bit is
asserted...", add the following, "The digitalSignature bit should be set
when the key is for use in ephemeral applications, e.g., for a single
session authentication application."

Paragraph beginning with "The nonRepudiation bit is asserted...", add
the following, "The nonRepudiation bit should be set when when the key
is used to sign an object which may require the validation of the
signature at a future time."

I also suggest adding, "If the key may be used for both digitalSignature
and nonRepudiation applications, both bits may be set."

Finally, after the descriptions of encipherOnly and decipherOnly I
(Continue reading)

Olivier Onimus | 2 Feb 1998 12:04
Picon

Time Stamp and Hash Alg

Hi,

I have one question and one suggestion about time-stamp:

In PKIX Part V Time Stamp Protocols, the
data to be time-stamped must have the form:

MessageImprint ::= SEQUENCE {
     hashAlgorithm AlgorithmIdentifier,
     hashedMessage OCTET STRING}

And  AlgorithmIdentifier  is definesd as:
  AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

For most of the implementations realised with standard
ASN.1-Tools-and-compilers,
this means that SW must "know" in advance all the
accepted Alg.-OIDs to link the expected parameter to them.

Now my question:

   Is there a profile of the supported hash-algorithms with the
   corresponding parameter-syntaxes ?

Now a remark:
   A time-Stamp-Server does NOT need the crypto-algorithm like an application
   which must decrypt data or check a signature !
   It just has to notice "OK, the client did hash the data with this alg.,
(Continue reading)

David P. Kemp | 2 Feb 1998 19:23

Attribute Cert examples?

Does anyone have or know of a publicly-available example of an X.509
Attribute Certificate?  I'm looking for test data to independently
validate some parsing software, and for an instance to include in the
PKIX Part 1 examples appendix.

Thanks,
  Dave Kemp

Bob Jueneman | 2 Feb 1998 22:28
Picon
Favicon

Re: Attribute Cert examples?

Has such an animal even been completely defined yet?  I though X9 was still working on the spec.

I'll be interested to se what kind of a reply you receive.

bob

Robert R. Jueneman
Security Architect
Novell, Inc.
Network Services Division
122 East 1700 South
Provo, UT 84604
801/861-7387
bjueneman <at> novell.com

"If you are trying to get to the moon, climbing a tree,
although a step in the right direction, will not prove
to be very helpful."

"The most dangerous strategy is to cross a chasm in two jumps."

>>> "David P. Kemp" <dpkemp <at> MISSI.NCSC.MIL> 02/02 11:23 AM >>>
Does anyone have or know of a publicly-available example of an X.509
Attribute Certificate?  I'm looking for test data to independently
validate some parsing software, and for an instance to include in the
PKIX Part 1 examples appendix.

Thanks,
  Dave Kemp

(Continue reading)

Nilsson Hans | 3 Feb 1998 11:49
Picon

Tag type for rfc822name

I am editing the revision a certificate specification for the national
Swedish Electronic Identity Card (see www.seis.se), to harmonize it with
the certificate specifications of PKIX-1 and S/MIME. I am also going to
include examples of DER-coded certificates. In that context I have come
across different ways of encoding the subjectAltName rfc822Name
extension. The question is: Should it use IMPLICIT or EXPLICIT tags?
Below are two extracts from PKIX-1, which uses IMLICIT in one example
and EXPLICIT in another.

Which way has it been implemented in existing S/MIME products? Can they
handle both IMPLICIT and EXPLICIT coding of rfc822Name?

Here are the examples from PKIX-1:
------------------------ IMPLICIT TAG:
------------------------------------------
0606 a3 1d         29: . . [3]
0608 30 1b         27: . . . SEQUENCE
0610 30 19         25: . . . . SEQUENCE
0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
0617 04 12         18: . . . . . OCTET STRING
                     : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
                     : 6f 76

0000 30 10         16: SEQUENCE
0002 81 0e         14: . [1]
                     : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
note is taken from PKIX-1!)
-----------------------EXPLICIT TAG:
----------------------------------------------------
(Continue reading)

Sharon Boeyen | 3 Feb 1998 13:58
Favicon

FW: Attributes clarification in 509

------------------
Sharon Boeyen
Entrust Technologies

mailto:boeyen <at> entrust.com       Tel: (613) 247-3181
http://www.entrust.com          Fax: (613) 247-3690
         Orchestrating Enterprise Security

>----------
>From:  Sharon Boeyen
>Sent:  February 2, 1998 11:25 AM
>To:    'ietf-pkix <at> lists.tandem.com'
>Subject:       Attributes clarification in 509
>
>As promised,
>
>Here is the text that was agreed at last week's X.509 meeting to clarify the
>use of the cACertificate and crossCertificatePair attributes. This text
>change to X.509 forms the draft technical corrigendum for defect report 185
>and will be sent for ballot by ISO.
>
>"Clause 8
>(Add the following text immediately following the asn.1 for certificatePair)
>
>The cACertificate attribute, held in a particular CA's directory entry, may
>be used to store self-signed certificates.
>
>Note - The cACertificate attribute should not be confused with the defined
>term CA-certificate.
>
(Continue reading)

David P. Kemp | 3 Feb 1998 16:02

Re: Tag type for rfc822name

> From: Nilsson Hans <HNN <at> ausys.se>

> The question is: Should it use IMPLICIT or EXPLICIT tags?
> Below are two extracts from PKIX-1, which uses IMLICIT in one example
> and EXPLICIT in another.
>
> Which way has it been implemented in existing S/MIME products? Can they
> handle both IMPLICIT and EXPLICIT coding of rfc822Name?

There can be only one correct encoding, otherwise DER would not be unique.

> Here are the examples from PKIX-1:
> ------------------------ IMPLICIT TAG:
> ------------------------------------------
> 0606 a3 1d         29: . . [3]
> 0608 30 1b         27: . . . SEQUENCE
> 0610 30 19         25: . . . . SEQUENCE
> 0612 06 03          3: . . . . . OID 2.5.29.17: subjectAltName
> 0617 04 12         18: . . . . . OCTET STRING
>                      : 30 10 81 0e 77 70 6f 6c 6b 40 6e 69 73 74 2e 67
>                      : 6f 76
>
> 0000 30 10         16: SEQUENCE
> 0002 81 0e         14: . [1]
>                      : 77 70 6f 6c 6b 40 6e 69 73 74 2e 67 6f 76
> Note: This subjectAltName data is IMPLICIT TAGS - is that correct? (this
> note is taken from PKIX-1!)

When I wrote that note in PKIX-1, I intended to call attention to the
fact that there appeared to be an error in the software that generated
(Continue reading)

John Pawling | 3 Feb 1998 16:35

Re: FW: Attributes clarification in 509

Sharon and friends,

The use of "forward" and "reverse" in Sharon's message seems contradictory
to the definitions stated in the X.509 spec, Section 8, Intro, which defines
forward and reverse as follows:

"If user A, trying to obtain the public key of user B, has already obtained
the public key of CA(B), then the process is complete. In order to enable A
to obtain the public key of CA(B), the directory entry of each Certification
Authority, X, contains a number of certificates. These certificates are of
two types. First there are forward certificates of X generated by other
Certification Authorities. Second there are reverse certificates generated
by X itself which are the certified public keys of other certification
authorities. The existence of these certificates enables users to construct
certification paths from one point to another."

Recommend that the X.509 editors should ensure that their use of forward and
reverse is consistent thorughout the document.

================================
John Pawling
jsp <at> jgvandyke.com
J.G. Van Dyke & Associates, Inc.
================================

At 07:58 AM 2/3/98 -0500, Sharon Boeyen wrote:
>------------------
>Sharon Boeyen
>Entrust Technologies
>
(Continue reading)

Sharon Boeyen | 3 Feb 1998 19:27
Favicon

Re: FW: Attributes clarification in 509

John,

You're absolutely correct and thanks for catching that. During last
week's meeting Warwick mentioned the directions as well and I said I'd
double check whether I had them correct or not. I'll revise the text
before ballot as follows:

"Clause 8
(Add the following text immediately following the asn.1 for
certificatePair)

The cACertificate attribute, held in a particular CA's directory entry,
may be used to store self-signed certificates.

Note - The cACertificate attribute should not be confused with the
defined term CA-certificate.

The crossCertificatePair attribute, held in a particular CA's directory
entry,  may be used to store certificates issued by this CA to other
CAs, as well as certificates issued for this CA by other CAs. Values
held in the forward element are certificates issued for this CA by other
CAs, while values in the reverse element are certificates issued by this
CA for other CAs. Either certificate, if present,  may be used in
building certificate paths for validation and may be published in the
directory entries of either CA or both. "

------------------
Sharon Boeyen
Entrust Technologies

(Continue reading)

Miklos, Sue A. | 3 Feb 1998 20:00

Re: Attribute Cert examples?

Dave... did you find anything?  The ANSI X9F (certco?) may be an
answer...

Sandi

>----------
>From:  David P. Kemp[SMTP:dpkemp <at> missi.ncsc.mil]
>Sent:  Monday, February 02, 1998 1:23 PM
>To:    IETF-PKIX <at> LISTS.TANDEM.COM
>Subject:       [IETF-PKIX] Attribute Cert examples?
>
>Does anyone have or know of a publicly-available example of an X.509
>Attribute Certificate?  I'm looking for test data to independently
>validate some parsing software, and for an instance to include in the
>PKIX Part 1 examples appendix.
>
>Thanks,
>  Dave Kemp
>


Gmane