headers
Stephen Kent | 1 Mar 2006 10:24
Picon

last calls


Folks,

In preparation for the Dallas meeting, I'd like to initiate last 
calls for two documents:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-srvsan-01.txt

and

http://www.ietf.org/internet-drafts/draft-ietf-pkix-cert-utf8-01.txt

Please provides comments to the list by March 10th.

Thanks,

Steve
Permalink | Reply | 0 comments |
headers
Peter Sylvester | 1 Mar 2006 14:37
Picon
Picon
Favicon

Re: SCVP: Certificate value & ESSCertID (minor)

Tim Polk wrote:
> Peter, Sam, and Denis,
>
> I believe that we want to ensure that SCVP servers can parse requests, 
> even if they include certificate types that aren't support (e.g., 
> attribute types), or certificates are referenced using an unsupported 
> mechanism (e.g., certificate hash). I agree the current text is 
> unclear and also think that attribute certificates are not covered 
> comprehensively.
If that is what you want then your proposed text does not fit.
In the following you don't require unconditional parsing.

"Conforming SCVP server MUST be able to parse all choices of 
PKCReference and ACReference."

Or at least you can add

"Conforming SCVP server MUST be able to return unsupported choices of 
PKCReference and ACReference in a CVResponse."

This doesn't imply complete parsing.

>
> To be really clear, I think we need to replace the sentence in the 
> last paragraph of section 3.2.1:
>
>     "Conforming SCVP Server implementations MUST be able to parse
>     CertReferences with certificates referenced by both inclusion and
>     CertID."
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Peter Sylvester | 1 Mar 2006 15:26
Picon
Picon
Favicon

SCVP chapter 3.3

I think that the text in 3.3 is not good and there is double text with 
section 7/

The first line "... contains a SEQUENCE of names ..." is not unfortunate
The definition says GeneralNames, so this is already asn.1 SEQUENCE. I 
think what is
meant is ".. contains a list of names ..." and "Although encoded as a 
SEQUENCE,
no order is implied." should be added.

The remaining of the first paragraph should not be there, it is already 
in section 7
concerning relaying. Talking about resources etc is really unrelated to the
description of that item.

The first sentence of the last paragraph is superfluous since this is 
just the syntax.

In section 7 change "sequence of names" to "list of names"

And: "the server-generated request MUST contain a requestorRef item 
consisting
if the names in the provided requestorRef and an identifier of the SCVP 
server."

We know alrteady that it is a GeneralName, and the order has no importance.

What is the value of returning a requestoRef, in particular because a 
server can
omit it, and even if not, the value is the same as provioded by the
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russ Housley | 1 Mar 2006 16:35

Re: Comments on draft-ietf-pkix-cert-utf8-01.txt


Jim:

Thanks for the first WG Last Call comments.

>1.  Page 2 last paragraph:  "issuer and and the old" - remove duplicate
>"and"

Agree.  It will be included in the next revision.

>2.  Inclusion of the section title would improve the readablity of the
>document.

Agree.  It will be included in the next revision.

>3.  Text dealing with connocalization (or the non-requirement for) should be
>included in the document.

Why?  That part of the text is unchanged.  This document cannot be 
understood without the rest of RFC 3280.

>4.  Does any text regarding Subject and issuer Alt Names need to be
>included?

Good question.  I asked this question when I read Santosh's posting, 
but no one has responded.  My initial reaction is that we should add 
it, but I would like to hear what others think.

Russ
(Continue reading)

Permalink | Reply | 6 comments |
headers
David A. Cooper | 1 Mar 2006 16:50
Favicon

Re: SCVP: Certificate value & ESSCertID (minor)


Peter,

We agree that a conforming SCVP server should be able to parse a 
CVRequest whether the request includes public key certificates or 
attribute certificates and whether the certificates are included in the 
request or are specified by reference.  Here is the full paragraph of 
the relevant text, with the revision that Tim has proposed:

   Conforming SCVP Server implementations MUST be able to process
   CertReferences with multiple certificates.  Conforming SCVP Server
   implementations MUST be able to parse CertReferences that contain
   either public key or attribute certificates.  Conforming SCVP Server
   implementations MUST be able to parse both the cert and pkcRef
   choices in PKCReference.  Conforming SCVP Server implementations
   that process attribute certificates MUST be able to parse both the
   attrCert and acRef choices in ACReference.

So, it states that SCVP servers must be able to parse requests that 
include attribute certificates.  However, a conforming SCVP server may 
simply return an error message in response to any request that includes 
attribute certificates.  The checks item in a request that includes 
attribute certificates would need to include at least one check 
associated with attribute certificates and section 3.2.2 states that 
SCVP server implementation are not required to support the attribute 
certificate checks.  So, a conforming SCVP server that does not support 
attribute certificates could simply return an error message with a 
response status of "unsupported checks" in response to any request that 
includes attribute certificates.  While the server would need to parse 
requests that include attribute certificates to do this, it would not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Housley | 1 Mar 2006 16:54

Re: 3280bis: private key usage extension (2)


I do not see any good from including this extension.  I suggest we 
drop it altogether.

It was included in RFC 2459 because we discussed all of the 
extensions that were in X.509 at the time.  We discourage its 
use.  Today, many more extensions have been added to X.509, and we 
make no attempt to keep up with them.  They are simply no part of the 
PKIX profile.  I strongly advocate the handling of this extension in 
the same manner.  Simple silence.

Russ

At 10:21 AM 2/16/2006, Denis Pinkas wrote:

>Copy of the minutes from the Paris PKIX meeting:
>
>"He [Denis] suggested that the private key usage extension not be 
>deprecated universally,
>but rather be allowed in certain contexts, e.g., time stamp crypto modules.
>He proposed to soften the prohibition against private key usage or 
>to delete annex D.1.
>and thus annex D) which is the only section that addresses this topic".
>
>Peter correctly recalls that there was no objection raised on that 
>issue by the participants
>of the Paris meeting.
>
>Stefan's argumentation is that it should not be part of the profile.
>There are many features described in the document that MAY be implemented
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stefan Santesson | 1 Mar 2006 18:22
Picon
Favicon

RE: 3280bis: private key usage extension (2)


I second Russ suggestion.

This thread makes it even clearer to me that we will not achieve
consensus on what this extension really means.

All information in a certificate is information associated with the
certified public key. This makes this extension confusing and the
proposed wording doesn't help.

Reading X.509 suggest that the extension signals to the relying party
that the corresponding private key is restricted but does is not clear
on how that is enforced or what impact a violation of this restriction
has.

I suggest that those who want's to clarify this extension write a Defect
Report to X.509 and use that as basis for their eventual implementation.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
On Behalf Of Russ Housley
Sent: den 1 mars 2006 16:55
To: Denis Pinkas; pkix
Subject: Re: 3280bis: private key usage extension (2)

I do not see any good from including this extension.  I suggest we
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Santesson | 1 Mar 2006 18:34
Picon
Favicon

RE: Comments on draft-ietf-pkix-cert-utf8-01.txt


On last issue, Subject and Issuer Alt Names I suggest we stay silent.

This draft is only concerned with fixing the false/bad utf-8 requirement
from RFC 3280. That text in rfc 3280 did not cover alt names so it
doesn't need fixing.

The only alt name that has directoryString encoding is EDI Party name
which is totally non relevant from a chaining and name constraints
perspective.

OtherName names should/could have their own conventions defined that we
don't want to mess with.

If something needs be said anyway, I suggest we do that in rfc 3280bis.
Better to keep this small draft focused.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
On Behalf Of Russ Housley
Sent: den 1 mars 2006 16:36
To: Jim Schaad; ietf-pkix <at> imc.org
Subject: Re: Comments on draft-ietf-pkix-cert-utf8-01.txt

Jim:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Polk | 1 Mar 2006 19:05
Favicon

Re: SCVP chapter 3.3


Peter,

IMHO, the most straightforward implementation of requestorRef would be 
achieved if the server maintained ordering and simply appended their name 
to the current value.  There is currently one sentence in Section 7 that 
implies this technique.

However, there is no security rationale for requiring ordering in the 
requestorRef list of names.  All that is required is that previous values 
be included in subsequent requests.

Since this is not a security requirement, and there is no reason to limit 
developers, I will make the appropriate changes to sections 3.3 and 7 to 
indicate the requestorRef is not ordered.  (I will post the text later 
today...)

SCVP servers that don't implement relay MUST satisfy the requirements in 
sections 3.3 and 4.7.   That is, they MUST copy the value into the 
requestorRef field in the response.  Such servers need not satisfy any 
additional requirements from Section 7.  That is, such servers need not 
review the names in requestorRef for their own name, since loopback is not 
an issue.

Thanks,

Tim Polk

At 03:26 PM 3/1/2006 +0100, you wrote:
>I think that the text in 3.3 is not good and there is double text with
(Continue reading)

Permalink | Reply | 1 comment |
headers
Santosh Chokhani | 1 Mar 2006 19:14

RE: Comments on draft-ietf-pkix-cert-utf8-01.txt


I would think the language for encoding subject alternative names should
be included since the name constraints are enforced on them also.

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
On Behalf Of Russ Housley
Sent: Wednesday, March 01, 2006 10:36 AM
To: Jim Schaad; ietf-pkix <at> imc.org
Subject: Re: Comments on draft-ietf-pkix-cert-utf8-01.txt

Jim:

Thanks for the first WG Last Call comments.

>1.  Page 2 last paragraph:  "issuer and and the old" - remove duplicate
>"and"

Agree.  It will be included in the next revision.

>2.  Inclusion of the section title would improve the readablity of the
>document.

Agree.  It will be included in the next revision.

>3.  Text dealing with connocalization (or the non-requirement for)
should be
>included in the document.

Why?  That part of the text is unchanged.  This document cannot be
(Continue reading)

Permalink | Reply | 0 comments |

Gmane