ietf
[Top] [All Lists]

RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

2013-03-28 10:12:56
Does this solve you issue.
I think this is as far as dare to go without risking a heated debate.

Yes, that suffices for me - it provides a cogent explanation of why
"revoked" is optional, and the existing text on CRLs as a fallback
mechanism suffices to illuminate a likely consequence of not using
"revoked".

Thank you,
--David

-----Original Message-----
From: Carlisle Adams [mailto:cadams(_at_)eecs(_dot_)uottawa(_dot_)ca]
Sent: Thursday, March 28, 2013 9:57 AM
To: 'Stefan Santesson'; Black, David; sts(_at_)aaa-sec(_dot_)com; 
mmyers(_at_)fastq(_dot_)com;
ambarish(_at_)gmail(_dot_)com; slava(_dot_)galperin(_at_)gmail(_dot_)com; 
gen-art(_at_)ietf(_dot_)org
Cc: pkix(_at_)ietf(_dot_)org; 'Sean Turner'; ietf(_at_)ietf(_dot_)org
Subject: RE: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

Hi,

This wording sounds fine to me.  Thanks Stefan!

Carlisle.


-----Original Message-----
From: Stefan Santesson [mailto:stefan(_at_)aaa-sec(_dot_)com]
Sent: March-28-13 6:34 AM
To: Black, David; sts(_at_)aaa-sec(_dot_)com; mmyers(_at_)fastq(_dot_)com; 
ambarish(_at_)gmail(_dot_)com;
slava(_dot_)galperin(_at_)gmail(_dot_)com; 
cadams(_at_)eecs(_dot_)uottawa(_dot_)ca; gen-art(_at_)ietf(_dot_)org
Cc: pkix(_at_)ietf(_dot_)org; Sean Turner; ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

I have given this a go by expanding the note as follows:

NOTE: The "revoked" state for known non-issued certificate serial
         numbers is allowed in order to reduce the risk of relying
         parties using CRLs as a fall back mechanism, which would be
         considerably higher if an "unknown" response was returned. The
         "revoked" status is still optional in this context in order to
         maintain backwards compatibility with deployments of RFC 2560.
         For example, the responder may not have any knowledge about
         whether a requested serial number has been assigned to any
         issued certificate, or the responder may provide pre produced
         responses in accordance with RFC 5019 and, for that reason, is
         not capable of providing a signed response for all non-issued
         certificate serial numbers.


Does this solve you issue.
I think this is as far as dare to go without risking a heated debate.

/Stefan


On 3/27/13 5:08 PM, "Black, David" <david(_dot_)black(_at_)emc(_dot_)com> 
wrote:

Stefan,

Is this important enough to do that?

IMHO, yes - the "running code" aspects of existing responder
behavior/limitations are definitely important enough for an RFC like
this that revises a protocol spec, and the alternatives to "revoked"
feel like an important complement to those aspects (discussion what to
do instead when responder behavior/limitations are encountered).

I appreciate the level of work that may be involved in capturing this,
as I've had my share of contentious discussions in WGs that I chair -
FWIW, I'm currently chairing my 4th and 5th WGs.  OTOH, when a WG has
put that much time/effort into reaching a (compromise) decision, it
really is valuable to record why the decision was reached to avoid
recovering that ground in the future and (specific to this situation)
to give implementers some more context/information on how the protocol
is likely to work in practice.

Thanks,
--David

-----Original Message-----
From: Stefan Santesson [mailto:stefan(_at_)aaa-sec(_dot_)com]
Sent: Wednesday, March 27, 2013 11:38 AM
To: Black, David; sts(_at_)aaa-sec(_dot_)com; mmyers(_at_)fastq(_dot_)com;
ambarish(_at_)gmail(_dot_)com; slava(_dot_)galperin(_at_)gmail(_dot_)com; 
cadams(_at_)eecs(_dot_)uottawa(_dot_)ca;
gen-art(_at_)ietf(_dot_)org
Cc: pkix(_at_)ietf(_dot_)org; Sean Turner; ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

I could.

My worry is just that this is such a contentious subject and it took
us x  hundreds of emails to reach this state, that if I add more
explanations,  people will start disagreeing with it and that we end
up in a long debate  on how to correctly express this.

Is this important enough to do that?

/Stefan


On 3/27/13 3:30 PM, "Black, David" <david(_dot_)black(_at_)emc(_dot_)com> 
wrote:

Hi Stefan,

Does this answer your question?

Yes, please add some of that explanation to the next version of the
draft
;-).
Coverage of existing responder behavior/limitations (important
"running code"
concerns, IMHO) and alternatives to using "revoked" ("have a number
of tools to prevent the client from accepting a bad certificate")
seem
particularly
relevant.

Thanks,
--David

-----Original Message-----
From: Stefan Santesson [mailto:stefan(_at_)aaa-sec(_dot_)com]
Sent: Wednesday, March 27, 2013 7:44 AM
To: Black, David; sts(_at_)aaa-sec(_dot_)com; 
mmyers(_at_)fastq(_dot_)com;
ambarish(_at_)gmail(_dot_)com;
slava(_dot_)galperin(_at_)gmail(_dot_)com; 
cadams(_at_)eecs(_dot_)uottawa(_dot_)ca; gen-art(_at_)ietf(_dot_)org
Cc: pkix(_at_)ietf(_dot_)org; Sean Turner; ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

Hi David,

Yes I missed to respond to that aspect.

This is a bit complicated, but we have a large legacy to take into
account  where some responders implements just RFC 2560, while some
deliver  pre-generated responses according to RFC 5019
(Light-weight OCSP). LW  responders are not capable of producing a
signed response at the
time of
responding and in case such responder finds a request for a
certificate
where no pre-produced response exists, it will reply with an
unsigned  error response "unauthorized", which also is a legitimate
way to respond.
So the actual OCSP responder may actually know that the
certificate
was
never issued, but since it delivers pre-produced responder through
a CDN,  it can not provide a revoked response in real time.

So the major aim with the current writing is to declare that the
revoked
response is a MAY because there are other valid alternatives.

We also want to avoid putting down a SHOULD respond revoked if a
certificate is known to be not-issued, because that would require
us
to
define what "known to be non-issued" actually means. And that
could
be
quite tricky as OCSP responders by no means are required to have
this knowledge.

The OCSP responder simply have a number of tools to prevent the
client
from accepting a bad certificate.
This update of OCSP simply allows responders to use the "revoked"
response
as a preventive measure, without mandating it.

This is also related to activities in the CA Browser Forum where
they put  down requirements on responders complying with CAB rules
to not
respond
"good" to certificates that were never issued.
With this update in OCSP, they can now mandate in their policies
both the  fact that their responders MUST know if a certificate was
never
issued
and
MUST respond "revoked".

So we allow other communities to raise the bar even if the base
standard
defines the response as optional.

In theory we could possibly say that responding revoked is
optional,
but
if you choose between revoked and unknown then you SHOULD favour
revoked
over unknown. But such nested requirements just feels bad and
impossible
to test compliance against. I'd much rather just leave it
optional. I think the Note gives a clear recommendation on this
and the rationale without spelling it out as a requirement.

Does this answer your question?


On 3/27/13 12:51 AM, "Black, David" 
<david(_dot_)black(_at_)emc(_dot_)com> wrote:

Hi Stefan,

This looks good - thank you for the prompt response.

It looks like my speculation on item [1] was wrong, so could you
respond
to the question below, please?:

[1] Section 2.2:

      NOTE: The "revoked" state for known non-issued
certificate serial
              numbers is allowed in order to reduce the risk
of
relying
              parties using CRLs as a fall back mechanism,
which would be
              considerably higher if an "unknown" response
was
returned.

Given this explanation, I'm surprised that the use of "revoked"
instead of
"unknown" for a known non-issued certificate is a "MAY"
requirement
and
not a "SHOULD" requirement.  Why is that the case?

--------------

Beyond that, the proposed actions (or proposed non-actions) on
items [2]-[5] are fine with me, Sean's taken care of the author
permissions item
from
idnits, and I assume someone has or will check the ASN.1 .

Thanks,
--David

-----Original Message-----
From: Stefan Santesson [mailto:stefan(_at_)aaa-sec(_dot_)com]
Sent: Monday, March 25, 2013 10:21 PM
To: Black, David; sts(_at_)aaa-sec(_dot_)com; 
mmyers(_at_)fastq(_dot_)com;
ambarish(_at_)gmail(_dot_)com;
slava(_dot_)galperin(_at_)gmail(_dot_)com; 
cadams(_at_)eecs(_dot_)uottawa(_dot_)ca;
gen-art(_at_)ietf(_dot_)org
Cc: pkix(_at_)ietf(_dot_)org; Sean Turner; ietf(_at_)ietf(_dot_)org
Subject: Re: Gen-ART review of draft-ietf-pkix-rfc2560bis-15

Hi David,

Thanks for the review.
My reply in line.

On 3/26/13 1:25 AM, "Black, David" 
<david(_dot_)black(_at_)emc(_dot_)com> wrote:

Authors,

I am the assigned Gen-ART reviewer for this draft. For
background on
Gen-ART, please
see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call
comments
you
may receive.

Document: draft-ietf-pkix-rfc2560bis-15
Reviewer: David L. Black
Review Date: March 25, 2013
IETF LC End Date: March 27, 2013

Summary:
This draft is on the right track but has open issues,
described
in
the
review.

This draft updates the OCSP protocol for obtaining certificate
status
with some minor extensions.

Because this is a "bis" draft, I reviewed the diffs against
RFC
2560.

I did not check the ASN.1.  I also did not see a writeup for
this
draft
in the data tracker, and so will rely on the document shepherd
to ensure that the ASN.1 has been checked when the writeup is
prepared.

I found five open issues, all of which are minor, plus one
idnits
item
that is probably ok, but should be double-checked.

Minor issues:

[1] Section 2.2:

      NOTE: The "revoked" state for known non-issued
certificate serial
              numbers is allowed in order to reduce the risk
of
relying
              parties using CRLs as a fall back mechanism,
which would be
              considerably higher if an "unknown" response
was
returned.

Given this explanation, I'm surprised that the use of "revoked"
instead of
"unknown" for a known non-issued certificate is a "MAY"
requirement
and
not a "SHOULD" requirement.  Why is that the case?

It appears that the reason is that the use of "revoked" in
this
situation
may be dangerous when serial numbers can be predicted for
certificates
that
will be issued in the future.  If that's what's going on, this
concern
is
already explained in the security considerations section, but
it
should
also be mentioned here for completeness.

No, this is not the main reason. The main reason is the one
stated
as a
Note: in this section:

NOTE: The "revoked" state for known non-issued certificate
serial numbers  is allowed in order to reduce the risk of
relying parties using
CRLs
as
a
fall back mechanism, which would be considerably higher if an
"unknown"
response was returned.



[2] Section 4.2.2.2:

      The key that signs a certificate's status information
need not be
the
      same key that signed the certificate. It is necessary
however to
      ensure that the entity signing this information is
authorized to
do
      so.  Therefore, a certificate's issuer MAY either sign
the OCSP
      responses itself or it MAY explicitly designate this
authority to
      another entity.

The two instances of "MAY" in the above text were both "MUST"
in
RFC
2560.

The RFC 2560 text construction of "MUST" or "MUST" is a bit
odd,
but
the two
"MAY"s in this draft are even worse, as they allow "MAY do
something
else
entirely", despite being enclosed in an either-or construct.
I
strongly
suspect that the latter was not intended, so the following
would
be
clearer:

      The key that signs a certificate's status information
need not be
the
      same key that signed the certificate. It is necessary
however to
      ensure that the entity signing this information is
authorized to
do
      so.  Therefore, a certificate's issuer MUST do one of
the
following:
              - sign the OCSP responses itself, or
              - explicitly designate this authority to
another
entity.


I Agree. I will adopt your text.


[3] Section 4.3:

Is the "SHOULD" requirement still appropriate for the DSA with
SHA-1
combo
(vs. a "MAY" requirement)?  This requirement was a "MUST" in
RFC
2560,
but
I wonder about actual usage of DSA in practice.

The change in algorithm requirements was provided by RFC 6277,
and further  refined in this draft in accordance with requests
from Sean
Turner.


[4] Section 5, last paragraph:

      Responding a "revoked" state to certificate that has
never been
      issued may enable someone to obtain a revocation
response
for a
      certificate that is not yet issued, but soon will be
issued, if
the
      CA issues certificates using sequential certificate
serial number
      assignment.

The above text after starting with the "if" is too narrow - it
should
say:

      if the certificate serial number of the certificate that
      will be issued can be predicted or guessed by the
requester.
      Such prediction is easy for a CA that issues certificates
      using sequential certificate serial number assignment.

There's also a nit in original text - its first line should be:

      Responding with a "revoked" state for a certificate
that
has never
been

Good suggestions. I will update accordingly.


[5] Section 5.1.1:

      In archival applications it is quite possible that an
OCSP
responder
      might be asked to report the validity of a certificate
on
a date
in
      the distant past. Such a certificate might employ a
signing method
      that is no longer considered acceptably secure. In such
      circumstances the responder MUST NOT generate a
signature
using a
      signing mechanism that is not considered acceptably
secure.

This could use an additional warning that certificate archival
should
not rely solely on signatures in archived certificates for
ensuring
the
validity and integrity of the archived certificates because
the
signature
algorithm(s) may transition to no longer being considered
acceptably
secure at some point after the certificates are archived.

This note if I remember correctly is imported from RFC 6277,
which is
incorporated into this document. The reason behind the text is
only
to
avoid usages of insecure algorithms.
Historical validation is a real can of worms that I really
would
like to
keep a tight lid on. I really want to avoid doing
recommendations
in
this
space as it may trigger a whole flood of things that could be
equally
important to say about this subject.


Nits:

idnits 2.12.15 said:

 -- The document seems to lack a disclaimer for pre-RFC5378
work,
but
may
    have content which was first submitted before 10 November
2008.
If
you
    have contacted all the original authors and they are all
willing
to
grant
    the BCP78 rights to the IETF Trust, then this is fine,
and
you
can
ignore
    this comment.  If not, you may need to add the
pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    http://trustee.ietf.org/license-info for more
information.)

This looks like it's ok because all the authors of RFC 2560
are
also
authors of
this draft, but it should be double-checked.


I defer this one to Sean. I think he has this one under control.


Thanks again for the review.

/Stefan



Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer EMC Corporation, 176
South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david(_dot_)black(_at_)emc(_dot_)com        Mobile: +1 (978) 
394-7754
----------------------------------------------------