headers
Al Arsenault | 1 Dec 1998 08:00

RE: Minor confusion in PKIX part 1, section 7.3.3

If I recall correctly, this paragraph is actually trying to address the
fact that the parameters field is optional, and even if it's there, it
might be NULL.  The relevant wording is:

> If the DSA algorithm parameters are absent 
> from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed 
> the subject certificate using a signature algorithm other than DSA, 
> then  the subject's DSA parameters are distributed by other means. If 
> the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
> parameters component and the CA signed the subject with a signature 
> algorithm other than DSA, then clients shall reject the certificate. 
> 

This is poorly worded, I admit, but it tries to address two different cases:

	case 1:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
end-entity need not reject the certificate, but it has to get the parameter
values from some place other than the certificate.

	case 2:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no field.
 In this case, the end-entity has to reject the certificate.

(There was actually a long discussion in the S/MIME WG in Chicago about
whether this field should be there and be set to NULL, or left out
altogether. You can see the S/MIME meeting minutes/mailing list for all the
gory details.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Al Arsenault | 1 Dec 1998 09:06

RE: Minor confusion in PKIX part 1, section 7.3.3

Santosh,

	You are correct - in my haste, I missed the statement two paragraphs above
the one being discussed, which is:

		The id-dsa algorithm syntax includes optional parameters. These
parameters are commonly referred to as p, q, and g. 
		When omitted, the parameters component shall be omitted entirely. That
is, the AlgorithmIdentifier shall be a SEQUENCE 
		of one component - the OBJECT IDENTIFIER id-dsa.

	Thus, the NULL value is not permitted in this field of PKIX-compliant
certificates.  Given that, I agree that the sentence about "distributed by
other means" should be dropped.

			Al Arsenault

At 02:35 PM 11/30/98 -0500, Santosh Chokhani wrote:
>Al:
>
>I think whether the parameter value of NULL is valid is driven by the
>Algorithm OID registration.  For example, RSA algorithm OIDs registered
>would have NULL parameter value.
>
>Now, for DSA, there are algorithm OID such dsa-with-sha1 has NULL
>parameters.  But, it is recommended only for the algorithm OID in the
>issuer signature and SIGNED MACRO fields.
>
>I think the point regarding the NULL is not germane to this discussion.
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Stefan Kelm | 1 Dec 1998 15:59
Picon

Re: generation of private keys

Dan,

> whether this set of keys was gen'd by XYZ?  Of course,
> whether gen'd on the up-and-up or not, incompetently
> escrowed trumps competently gen'd any day.

sorry, but I don't get this last sentence...

> Bottom line:
> one bit answer to _CA_takes_responsibility_for_key_gen?_

So we're back to a boolean extension again?

Warwick and Carlisle: could you please elaborate on why you'd prefer an
enumeration rather than a boolean?

Cheers,

        Stefan.

______________________________________________________________________________
Stefan Kelm            PGP key: "finger kelm <at> www.pca.dfn.de" or via key server
DFN-PCA, University of Hamburg                               <kelm <at> pca.dfn.de>
Vogt-Koelln-Str. 30                               http://www.pca.dfn.de/~kelm/
22527 Hamburg (Germany)          Tel: +49 40 5494 2262 / Fax: +49 40 5494 2241
Permalink | Reply | 0 comments |
headers
Stefan Santesson | 1 Dec 1998 18:03
Picon

Qualified Certificates and the 43:d IETF Meeting

All,

All,

The editorial team for the Quilified Certificates draft has worked since
Chicago to prepare a first draft until the Orlando meeting. Some new
changes are that the subject field now only contains well known attributes
while more specific identity information is specified in a new
datastructure stored in the subjectAltName extension. This proposal is not
yet stable but comments are welcome if this approach is good or bad.

This draft, and whether it should be adopted as a PKIX work item will be
discussed in Orlando. On the meeting we will present the satus and the
rationales behind this draft.

An official first draft will be issued after the Orlando meeting. The draft
attached below is a preliminary version.

/Stefan

PKIX Working Group                                   S. Santesson (SEIS)
Internet Draft                                            W. Polk (NIST)
                                                        A. Berger  (GMD)

expires in six months                                  November xx, 1998

                Internet X.509 Public Key Infrastructure

                         Qualified Certificates
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carlisle Adams | 1 Dec 1998 20:35
Favicon

RE: generation of private keys

Hi Stefan,

> -----Original Message-----
> From: Stefan Kelm [mailto:kelm <at> pca.dfn.de]
> Sent: Tuesday, December 01, 1998 10:00 AM
> To: geer <at> world.std.com
> Cc: ietf-pkix <at> imc.org
> Subject: Re: generation of private keys
> 
> Dan,
> 
> > whether this set of keys was gen'd by XYZ?  Of course,
> > whether gen'd on the up-and-up or not, incompetently
> > escrowed trumps competently gen'd any day.
> 
> sorry, but I don't get this last sentence...

All he's saying is that it may not matter who generated the key pair
(regardless of how wonderfully competent they were).  If the escrowing is
done in an incompetent way, then it's all pointless.

> > Bottom line:
> > one bit answer to _CA_takes_responsibility_for_key_gen?_
> 
> So we're back to a boolean extension again?
> 
> Warwick and Carlisle: could you please elaborate on why you'd prefer an
> enumeration rather than a boolean?

I did not say that I would prefer an enumeration; I said that an enumeration
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 1 Dec 1998 15:28

RE: Time stamp request

At 11:23 AM 11/25/98 -0500, Sarbari Gupta wrote:
>[snip]
>
>On the other hand, currently (in draft-ietf-pkix-time-stamp-00.txt), the
>MessageImprint data structure seems to imply that only a cryptographic
>hash of the message is permitted. However, it would be relatively easy
>to accommodate other types of message imprints, including the actual
>message (there is no better imprint of a message than the message
>itself!!) and arithmetic checksums, etc. 

I do not think that arithmetic checksums are useful.  It is trivial to
generate two documents that have the same arithmetic checksum.  So, a
timestamp on such a checksum is essentially meaningless.

I suggest that a one-way hash value of the document or the document itself
be used.

Russ
Permalink | Reply | 0 comments |
headers
Sarbari Gupta | 2 Dec 1998 15:37
Favicon

RE: Time stamp request

Russ:

Arithmetic checksums are weak - there is no argument about that. I was
just pointing out that the MessageImprint type could be broadened easily
to accommodate the various needs of clients of a timestamping service.

In fact, if the actual message itself was being sent to the Time Stamp
Authority (TSA), I can envision two modes of usage:
	1) the TSA calculates a hash on the message and uses the hash
value to generate the time stamp token
	2) the TSA uses the message in its entirety to generate the time
stamp token.

The first mode is obvious. The second mode allows time stamp tokens to
serve as standalone data vehicles that can be used to verify the content
as well as carry the content - this would typically be useful for small
messages. 

- Sarbari 

-----Original Message-----
From: Russ Housley [mailto:housley <at> spyrus.com]
Sent: Tuesday, December 01, 1998 9:28 AM
To: Sarbari Gupta
Cc: ietf-pkix <at> imc.org
Subject: RE: Time stamp request

At 11:23 AM 11/25/98 -0500, Sarbari Gupta wrote:
>[snip]
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Linn, John | 2 Dec 1998 18:22

Why is dcs-00's scalability deprecated?

In reviewing the dcs-00 draft, I believe that this represents a valuable and
versatile service. There's a paragraph in its introduction which I'm
wondering about:

"It is not recommended that the DCS be used as a substitute for normal
public key certificate revocation checking (e.g., CRLs, OCSP) in large
environments, due to concerns about the scalability of this protocol.  It
should only be used to support non-repudiation or to supplement more
traditional revocation services when more timely information is required." 

Why is the scalability of DCS, if applied for certificate validation
purposes using unsigned cpkc requests, sufficiently different from OCSP's as
to motivate this deprecation?  Is the driving issue that DCSReqInfo's
mandated nonces (vs. requester ID and reqTime, which are optional) prevent
response preproduction, the potential that chain validations could prove
costly to aggregate at a common responder, and/or what other concerns are
being considered here?

Any clarifications and thoughts appreciated.

--jl
Permalink | Reply | 0 comments |
headers
Juergen Walter | 2 Dec 1998 19:00
Picon

RE: generation of private keys

Hi all,

I would like to add few comments to the key generation extension. It was
suggested to give the relying party a hint at the assurance level of the
certificate adding a key generation extension to the profile in [PKIX
CERT].

The suggested key generation extension represents only one aspect of
certification policy. It SHOULD be stated in the CPS of the issuing CA.
There are two extensions refer to the underlying policy in the
certificate, the CPS pointer and User Notice qualifiers.

The relevant text taken from[PKIX CERT] and [PKIX CPS] follows at the
end of the message.

The disadvantage of these extensions I see is that they are not
customizable for automatic processing. Even the reading and
understanding of CPS may be difficult. Supposed if there any need for a
key generation extension for some communities nowadays; next year there
may be some need for another extension refering to other elements of CPS
in a formal and automatically customizable representation.

Is this the way we want to go?

Surely, I can live with a key generation extension as a boolean or
whatever. But I can not recommend use of this extension in such a way
that the relying party only sticks on this to decide whether accept a
certificate or not under certain circumstances. A look on the whole CPS
is strongly recommended.
(Continue reading)

Permalink | Reply | 0 comments |
headers
secstan | 2 Dec 1998 20:58

RE: Qualified Certificates and the 43:d IETF Meeting

Stefan,

I still have major concerns over this draft in that the naming attributes
used in the subject and issuer are not those used in conventional directory
"distinguished names".  Whilst I recognise that LDAP / X.500 directories are
only one possible means of distributing certificates, the use of qualified
certificates should not make it difficult to use directories for
distributing certificates.

The changes made has moved in the right direction but more could be done to
facilitate a common approach.

More specifically:

1) In 3.1.2, instead of Choice II using surname and firstname, conventions
could be defined for carrying this information in Common Name
(e.g. CommonName =<firstname> <surname>)

2)The standard attribute dnQualifier could be used instead of serialNumber
(Th attribute "serialNumber is defined in RFC 2256 as being the serial
number of a device).

3) postalAddress is more appropriate as an additional subjectAttribute (see
next comment) rather than a naming attribute.

4) In 3.2.1 it is suggested that the structure PersonalData is added to
SubjectAltName.
This doesn't fit in with the standard syntax which defines this as being
GeneralName
(see PKIX part 1).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane