Subject: Re: [pkix] minutes posted, comments welcome.

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 10 Nov 2010 17:06:47 +0100

In order to save you time, here is the URL:

http://www.ietf.org/proceedings/79/minutes/pkix.htm

Denis

----- Message reçu ----- 
De : pkix-bounces 
À : pkix 
Date : 2010-11-10, 08:01:09
Sujet : [pkix] minutes posted, comments welcome.

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 10 Nov 2010 17:54:11 +0100

I was not present at the meeting.

However, when reading the minutes:

1) About OCSP Update, the text of the minutes states:
"Still unresolved is how to handle critical extensions that are unrecognized".

This sentence may let think that the single unresolved problem is how to handle 
critical extensions that are unrecognized. However, there are other unresolved topics.

e-mails have been sent and not responded by the co-editors on the issue that 
"the locally trusted responder should be based on trusted key and not just the name".

A text proposal on how to verify the signature of an OCSP response has been sent 
in order to solve this issue. A new draft with changes is thus expected.

2) About OCSP Agility, the text of the minutes states:
"It was decided to not make any additional changes to this doc";

I had a face to face discussion with Stefan today and he expects to issue a new draft with changes 
that will accommodate my comments.

Since Stefan was present by phone at the meeting, he might help to propose 
the appropriate changes to the text of the minutes.

Denis

.

Denis

--------- 
De : pkix-bounces 
À : pkix

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 10 Nov 2010 11:55:27 -0500

A quick clarification on the OCSP Update presentation:

Several issues have been resolved, e.g., the nonce

extension is defined as an OCTET string, and the

ASN.1 module has been modified accordingly.

This was a misreading of what was two separate issues on Slide 3 of the
presentation.  Section 2.1.1.1 of draft-ietf-pkix-rfc2560bis-02
indicates that the syntax for the nonce extension is OCTET STRING, but
I did not make any changes to the ASN.1 module (e.g., by adding a line
that says "Nonce ::= OCTET STRING").

The second bullet item on Slide 3 is not related to the nonce
extension.  It notes that I changed the IMPORTS section of the ASN.1
module in Appendix C.1 as discussed on the list:

-- Directory Authentication Framework
(X.509)

Certificate, AlgorithmIdentifier, CRLReason

FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1)

authenticationFramework(7) 3 }

-- PKIX Certificate Extensions

AuthorityInfoAccessSyntax, CRLReason,
GeneralName

FROM PKIX1Implicit88 { iso(1) identified-organization(3)

dod(6) internet(1) security(5) mechanisms(5) pkix(7)

id-mod(0) id-pkix1-implicit-88(2) id-pkix1-implicit(19) }

Name, GeneralName,
CertificateSerialNumber, Extensions,

id-kp, id-ad-ocsp, Certificate,
AlgorithmIdentifier

FROM PKIX1Explicit88 { iso(1) identified-organization(3)

dod(6) internet(1) security(5) mechanisms(5) pkix(7)

id-mod(0) id-pkix1-explicit-88(1)
id-pkix1-explicit(18) };

---

From: Stephen Kent <[email-masked]>
Date: Thu, 11 Nov 2010 00:40:05 -0500

At 11:55 AM -0500 11/10/10, David A. Cooper wrote:
>This was a misreading of what was two separate issues on Slide 3 of 
>the presentation.  Section 2.1.1.1 of draft-ietf-pkix-rfc2560bis-02 
>indicates that the syntax for the nonce extension is OCTET STRING, 
>but I did not make any changes to the ASN.1 module (e.g., by adding 
>a line that says "Nonce ::= OCTET STRING").
>
>    -- Directory Authentication Framework (X.509)
>       AuthorityInfoAccessSyntax, CRLReason, GeneralName
>       Name, GeneralName, CertificateSerialNumber, Extensions,
>       id-kp, id-ad-ocsp, Certificate, AlgorithmIdentifier
>            id-mod(0) id-pkix1-explicit-88(1) id-pkix1-explicit(18) };

David,

Thanks for the clarification.  I will amend the minutes accordingly.

Steve

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 16 Nov 2010 20:38:06 -0800

David,

Do you believe that an Errata should be filed on RFC 5912 when this document
progresses that specifies that the extension is associated with an OCTET
STRING, or should it be left as is which is to assume that the object is not
necessarily ASN.1 encoded?

Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. Cooper
Sent: Wednesday, November 10, 2010 8:55 AM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: [pkix] minutes posted, comments welcome.

This was a misreading of what was two separate issues on Slide 3 of the
presentation.  Section 2.1.1.1 of draft-ietf-pkix-rfc2560bis-02 indicates
that the syntax for the nonce extension is OCTET STRING, but I did not make
any changes to the ASN.1 module (e.g., by adding a line that says "Nonce ::=
OCTET STRING").

The second bullet item on Slide 3 is not related to the nonce extension.  It
notes that I changed the IMPORTS section of the ASN.1 module in Appendix C.1
as discussed on the list:

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 17 Nov 2010 09:31:55 -0500

On 11/16/2010 11:38 PM, Jim Schaad wrote:

Do
you believe that an Errata should be filed on RFC 5912 when this
document progresses that specifies that the extension is associated
with an OCTET STRING, or should it be left as is which is to assume
that the object is not necessarily ASN.1 encoded?

Jim,

I believe that RFC 5912 already specifies that the nonce extension in
OCSP has a syntax of OCTET STRING:

re-ocsp-nonce EXTENSION ::= { SYNTAX OCTET STRING IDENTIFIED

BY id-pkix-ocsp-nonce }

However, if an update to RFC 5912 is ever prepared, the syntax for the
id-pkix-ocsp-nocheck extension could be added.  In RFC 2560, there is a
statement in Section 4.2.2.2.1 that the value of the extension SHOULD
be NULL (2560bis says SHALL be NULL), but nothing was included in the
ASN.1 module other than the extension's OID.  The same was done in RFC
5912.  So, the id-pkix-ocsp-nocheck OID is defined, but the extension's
syntax is not, and the extension is not listed in CertExtensions, the
list of defined certificate extensions.

Dave

---

From: "Adriano.Santoni" <[email-masked]>
Date: Thu, 18 Nov 2010 15:27:36 +0100

Hello all,

maybe if I am asking an old question....

Is anybody aware of any standard / guideline / recommendation /against/ 
the use of multiple-AVA RDNs in certificates?

I am not assuming it exists, I am just wondering.

Adriano

---

From: Michael D'Errico <[email-masked]>
Date: Thu, 18 Nov 2010 10:42:03 -0800

> the use of multiple-AVA RDNs in certificates?

I know I have seen people recommend against them, though I don't recall
seeing a formal document.  However, I have seen many certificates that
do use them (such as CN paired with another attribute), so if you are
looking for an excuse not to support them in your software, you will run
into trouble.

Mike