Subject: RE: WG Last Call Comment for 3280bis

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 1 Dec 2006 05:40:28 -0800

I am not ok with Russ's language for the reasons I and David Cooper have
cited.

I am ok with Wen-Cheng suggestion of deprecating the hold instruction.
It is non-critical anyway and the CRL processing logic does not discuss
it now.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, December 01, 2006 7:11 AM
To: [email-masked]; Russ Housley
Subject: Re: WG Last Call Comment for 3280bis

I am ok with this change.

If possible, I would prefer the WG to deprecate the whole use of
the hold instruction extension but only allow the use of
"certificateHold"
and "removeFromCRL" CRL reason code. Doing that will
make certificate suspension mechanism more simple and more
interoperable.

Wen-Cheng Wang

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 01, 2006 2:23 AM
Subject: WG Last Call Comment for 3280bis

> 
> I know that Steve Kent called the 3280bis closed on 11/7/2006, but 
> the recent thread regarding on-hold needs to become a concrete 
> proposal for a change in the text.  Here is my suggestion.
> 
> OLD TEXT:
> 
>    The following instruction codes have been defined.  Conforming
>    applications that process this extension MUST recognize the
following
>    instruction codes.
> 
>    holdInstruction    OBJECT IDENTIFIER ::=
>                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }
> 
>    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>    id-holdinstruction-callissuer
>                              OBJECT IDENTIFIER ::= {holdInstruction 2}
>    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
> 
>    Conforming applications that encounter an id-holdinstruction-
>    callissuer MUST call the certificate issuer or reject the
>    certificate.  Conforming applications that encounter an id-
>    holdinstruction-reject MUST reject the certificate.  The hold
>    instruction id-holdinstruction-none is semantically equivalent to
the
>    absence of a holdInstructionCode, and its use is strongly
deprecated
>    for the Internet PKI.
> 
> PROPOSED REPLACEMENT TEXT:
> 
>    The following instruction codes have been defined.  Conforming
>    applications that process this extension MUST recognize the
>    id-holdinstruction-reject instruction code.
> 
>    holdInstruction    OBJECT IDENTIFIER ::=
>                     { iso(1) member-body(2) us(840) x9-57(10040) 2 }
> 
>    id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction 1}
>    id-holdinstruction-callissuer
>                              OBJECT IDENTIFIER ::= {holdInstruction 2}
>    id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction 3}
> 
>    Conforming CAs MUST NOT make use of the
>    id-holdinstruction-callissuer instruction code.
> 
>    Conforming applications that encounter any of these hold
instruction
>    codes MUST reject the certificate.
> 
>    Communities may elect to use additional hold instruction codes;
>    however, caution ought to be exercised in adopting any additional
>    hold instruction codes that might prevent use in a general context.
>

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 04 Dec 2006 03:29:37 +1300

"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;
>    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: "Santosh Chokhani" <[email-masked]>
Date: Mon, 4 Dec 2006 12:35:25 -0800

Stefan,

I also prefer deprecating the use of instruction code.  Simpler is
better.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, December 04, 2006 10:35 AM
To: Santosh Chokhani; 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
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]
> Subject: RE: WG Last Call Comment for 3280bis
>
>
> I am ok with Peter's suggestion.
>
> 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
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 5 Dec 2006 06:45:45 -0800

Amen

-----Original Message-----
From: pgut001 [mailto:[email-masked]] 
Sent: Tuesday, December 05, 2006 7:22 AM
To: Santosh Chokhani; [email-masked]; [email-masked];
[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'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: "Santosh Chokhani" <[email-masked]>
Date: Thu, 7 Dec 2006 14:44:41 -0800

Can we have the actual proposed language?

Thanks.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Thursday, December 07, 2006 4:10 PM
To: Stefan Santesson; [email-masked]
Subject: RE: WG Last Call Comment for 3280bis

Stefan:

>Question to Russ: Why not say so about the whole extension instead 
>of individual instruction codes?

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

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 8 Dec 2006 15:12:24 -0800

Carlos,

There is nothing in 3280 or 3280 Biz to support your claims below.  You are making assumptions to support a position.

I have provided appropriate language for 3280 Biz in a post to Steve Kent 1-2 days back.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Carlos González-Cadenas
Sent: Friday, December 08, 2006 6:01 PM
To: Santosh Chokhani
Cc: pkix
Subject: Re: WG Last Call Comment for 3280bis

Santosh,

With respect to 

>Also, this assumes a business model for "on hold" that limits why folks put certificates on hold.  >To be precise, if the certificate is on hold because the credential is in transit or otherwise >should not be used (e.g., private key holder on extended leave), in your approach the question >about "hold" period will say that the certificate was good, but the intent of the CA and the >subscriber is that the certificate was not good during the hold period.

I fully agree with your conclusion. IMHO I think that this business model cannot be supported in today's 3280/3280bis, as determining that the certificate was not good at that moment would require CRL archiving, and as far as I know that is out of scope for 3280/3280bis. 

As far as I can see, the only technically possible business models are these where, in case that the certificate is not finally revoked after being on-hold,  there's no need to know that the certificate was on-hold. I know that many folks use on-hold for "credential-in-transit" or "extended-leave", but there are no technical means for RPs inside 3280/3280bis i.e. to reject a signature created while the certificate was on-hold.

Maybe completing Stefan's proposed wording with in the following way would work:

A certificate that has been cleared from on hold status to a non revoked status SHOULD be treated as if it has never been revoked or on hold. Conforming CAs SHOULD NOT use the on-hold status for purposes ( i.e. credentials in transit, extended leave of the private key holder, ...) that require the relying parties to reject the certificate when checked for validity inside the hold period after the certificate is cleared from on hold status. 

Best Regards,

Carlos

On 12/8/06, Santosh Chokhani <[email-masked] > wrote:

Carlos,

In case 2, you are making the point I am making.  The result will always be that of current time.

________________________________

From: [email-masked] [mailto: [email-masked] <mailto:[email-masked]> ] On Behalf Of Carlos González-Cadenas
Sent: Friday, December 08, 2006 1:38 PM
To: Santosh Chokhani
Cc: Stefan Santesson; Stephen Kent; pkix
Subject: Re: WG Last Call Comment for 3280bis

Santosh,

Of course. I'll try to be more precise. Sorry for the inconvenience.

Let's assume:

VT = the instant of time in which a RP performs the validation of a certificate (i.e. when you use your cert path validation software / you press the validate button, ...). 
T = the instant of time in which we want to know if the certificate is/was valid or not (i.e. obtained via a timestamp in a signature). This is the instant that gets checked against the revocation date of the CRL.
NB = Not Before
NA = Not After
HS = Hold Period Start
HE = Hold Period End
CRL = CRL ThisUpdate

The default (and most common case) is VT=T (the RP doesn't provide T). That's validating the certificate at the actual moment (VT) and in the actual moment (T) ( i.e. we're interested now in the actual certificate status).

Validating in a time in the past implies T<VT (we request to validate certificate in T at a later instant VT). For that we can have two possible temporal sequences of interest: 

1) NB<HS<T<HE<CRL<NA<VT, we want to know the certificate status in T AFTER the end of the certificate validity period, here we need CRL archival (CRLs issued after NA doesn't contain any info about the certificate), and, as you said, this is not covered by 3280/3280bis. 

2) NB<HS<T<HE<CRL<VT<NA, so we want to know at VT (before the end of validity of the certificate) the status of the certificate in T. This case (if I'm not wrong) is covered by 3280/3280bis and does not require archival of CRLs, as we can use the CRL issued at the CRL instant depicted above. The CRL will not contain any revocation entry (as it's issued after HE), and therefore the certificate will be considered valid (and in my opinion that's correct). 

That 2) is in sync with Stefan's proposal:
> A certificate that has been cleared
> from on hold status to a non revoked status SHOULD be treated as if it 
> has never been revoked or on hold. I.e. that the certificate once
> cleared is valid for its full validity period.

Regards,

Carlos

On 12/8/06, Santosh Chokhani < [email-masked] <mailto:[email-masked]> > wrote:

Carlos,

Can you explain what the difference is between what you say and current time.

Note 3280 Biz statement "Note that mechanisms are not available for validating a
   certificate with respect to a time outside the certificate validity

   period."
 
So, the certificates are not expired and you use current CRL.  To me it seems that is validating as of this time and not some time in the past.

________________________________

From: [email-masked] [mailto: [email-masked] <mailto:[email-masked]> ] On Behalf Of Carlos González-Cadenas
Sent: Friday, December 08, 2006 11:37 AM

To: Santosh Chokhani
Cc: Stefan Santesson; Stephen Kent; pkix
Subject: Re: WG Last Call Comment for 3280bis

Santosh,

I don't agree in your affirmation:

>>If you verified a certificate using current CRL, that is like verifying as of this time and not >>as of a time in the past.

Using up-to-date CRL information doesn't imply verifying the certificate status at this time. In fact, the CRL entries contain (past) information about when the revocation of the certificate was produced (so you can use this information to compare with the instant of time you want to validate the certificate in). 

Being the nature of CRL like an "historical accumulative database of revocation events",  for sure you want the most-updated applicable CRL (when saying "applicable" I mean that not all the CRLs issued by a CA contain information for that certificate, potentially only the ones issued before the certificate expiration time). 

The CA is only allowed to remove revocation entries from the "historical accumulative database" (CRL) in the on-hold case, when the certificate is finally determined valid: so, no revocation event, I don't see why would one want to reject the certificate after the on-hold period, when the CA considers there's no revoked certificate (it only makes sense within the on-hold period as a cautionary measure). 

Best regards,

Carlos

On 12/8/06, Santosh Chokhani < [email-masked] <mailto:[email-masked]> > wrote: 

Carlos,

If you verified a certificate using current CRL, that is like verifying as of this time and not as of a time in the past.

Logical definition of a time of interest is to say what the PKI artifacts were at that time and what answer we would have gotten.

The proposed solution also keeps the business model for hold out in the first place.

________________________________

From: [email-masked] [mailto: [email-masked] <mailto:[email-masked]> ] On Behalf Of Carlos González-Cadenas
Sent: Friday, December 08, 2006 11:06 AM
To: Santosh Chokhani
Cc: Stefan Santesson; Stephen Kent; pkix
Subject: Re: WG Last Call Comment for 3280bis

Santosh, Stefan,

I agree with Stefan in both proposals, seeing that the second is of great value, as it clarifies how to proceed for RPs in an area that is certainly difficult and open to interpretation.

I disagree with Santosh in this afirmation: 

>>I would think that Section 6 will give the answer you expect for current
>>time.  In terms of a time in the past, specifically for a time during
>>the hold period, I would think that the user should get CRL applicable 
>>at that time and reject the certificate.

I don't see any reason for not being able to validate in the past a certificate that is within its validity period in the instant of validation, using the latest CRL issued by the CA (no need in this case for archived CRLs). Using Stefan's proposal, if that certificate was removed from hold to valid in the past,  the validation will be successful (no entry in the CRL regarding this cert). 

Note that even when the certificate is expired and CRL archival is needed to validate the certificate, it's not necessary to pick the CRL that included the certificate on-hold. One can get the latest CRL issued before certificate expiration (this makes sense, as it's the most updated one). 

For me this behaviour makes sense, the certificate will be only rejected when it's on-hold and you're validating this certificate in this hold period. When the certificate is removed from hold to valid, no need to consider this certificate revoked in any time in the future (including validations performed after the hold period). 

Best regards,

Carlos

On 12/8/06, Santosh Chokhani < [email-masked] <mailto:[email-masked]> > wrote: 

Stefan,

I agree with your concern, but not your solution.

Section 6.1 of thee 3280 Biz states: 

"The algorithm presented in this section validates the certificate with
respect to the current date and time.  A conforming implementation MAY
also support validation with respect to some point in the past.  Note 
that mechanisms are not available for validating a certificate with
respect to a time outside the certificate validity period."

I would think that Section 6 will give the answer you expect for current
time.  In terms of a time in the past, specifically for a time during
the hold period, I would think that the user should get CRL applicable
at that time and reject the certificate.

BTW, is there a reason you do not answer about CRL Issuer question?  Do 
you compliant Issuers to have option of asserting hold instruction?

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]
Sent: Friday, December 08, 2006 7:35 AM 
To: Santosh Chokhani; Stephen Kent
Cc: pkix
Subject: RE: WG Last Call Comment for 3280bis

Santosh.

What I mean by the second remark, is not what it means from a business
model perspective. I was aiming of what it means technically from a path 
validation perspective. The tricky part is that this is mostly matter
for historical validation, and historical validation is out of scope for
RFC 3280, and should be.

However, the important point is if a certificate is validated in the 
present, and it is not revoked, it doesn't matter if that certificate
has been on hold in the past, even if the signature validated was signed
during a time window when the certificate was on hold.

This seems to be a source of confusion and thus a clarification might be 
useful.

Stefan Santesson
Senior Program Manager

> From: Santosh Chokhani [mailto:[email-masked] ]
> Sent: den 8 december 2006 12:47
> To: Stefan Santesson; Stephen Kent
> Cc: pkix
> See below.
> Sent: Friday, December 08, 2006 6:25 AM
> To: Santosh Chokhani; Stephen Kent 
> Cc: pkix
> To be picky;
> We need to be careful not to say that anyone must reject a
certificate.
> This is still a decision of the RP. There is a difference between the 
> decision to rely on something for a business reason and to accept the
> certificate as valid.
>
> What we should say is that: A certificate on hold MUST be treated as
> revoked and MUST fail path validation regardless of any present hold 
> instruction code.
> [Santosh Chokhani] Agree.
>
> What we also might want to say is: A certificate that has been cleared
> from on hold status to a non revoked status SHOULD be treated as if it 
> has never been revoked or on hold. I.e. that the certificate once
> cleared is valid for its full validity period.
> [Santosh Chokhani] I am not sure on this one.  It depends on the
> business model and RP. 
>
> Also, what about compliant CRL Issuers?  Should they use hold
> instruction extension.  Backward compatibility notwithstanding, I
think
> not.
> > Sent: den 7 december 2006 01:19
> > To: Stephen Kent
> > Cc: pkix
> > Steve,
> > How about the following:
> > Compliant producers (i.e., CAs and CRL Issuers) shall not use hold
> > instruction.
> > 
> > Compliant consumer (i.e., relying parties) shall reject the
> certificate
> > regardless of the hold instruction.  Compliant consumers may take
> > additional actions as suggested by the hold instruction as long as 
> > those
> > actions are consistent with the rejection of the certificate.
> >
> > From: Stephen Kent [mailto:[email-masked] ]
> > Sent: Wednesday, December 06, 2006 6:34 PM
> > To: Santosh Chokhani
> > Cc: pkix
> > At 2:19 PM -0800 12/6/06, Santosh Chokhani wrote: 
> > >Steve,
> > >
> > >My apologies for the interruption.
> > >
> > >We generally use hold and suspension as the same.
> > >
> > >A practical and simple solution for 3280 Bis is to recommend that 
> > >regardless of the hold instruction, the certificate that is on hold
> as
> > >of the time of interest shall be rejected.
> > >
> >
> > Yes, that is the simplest thing to do. The only other question is 
> > what we say about hold instructions, short of banning them, given
> > that we require only that a client treat a cert on hold just like
any
> > other cert on a CRL.
> > Steve

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 13 Dec 2006 16:06:37 -0800

Stefan,

I agree with you.

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Wednesday, December 13, 2006 9:44 AM
To: Michael Ströder; Santosh Chokhani
Cc: pkix
Subject: RE: WG Last Call Comment for 3280bis

A non-revoked certificate when validated in present time is good, regardless of whether it has been on hold in the past.
What it is used for (e.g. validating a signature from some time in the past) is totally up to the relying party and outside the scope of 3280bis.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Michael Ströder
> Sent: den 12 december 2006 13:10
> To: Santosh Chokhani
> Cc: pkix
> Santosh Chokhani wrote:
> > Now, to the other question about "Should the certificate have been
> good
> > at time t" in the case of hold instruction, the answer depends on the
> > reason for hold.  Different folks use hold for different reasons.  If
> > certificates are put on hold because the credential is in transit and
> > should not be used while in transit or a user suspends a certificate
> > because he is on extended leave, then the answer should be reject the
> > certificate.
>
> Yes, reject.
>
> >  If the hold was for investigation of possible compromise
> > or otherwise need to revoke, then the certificate should be accepted.
>
> Really? As I read your text I'd also reject it.
>
> Ciao, Michael.

---

From: Sharon Boeyen <[email-masked]>
Date: Thu, 14 Dec 2006 11:41:10 -0500

I think this is definitely the simplest approach and support it too.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Thursday, December 14, 2006 10:36 AM
To: Tim Polk; [email-masked]
Subject: RE: WG Last Call Comment for 3280bis

I'm also fine with this approach.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Tim Polk
> Sent: den 13 december 2006 23:00
> To: [email-masked]
> Folks,
> I have some troubles with the direction of the discussion on the 
> certificate hold instruction, but I believe there is a very simple 
> solution.
>
> The problem is this: X.509 defined the CRL entry extension but did not 
> specify any codes; X9.57 defined the hold instruction codes.  Since 
> the X9 codes are oriented towards the financial services industry, 
> they don't really apply to most Internet applications.  Specifically, 
> I find it hard
> to imagine a lot of Internet applications where someone calls the
> issuer to
> verify the certificate status.  However, redefining the codes is not a
> good
> solution.  We should not be telling relying parties to process these
> codes
> according to an alternative set of rules.
>
> Since everyone seems to be uncomfortable with the hold instruction 
> code CRL entry extension, and even more uncomfortable with the only 
> defined hold instruction codes, the solution is straightforward. We 
> should follow the
> model used with the private key usage period certificate extension.  We
> should remove the extension from 3280bis in its entirety (as opposed to
> including it and deprecating its use.)
>
> I can't see a reason that removing this extension would cause 
> problems.  Relying parties that process a CRL containing an 
> unrecognized noncritical extension will ignore it.  Relying parties 
> that support this
> extension and the X9.57 codes (presumably to support the financial
> services
> applications) need to be aware of the semantics for these codes and
> enforce
> them.  I admit to some confusion about these semantics myself, but it
> isn't
> PKIX's responsibility to clarify these semantics!
>
> I think the real problem here is an error of omission in section 
> 5.3.1, reason code.  The description of this CRL entry extension 
> assumes that the names of the reason codes are self explanatory.  The 
> entire text for 5.3.1
> follows:
>
>
> >The reasonCode is a non-critical CRL entry extension that identifies
> the
> >reason for the certificate revocation. CRL issuers are strongly
> encouraged
> >to include meaningful reason codes in CRL entries; however, the 
> >reason code CRL entry extension SHOULD be absent instead of using the
> unspecified
> >(0) reasonCode value.
>
> I suggest adding the following text after the current paragraph:
>
> >The removeFromCRL (8) reasonCode  value may only appear in delta 
> >CRLs,
> and
> >indicates that a certificate is to be removed from a CRL because
> either
> >the certificate expired or was removed from hold.  All other reason
> codes
> >may appear in any CRL, and indicate that the specified certificate
> should
> >be considered revoked.  It is a relying party decision whether a 
> >particular revocation reason precludes acceptance of a revoked
> certificate.
>
> My two cents.
>
> Tim Polk