Re: Security section of draft-ietf-pkix-opp-ftp-http

[Marc Branchaud <marcnarc@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----

Content-Type: text/plain; charset=us-ascii


"Bob Jueneman" <BJUENEMAN@novell.com> scrawled:
> 
> Michael, I'm not entirely sure I agree with your semantics. 
> Maybe I've missed something, but I always interpreted 
> the traditional CRL nextUpdate semantics to mean "if you 
> haven't gotten an new CRL by this time, you are potentially 
> missing something", not "I'm not going to have another 
> word to say on this subject until this time, even if the world 
> is about to come to an end."
> 
> In other words, I believe that a CA (at least some CAs) 
> would feel that they are allowed, and perhaps even 
> compelled, to issue a CRL PRIOR to the time of the 
> nextUpdate, especially in the event of a known key 
> compromise. Certainly I would take my business elsewhere 
> if a CA or repository would not provide me that service.
> 
> I haven't followed the OCSP discussion that closely, 
> I'm afraid, but surely the semantics haven't changed
> all that much?
>
> bob
> 

I'd say that the semantics have never been too clear.  I even find the way
you've described them a bit confusing.  You say that a CRL's nextUpdate means
that "if you haven't gotten an new CRL by this time, you are potentially
missing something" but you also say that a CA should be allowed to issue a 
CRL prior to nextUpdate.

So, basically, regardless of whether nextUpdate has passed or not, an RP may 
potentially be missing something.  nextUpdate doesn't really tell the RP 
anything.

The best interpretation of nextUpdate I've seen is something I inferred from
a post David Kemp put up about a week ago.  He said that a CA needs a certain
amount of time to process a revocation, and it needs a way to relay that
revocation-lag information to RPs.

That kind of information is far more useful to RPs than some guesstimate 
about the frequency of CRL publishing.  nextUpdate might be used to carry 
that information.  It makes sense within OCSP to say "Here is the 
cartificate's status NOW, and if a revocation were to occur NOW it would 
take X seconds for it be processed."  So if an RP waited X seconds and did 
another check, it would know the cert's status at NOW.  Another way to think 
of it is "this was the cert's status X seconds ago."

For CRLs, though, making nextUpdate adopt these semantics only makes sense if
the CRLs are published at most every X seconds (and never sooner).  That is,
there would be no CRLs published until nextUpdate.  This is because the CRL
would be saying "These are the revoked certificates as of NOW and since it
takes me (the CA) X seconds to process a revocation there will be _no_
updates to this list until NOW + X."  That is, nextUpdate = NOW + X.

I think this is a new spin on CRLs.  If not, it certainly hasn't been clear
to me until now (and so I'd say that the standards have inadequately 
explained the issue).  The implication is that if a CA wants to be able to 
boast of a fast revocation response time, say 10 seconds, then it has to 
publish a CRL every 10 seconds (or use OCSP).

                Marc

+------------------------------------------------------------------------+
 Marc Branchaud                                  \/
 Chief PKI Architect                             /\CERT INTERNATIONAL INC.
 marcnarc@xcert.com        PKI References page:              www.xcert.com
 604-640-6227          www.xcert.com/~marcnarc/PKI/
+------------------------------------------------------------------------+
  PGP key fingerprint:  60 11 4B 9D 4E E5 2F 47  BD C5 C2 BF 26 DF 5A E1



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQB1AwUBNTzPklrdFXNdDxPlAQHoqQL5AaEfaxCA3Tjr9n717uhdi/27XEpqsO1f
IaKC01WDdBWNOD6IWmRRMW51g66NpNU8joMcvI7baiyEBwNhTlq3QW7ZtmDBlBPm
LYL7v4qoilyDvXdKD5vJru9CPEVZdvbi
=zmYR
-----END PGP SIGNATURE-----