On 4/8/13 5:59 PM, Piyush Jain wrote:
Sean,
Thanks for your comments.
There are two points that I would like to cover separately. The first point
is a response to your comments below. The second point is a broader
objection to revoked for issued.
1) The text says - The "revoked" status is still optional in this context in
order to maintain backwards compatibility with deployments of RFC 2560.
This implies that making "revoked" status REQUIRED will break
interoperability between newer and older implementations. This is INCORRECT.
Using the word "compliance" might set of an entirely new debate.
Servers/clients can claim compliance if they want to but I'm not sure that
the
primary goal was for a document to claim compliance with another set of
RFCs.
These drafts for interoperability and that would lead me to
compatibility and not conformance.
That is fair. I was just pointing at the intent of the author. If you make
"revoked" status REQUIRED it does not break compatibility of newer
implementations with older implementations, however it does break
conformance of older implementations with RFC 5019 and 2560.
2) Returning revoked for non-issued adds confusion without addressing any
real problem. "Allowing CAs to return revoked for non-issued" is a goal that
is vague and meaningless, given that CAs indicate issuance by signing the
certificate in question with their private key. If you question this basic
premise of x.509 that issuance is determined by signature, you should
question the signature on signed response as well. Who is to say that the
responder certificate that was used to sign a good response was issued by
the CA?
Henry nicely articulated the whole issue with this draft in his post
(attached). I second his view on not moving this draft forward.
I went back and looked at the WG poll about this issue that you and lot
of other people participated in
(https://www.ietf.org/mail-archive/web/pkix/current/msg31906.html). The
WG's rough consensus was to allow "revoked" to be used for non-issued
certificates with the caveat thrown in by Paul Hoffman that the meaning
of "revoked" be clear about what it now means. I've not seen anything
that would make me want to throw this draft back to the WG to revisit
that consensus.
spt
-Piyush
-----Original Message-----
From: Sean Turner [mailto:turn...@ieca.com]
Sent: Monday, April 08, 2013 1:23 PM
To: Piyush Jain
Cc: ambar...@gmail.com; slava.galpe...@gmail.com;
cad...@eecs.uottawa.ca; 'Stefan Santesson'; 'Black, David'; sts@aaa-
sec.com; p...@ietf.org; gen-art@ietf.org
Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15
Piyush,
(David's on the "to:" line because the text in question showed up as a
result
of the gen-art review and it's now in -16)
I've been following this thread trying to figure out what if anything
needs to
be changed to address your concerns in -17. (Note the thread forked
later,
but I'm addressing the "times" issue in another thread.)
The sentence in questions was added to address the gen-art review is the
following (it's in a "note" paragraph and there's actually more to it):
The "revoked" status is still optional in this context in
order to maintain backwards compatibility with deployments
of RFC 2560.
1) The first bit I'd like to discuss is this part of your concern:
And it gives the impression that best course of action
for 2560bis responders is to start issuing revoked for
"not-issued", which is far from the originally stated
goal to provide a way for CAs to be able to return
revoked for such serial numbers.
and:
I believe that Stefan is trying to convey that requiring
servers to return revoked in this context will make them
non-compliant with 2560 and 5019 as opposed to breaking
interoperability with legacy clients.
I honestly don't see how you get to your impression, because the 2119
language about when a responder might used revoked for not-issued is:
This state MAY also be returned if the associated
CA has no record of ever having issued a certificate with the
certificate serial number in the request, using any current or
previous issuing key (referred to as a "non-issued" certificate in
this document).
MAY being the operable word here. That's clear to implementers because if
you read 2119 for MAY it says: This word, or the adjective "OPTIONAL",
mean that an item is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or because the vendor
feels
that it enhances the product while another vendor may omit the same item.
...
For me this seems clear because the 2119 language trumps any note.
Even Stefan's response to David a couple of days earlier than when you
posted this concerns includes:
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'm not sure what else could be added to alliveate your concern on this
point.
Maybe this one got over taken by events?
2) The second bit of your concern is that this is not an accurate
characterization of the WG's rationale for the choices made. This concern
is
easier to evaluate and I agree that it is important to capture the actual
rationale. I think you've suggested that the following:
"maintain backwards compatibility with deployments of RFC 2560"
be replaced with:
"maintain compliance with RFC 2560 and RFC 5019"
Using the word "compliance" might set of an entirely new debate.
Servers/clients can claim compliance if they want to but I'm not sure that
the
primary goal was for a document to claim compliance with another set of
RFCs. These drafts for interoperability and that would lead me to
compatibility and not conformance.
spt
On 4/3/13 1:38 PM, Piyush Jain wrote:
No, it does not make any sense at all. An error code is unsigned and
can
be
easily inserted into the communication by an attacker.
[Piyush] Funny that you make this argument. How does returning a
signed revoked address this? Attacker can still replace signed revoked
with an UNSIGNED TRY_LATER.
These kinds of argument are based on two very flawed premises:
(1) the premise that there exist only two possible states for a CA:
(a) safe and pristine
(b) full and thorough compromise of each and everything
[Piyush] NIST has addressed RA compromise and CA key compromise
separately so this is not true.
And you have not listed what other breaches you are trying to address
offering revoked for non-issued as the silver bullet for all those
unknown security breaches.
You tendency to allude to vague problems to justify a particular
solution, couple with a reluctance to engage in a discussion regarding
the security implications continues to amuse me. List the other states
and have a discussion around how this solution solves those problems.>
(2) that a huge PKI (100k+ entities) can be nuked and
re-personalized after a CA compromise at close to zero cost and
within the blink of an eye
and both premises exhibit a throrough cluelessness about security,
risk
management and the real world.
Let's get this right.
Only possible benefit of revoked for non-issued exists when there are
CA SIGNED certificates floating in the wild and CA has no clue that it
has issued it and therefore cannot revoke it.
Now, to say that clients are secure and CA can continue to operate if
it issues revoked OCSP response for such certificate indicates
cluelessness about security.
Customers pay a lot of money for certificates for which the marginal
cost of issuance is almost 0. CAs obligation is to make sure that they
are secure and to address any breach securely.
To say that customers will tolerate a CA security breach just because
it issues revoked for non-issued and continues to publish CRLs that
imply fraudulent certificates as good indicates cluelessness about
risk management and real world.
_______________________________________________
pkix mailing list
p...@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
