headers
Michael Zolotarev | 1 May 2000 02:29

RE: TSA draft V7. certReq field.

Ok.

Except is probably sounds a little better to say: "IN THIS CASE that field
may also
contain other certificates."

Michael

> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas <at> bull.net]
> Sent: Friday, April 28, 2000 8:39 PM
> To: Michael Zolotarev; PKIX mailing group
> Subject: Re: TSA draft V7
> 
> 
> Michael,
> 
> On the gfirst point I answered to quickly.
> 
> The idea is to return the relevant certificate in the certificates
> field from the SignedData structure.
> 
> Here after is the complete fix:
> 
> If the certReq field is present and set to true, the TSA's public
> key certificate that is referenced by the ESSCertID attribute in the 
> response must be provided by the TSA in the certificates field from 
> the SignedData structure in that response. That field may also
> contain 
> other certificates.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Zolotarev | 1 May 2000 02:34

RE: TSA draft V7. OIDs.

> > C1. The draft uses both id-ad-timeStamping and 
> id-pkix-ad-timestamping OIDs.
> > I'd prefer "pkix" to be preserved as part of the name.
> 
> They come from two different arcs (SMIME and PKIX).
> 

Denis, I've put the OIDs together below. To me they are identical :)

id-pkix-ad-timestamping  OBJECT IDENTIFIER ::= {id-pkix-ad 3}
id-pkix-ad               OBJECT IDENTIFIER ::= {id-pkix 48}
id-pkix                  OBJECT IDENTIFIER ::= {iso(1) 
                         identified-organization(3) dod(6) 
                         internet(1) security(5) mechanisms(5) pkix(7)}

id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1) 
                      identified-organization(3) dod(6) 
                      internet(1) security(5) mechanisms(5) pkix(7) 
                      ad (48) timestamping (3)}

M
Permalink | Reply | 0 comments |
headers
Michael Zolotarev | 1 May 2000 02:55

RE: TSA draft V7.0

Carlisle,

Let me explain my point once again:

The 2459 defines the AIA extension as containing information about the
ISSUER of a certificate. Be it a TSA, or any other certificate. Therefore,
the AIA extension in a TSA certificate is expected to provide details about
the CA that issued that certificate, but not about the TSA itself.

Assuming that a CA generates a certificate for TSA so that the AIA somehow
contains the TSA's details - how would you know if the extension really
contains information about issuing CA, or the TSA? The freedom if
interpretation would be dangerously confusing.

This is why it would be only reasonable to have the AIA in self-signed TSA
certificates.

Regards
Michael

> -----Original Message-----
> From: Carlisle Adams [mailto:carlisle.adams <at> entrust.com]
> Sent: Saturday, April 29, 2000 12:14 AM
> To: Denis.Pinkas <at> bull.net; 'Michael Zolotarev'
> Cc: PKIX mailing group
> Subject: RE: TSA draft V7.0
> 
> 
> Hi Michael,
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Zolotarev | 1 May 2000 03:14

RE: TSA draft V7.0

I agree that it would be extremely difficult for a CA to evaluate a TSA's
practices before granting it a certificate with id-timestamping. It would be
even more difficult for me, as a client, to trust that assessment.

That is why is seems reasonable to expect that TSA would use self-signed
certificates, taking full responsibility over its practices and operations.

However, I reckon that this is largely outside of the scope of the
timestamping draft, really.

Regards
Michael

> -----Original Message-----
> From: tgindin <at> us.ibm.com [mailto:tgindin <at> us.ibm.com]
> Sent: Saturday, April 29, 2000 10:22 AM
> To: Carlisle Adams
> Cc: Denis.Pinkas <at> bull.net; 'Michael Zolotarev'; PKIX mailing group
> Subject: RE: TSA draft V7.0
> 
> 
> 
> 
> Carlisle Adams <carlisle.adams <at> entrust.com> on 04/28/2000 10:14:20 AM
> 
> To:   Denis.Pinkas <at> bull.net, "'Michael Zolotarev'"
>       <mzolotarev <at> baltimore.com>
> cc:   PKIX mailing group <ietf-pkix <at> imc.org>
> Subject:  RE: TSA draft V7.0
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
FRousseau | 1 May 2000 22:32

RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt

Denis,

In Section 2.4.1, could there be a way for a requester to indicate what hash
and signature algorithms he/she wants on the TimeStampToken in cases where a
TSA would support multiple algorithms since according to the current
definition of the "policy" field in Section 2.4.2, it does not seem to be
within the scope of this field to address this? How would otherwise a TSA
announce to the world what algorithms it uses to sign Time Stamp Tokens and
also what algorithms it supports in messageImprints.  Could the S/MIME
capabilities attribute be used for this?

In Section 2.4.2, in the time stamping response when the "status" field
contains the value one (1), doesn't this mean that a token is also present,
but its format was modified from what the requester demanded? If so, some
text will need to be modified to also indicate that when the PKIStatus
contains the value one and not just zero, a Time Stamp Token is also
present.  Otherwise, it should be clear what only values for the "status"
field are allowed in a response by a TSA.

In Section 2.4.2, it is mentioned that 'The statusString field of
PKIStatusInfo MAY be used to include reason
text such as "messageImprint field is not correctly formatted"', however the
"statusString" field itself, which is defined as PKIFreeText in RFC 2510, is
missing from the definition of the PKIStatusInfo field specified in this
document.  It would be preferable if the PKIStatusInfo field was defined
consistently in both documents.

Francois
___________________________________
Francois Rousseau
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Zolotarev | 2 May 2000 02:33

RE: I-D ACTION:draft-ietf-pkix-time-stamp-07.txt


> Denis,
> 
> In Section 2.4.1, could there be a way for a requester to indicate what
hash and signature algorithms he/she wants on the 
> TimeStampToken in cases where a TSA would support multiple algorithms
since according to the current definition of the 
> "policy" field in Section 2.4.2, it does not seem to be within the scope
of this field to address this? How would 
> otherwise a TSA announce to the world what algorithms it uses to sign Time
Stamp Tokens and also what algorithms it 
> supports in messageImprints.  Could the S/MIME capabilities attribute be
used for this?
> 
I'd say that the client should be able to verify all 'common' types of
signatures: [RSA/DSA]:[SHA1/MD5].
The encryption algorithm for the signature is defined by the key type in the
TSA's certificate, so the client can find it out before making the first
transaction with the TSA. I do not think that the hash is really going to be
a hard bit for the client.

The same about hash algorithms supported by the TSA for messageImprints -
the TSA should accept all 'common' types. If it does not understand the
algorithm's OID, the error will be returned to the client. So that the
client will have to try a different algorithm. With makes it nothing but
ugly, making me to believe any static information about TSA's capabilities
should be communicated separately from the actual TSA responses. The client
should discover the capabilities of the TSA before transacting, out-of-band
or from some published TSA practice statement.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ruheena Rashid | 2 May 2000 08:45

Query : CA related

Hello

I have a query regarding the Certification Authority (CA) in IKE. RFC 2409 
mentions about the inclusion of certificate payloads, which needs to be 
verified by the CA, but does not mention as to how the information is 
conveyed to the CA for verification.

Is it that the Peer obtains the certificate and performs the verification ?
(or)
Does it send the complete payload to CA for verification ?

I would like to know whether any draft or RFC exists, which mentions about 
how the CA performs the verification of the certificates?

Also, whether any encryption needs to be performed to send the information 
to the CA (since security is a major issue) ?

I would also like to know whether any implementation exists for the same.

Regards
Ruheena Rashid.

Ruheena Rashid
Software Engineer
Future Software Pvt. Ltd.
Nandanam
Chennai
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 May 2000 12:43
Picon
Favicon

I-D ACTION:draft-salzr-ldap-repsig-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: LDAP Controls for Reply Signatures
	Author(s)	: R. Salz
	Filename	: draft-salzr-ldap-repsig-00.txt
	Pages		: 8
	Date		: 01-May-00
	
In many environments the final step of certificate issuance is 
publishing the certificate to a repository. Unfortunately, there 
is no way for a Certification Authority (CA) to have a secure 
application-level acknowledgement that the proper repository 
did, in fact, receive the certificate. This issue is of greater 
concern when considering the publication of Certificate 
Revocation Lists (CRLs) -- if an adversary manages to interpose 
itself between the CA and its intended repository, then clients 
could end up relying on outdated revocation lists.
This document defines a set of controls so that an LDAP client, 
such as a CA, can receive a cryptographically secure 
acknowledgement that an LDAP server has received a request, and 
that the integrity of the server's reply has not been 
compromised.

    Whenever possible, the definitions here use mechanisms and 
    datatypes defined by the IETF PKIX working group. This document 
    references RFC 2459 [RFC2459]. Knowledge of the RFC is required 
    for proper implementation of this document, although it should 
    be possible to understand this document without much knowledge 
    of that RFC.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bruce Greenblatt | 3 May 2000 23:41

Re: I-D ACTION:draft-salzr-ldap-repsig-00.txt

Rich,

Why can't you use the mechanisms defined in RFC 2649 as a basis for this?
Your proposal seems remarkably similar to the definitions in RFC 2649.

Bruce

At 06:43 AM 5/2/2000 -0400, Internet-Drafts <at> ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
directories.
>
>
>	Title		: LDAP Controls for Reply Signatures
>	Author(s)	: R. Salz
>	Filename	: draft-salzr-ldap-repsig-00.txt
>	Pages		: 8
>	Date		: 01-May-00
>	
>In many environments the final step of certificate issuance is 
>publishing the certificate to a repository. Unfortunately, there 
>is no way for a Certification Authority (CA) to have a secure 
>application-level acknowledgement that the proper repository 
>did, in fact, receive the certificate. This issue is of greater 
>concern when considering the publication of Certificate 
>Revocation Lists (CRLs) -- if an adversary manages to interpose 
>itself between the CA and its intended repository, then clients 
>could end up relying on outdated revocation lists.
>This document defines a set of controls so that an LDAP client, 
>such as a CA, can receive a cryptographically secure 
>acknowledgement that an LDAP server has received a request, and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Santesson | 4 May 2000 12:04
Picon

Unmistakable identity

Denis,

Some comments regarding DN and Unmistakable identity.

DN is a technical requirement.
Unmistakable identity is a functional requirement.

The DN requirement is fullfilled if the CA assignes you a unique number,
e.g. "123456931", but destroys any useful information regarding who is the
person behind that number.

For this identity to also serve the purpose of being an unmistakable
identity, the CA MUST provide the nessecary framework to ensure that this
identity also can be used to identify the person "Denis Pinkas" (at least in
case of a dispute).

Actually the definition of unmistakable identity says it all, and is
relevant.

With respect to the EU directive, the PKIX document is an international
document, not only driven by the EU directive. Eventhough, the concept of
unmistakable identity applies also EU even if this term is not explicitly
defined in the directive.

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:Denis.Pinkas <at> bull.net]
> Sent: Wednesday, April 26, 2000 10:27 AM
> To: Stefan Santesson
(Continue reading)

Permalink | Reply | 1 comment |

Gmane