Subject: RE: WG Last Call Comment for 3280bis

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 3 Dec 2006 07:15:32 -0800

I am ok with Peter's suggestion.

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Sunday, December 03, 2006 9:30 AM
To: Santosh Chokhani; [email-masked]; [email-masked]
Subject: RE: WG Last Call Comment for 3280bis

"Santosh Chokhani" <[email-masked]> writes:

>The phrase "that might prevent use in a general context" is not clear.
>
>Do you mean prevent use of certificate, of hold reason code, or hold
>instruction, or something else?
>
>May be the following makes sense:
>
>    "Communities may elect to use additional hold instruction codes;
>    however, caution ought to be exercised in adopting any additional
>    hold instruction codes since additional hold instruction codes may
>    not be understood by all the relying parties"

It makes sense (in the sense that it parses gramatically), but it still
doesn't correctly convey the intent, which is to say "If you use this
extension, you're on your own, because no two people can agree on how to
handle it".  Perhaps the text could say something like:

  There is no consensus in the community over how to handle this
extension
  except for general agreement that it's a bad idea and shouldn't be
used.
  Developers should be aware that the semantics of this extension depend
  heavily on individual implementations, and may vary widely across
  implementations.

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 4 Dec 2006 15:34:32 +0000

I would like to avoid such state of the art language in standards, and simply state what the recommendation/requirement is.

I think it is good to recommend against use of instruction code. I'm OK with SHOULD NOT and could also buy MUST NOT.
Question to Russ: Why not say so about the whole extension instead of individual instruction codes?

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Santosh Chokhani
> Sent: den 3 december 2006 16:16
> To: pgut001; [email-masked]; [email-masked]

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 4 Dec 2006 15:09:44 -0500

Stefan,

I agree, although you still need to take care, as Russ did,
to specify issuer and application requirements separately:

     Conforming CRL Issuers {SHOULD|MUST} NOT make use of the
     hold-InstructionCode extension.

     Conforming applications that encounter this extension
     with any hold instruction codes MUST reject the certificate.

Prohibiting the entire extension closes the door on something
Russ' language theoretically permitted: achieving universal
understanding and globally consistent treatment (other than
reject) of a new instruction code (other than 1, 2 or 3).
Given the likelihood of that happening, deprecating the whole
extension is the right approach. 

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Monday, December 04, 2006 10:35 AM
To: Chokhani, Santosh; pgut001; [email-masked]; [email-masked]
Subject: RE: WG Last Call Comment for 3280bis

I would like to avoid such state of the art language in standards, and
simply state what the recommendation/requirement is.

I think it is good to recommend against use of instruction code. I'm OK
with SHOULD NOT and could also buy MUST NOT.
Question to Russ: Why not say so about the whole extension instead of
individual instruction codes?

Stefan Santesson
Senior Program Manager

---

From: "Michael Myers" <[email-masked]>
Date: Mon, 4 Dec 2006 16:23:25 -0800

Is is possible to do this without resorting to untestable negative
requirements?

Mike

-----Original Message-----
From: Kemp, David P.
Sent: Monday, December 04, 2006 12:10 P
>                                      ^^^

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 05 Dec 2006 11:29:28 +0100

>      hold-InstructionCode extension.
Do you really want this, or do you want to say:

- A conforming implementation MAY choose not to implement hold?

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorite'; 
die Liste mit zuru"ckgerufenen Zertifikaten finden Sie da auch.

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 05 Dec 2006 12:42:41 +0100

> - A conforming implementation MAY choose not to implement hold?

I guess the main issue here is that we have to agree if the extension is
to be deprecated or simply we "suggest" not to use it... I am in favor of
deprecating it, therefore a "SHOULD NOT" is fine with me...

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept
PKI/Trust
--o------------------------------------------------------------------------

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 06 Dec 2006 01:21:47 +1300

Stefan Santesson <[email-masked]> writes:

>I would like to avoid such state of the art language in standards, and simply
>state what the recommendation/requirement is.

I'm not terribly fussed about the exact phrasing, as long as it clearly and
unambiguously states either "Do not under any circumstances use this
extension" or alternatively "If you use this extension and run into problems
with it, the entire PKIX WG will laugh at you in the sinister manner of Joseph
Stalin just before he enslaved eastern Europe".  Having wording that requires
that you hold the text upside-down in front of a mirror in order to determine
that this is what it's actually saying won't be too helpful to most readers.

Peter.

---

From: "Kemp, David P." <[email-masked]>
Date: Tue, 5 Dec 2006 12:18:41 -0500

> From: Michael Myers [mailto:[email-masked]] 
>

Well, it is negative, but it's certainly not untestable.  One can
prove by inspection whether a CRL issuer is compliant with this
requirement or not.

This isn't a tree-falling-in-the-empty-forest kind of negative;
you're not trying to test that a CRL issuer has never created a
non-compliant CRL or is incapable of doing so, you're only trying
to test whether the issuer "makes use of" (i.e. creates and
makes visible to RPs) such a CRL.

-----Original Message-----
> - A conforming implementation MAY choose not to implement hold?

MAY choose not to implement hold (section 5.3.1 bits 6 and 8),
depending on other discussion, but MUST NOT use hold instruction
(section 5.3.2), per this thread.

Dave

---

From: Michael Ströder <[email-masked]>
Date: Thu, 07 Dec 2006 18:56:08 +0100

> deprecating it, therefore a "SHOULD NOT" is fine with me...

+1 for deprecating it as clearly as possible

Ciao, Michael.

---

From: Russ Housley <[email-masked]>
Date: Thu, 07 Dec 2006 16:10:20 -0500

>of individual instruction codes?

I'm okay with that too.  In fact, I'd prefer it.

Russ