headers
David Chadwick | 1 Apr 2002 15:29
Picon

LDAP Certificate transfer syntax

Colleagues

Here is my proposed change to the section describing the LDAP syntax for
cerificates in the PKIX id
<draft-pkix-ldap-schema-03.txt> which should be published before the end
of April. As this is likely to be the most contentious part of the new
ID, I thought it would be useful to distribute this text at the earlier
possible moment.

All constructive comments welcomed

David

3.3  Certificate Syntax

A value in this transfer syntax is the binary octet string that results
from BER or DER-encoding of an X.509 public key certificate.  The
following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )

Servers must preserve values in this syntax exactly as given when
storing and retrieving them. 

Note. Due to the changes from X.509(1988) to X.509(1993) and subsequent
changes to the ASN.1 definition to support certificate extensions in
X.509(1997), no character string transfer syntax is defined for
certificates. The BNF notation in RFC 1778 [12] for "User Certificate"
MUST NOT be used. Values in this syntax MUST be transferred as BER or
DER encoded octets. The use of the ;binary encoding option, i.e. by
(Continue reading)

Permalink | Reply | 20 comments |
headers
Housley, Russ | 1 Apr 2002 18:10

Re: LDAP Certificate transfer syntax


David:

Is it possible to preserve the DER encoding.  If not, then the DER encoding 
must be restored in order to validate the signature?  This just seems like 
wasted processing to me.

Russ

At 02:29 PM 4/1/2002 +0100, David Chadwick wrote:
>Colleagues
>
>Here is my proposed change to the section describing the LDAP syntax for
>cerificates in the PKIX id
><draft-pkix-ldap-schema-03.txt> which should be published before the end
>of April. As this is likely to be the most contentious part of the new
>ID, I thought it would be useful to distribute this text at the earlier
>possible moment.
>
>All constructive comments welcomed
>
>David
>
>
>3.3  Certificate Syntax
>
>A value in this transfer syntax is the binary octet string that results
>from BER or DER-encoding of an X.509 public key certificate.  The
>following string states the OID assigned to this syntax:
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
David Chadwick | 1 Apr 2002 23:32
Picon

Re: LDAP Certificate transfer syntax


"Housley, Russ" wrote:
> 
> David:
> 
> Is it possible to preserve the DER encoding.  If not, then the DER encoding
> must be restored in order to validate the signature?  This just seems like
> wasted processing to me.
> 

Russ

I quite agree. The revised text is meant to ensure that the DER or BER
encoding created by the client when the certificate was first sent to
the directory for storage is preserved as is. This is the purpose of the
sentence below in the revised text, viz:

> >Servers must preserve values in this syntax exactly as given when
> >storing and retrieving them.
> >

Perhaps I should say "as given to them by the client, when storing and
retrieving certificates"

David
Attachment (d.w.chadwick.vcf): text/x-vcard, 860 bytes
Permalink | Reply | 0 comments |
headers
Ambarish Malpani | 1 Apr 2002 23:59

Comments on draft-ietf-pkix-dpv-dpd-req-03.txt


Hi Denis, Russ,
     Great work on the new draft!

A few comments:

1. In 2 places you equate the "root" with a self-signed cert. I
hope you intend to allow the trust anchor to be a non-self-signed
cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.

2. Section 4 Para 9
    You require the DPV server to "obtain" the certificate from the
reference provided by the client. This is *not* a requirement. If
the server obtains the certificate by some other means, that is okay,
as long as it verifies that the certificate is indeed the one
being referred to by the client.

3. Section 4 Para  12
    In order to prevent replay attacks, you require the nonce to be
present in the response. As mentioned by Petra, if the response
contained the request hash, it doesn't need to contain the nonce. It
is still bound to the request. Present of the request nonce in the
reply shouldn't be a requirement in this case.

4. Section 4 Para 16
    You require a DPV response to be signed - error response
might not be signed (e.g. badly formatted request, etc.) Please
allow for that case.

That's it!
(Continue reading)

Permalink | Reply | 10 comments |
headers
Denis Pinkas | 2 Apr 2002 11:23
Picon

Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt


Mike,

> Tim,
> 
> Two working days seems a bit tight given the breadth of
> comments.  Given that constraint, silence may not necessarily
> concurrence.  It could very well be the effects of our day jobs.
> But that said, I'll see what I can do regarding those comments I
> made.

Since you did not attended the Minneapolis meeting, in order to help you,
here is the disposition of comments that has been presented, with comments
19, 23 and 25 updated.

Denis

Disposition of comments

COMMENT 1: Hash of the request in signed response or important elements of
the request: responses need to include binding to the certificate from the
request.

COMMENT 2: random number repeated in the response.

COMMENT 3: no algorithm requirements.

COMMENT 4: PDP (Policy Definition Requ.) will be in a different document.

COMMENT 5: No authentication of the server prior to the sending of the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian Hunter | 2 Apr 2002 15:24
Picon

Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt


Hello Denis and Russ,

>      Great work on the new draft!
I concur.

I have one question and a couple of small typographical comments to add.

5. Section 5 Para 4
    This comment goes along with Ambarish's comment 1.  I do not
understand what is meant by "if issued" in the following sentence:
  "The trust anchor self-signed certificate, if issued, is not
included."

Without understanding the "issued" point and assuming that all trust
anchor certificates, self-signed or not, are issued, then I would have
the sentence read:
  "The trust anchor is not included."
Note that I am agreeing with Ambarish that the self-signed requirement
for a root should be dropped.

6. Section 4 Para 11 c)
    "If another request could made later..."
    Suggest to change to: "...could be made..."

7. Section 7 Para 3
    "constrains" -> "constraints"

8. Section 7.1 Para 1
    "build" -> "built"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Sylvester | 2 Apr 2002 15:25
Picon
Picon
Favicon

Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt


> 
> COMMENT 5: No authentication of the server prior to the sending of the
> request (not done with similar protocols). 
> 
Denis, I think that I may have badly stated the requirement. I 
assume an online connection *and* confidentiality via TLS
done at the transport layer. In this case, confidentiality
would be somewhat meaningless if you don't authenticate the 
server.  Your remark is correct if you think about encryption 
with email, but then you assume that only the server can decrypt,
thus you still have server authentication. 

What similar protocol do you have in mind? (OCSP)?

> COMMENT 6: Confidentiality done at transport level.

Ok, but it is not mentioned in the text. If
properly stated, it resolves COMMENT 5. 

>  
> COMMENT 8: Relaying not supported by the protocol.
>
This is a pity: This was omitted in OCSP, and the risk
of endless loops of two OCSP servers talking to each other
are definitely there. 
Relaying a request to another service is a requirement,
at least in the same way as it is for OCSP. 

But there are two issues:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Stillson | 2 Apr 2002 22:52

Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt)


  On Mon, 1 Apr 2002, David Chadwick wrote:
> All constructive comments welcomed

  Hi David-
  A thought for the you...

  Although implied by section 3, perhaps it should be stated expectedly:

  "A PKI object should be placed into a LDAP directory such that the LDAP
   object DN matches the subject DN of the object."

  Although this seems obvious to some, I've run into a surprising number of
  clients setting up directories using some alternate structure, who are
  then surprised when validation software can't find certificates given
  subject DN's.

    - Ken Stillson

--

-- 
      |   Ken Stillson             |    stillson <at> mitretek.org    |
      |   Sr. Principal Engineer   |    voice: (703) 610-2965    |
      |   Mitretek Systems         |      fax: (703) 610-2984    |
Permalink | Reply | 4 comments |
headers
Peter Sylvester | 2 Apr 2002 20:00
Picon
Picon
Favicon

Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt


> 
> COMMENT 7: Requests shall be able to be authenticated.

At the end of the following exchange you mention that it
is unclear what requirement is being addressed and
what ind of treatment would be done with such an identity
field. The comment is not necessarily related to 
authentication. 

- The requirement is to include the identities of 
  participating parties in the request and in the 
  response, in order to indicate who has participated.

  This is independant of whether this matches with
  some authentication. 

- The treatment is essentially for display purposes
  to be able to describe show the transaction result
  together with the identities with the need to 
  understand a particular way how these information
  can be found in some authnetication envelope.

- Anyway, the response should provide for a means
  to indicate for whom the response has been made,
  not only who has made the response.  

Peter

----------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Chadwick | 3 Apr 2002 00:39
Picon

Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt)


Ken Stillson wrote:
> 
>   On Mon, 1 Apr 2002, David Chadwick wrote:
> > All constructive comments welcomed
> 
>   Hi David-
>   A thought for the you...
> 
>   Although implied by section 3, perhaps it should be stated expectedly:
> 
>   "A PKI object should be placed into a LDAP directory such that the LDAP
>    object DN matches the subject DN of the object."
> 

Ken

whilst I agree with you that this is an obvious thing to do, I dont
believe the ID should say how people should structure their DITs. As
this is a general standard, people are free to structure their DITs in
any way they wish to, and should still be able to use the subschema in
this ID. I think it should rather be a BCP that tells people the best
way to build their directories so that they have the minimum of hassles
operationally. (But I bet it will be difficult to get people to agree on
the contents of the BCP)

David

>   Although this seems obvious to some, I've run into a surprising number of
>   clients setting up directories using some alternate structure, who are
(Continue reading)

Permalink | Reply | 0 comments |

Gmane