Subject: [sidr] CRL management options

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Oct 2009 15:28:35 -0400

Folks,

At the RIPE meeting in Lisbon last week, there was some discussion 
about how relying parties (e.g. ISPs) might like to see reason codes 
used in the CRLs issued in the RPKI. The concern motivating this is a 
situation in which a CA (e.g., an RIR or an ISP) might be forced to 
revoke a cert for a customer because of some form of legal pressure, 
e.g., an effort to shut down a phishing site. The argument is that if 
an RIR were able to insert a reason code in the CRL entry for such a 
revocation, an ISP would be able to decide whether to accept or 
ignore the CRL entry in question. The relevant X,509 and PKIX 
standards allow for such a capability, but we removed it for the RPKI 
cert/CRL profile, because we didn't see a need for such codes.  The 
codes can be used on a per-CRL entry basis, so only when a cert is 
revoked for a reason that the AC elects to note would a code be 
inserted into the CRL entry for the revoked cert.

(As a side note, I made a brief presentation describing how cert 
validation software for the RPKI could offer RPs various options for 
dealing with expired and revoked certs, to address similar concerns. 
These options do not require any changes to the cert/CRL profile, but 
they also do not offer an automated capability for selective CRL 
entry processing.)

There are some costs associated with offering this option:

	- we make CRL processing more complex for all relying parties 
(relative to the current profile). the reason is that if we include 
this feature as part of the profile, ALL RPs MUST be prepared to 
process CRLs that make use of the feature. There is no requirement 
that ANY CA make use of the feature; it would be up to each CA and 
would be reflected in the CPS for the CA

	- it is not clear if law enforcement authorities would allow 
a CA (e.g., an RIR or an ISP) to mark a CRL in this fashion once they 
understood the potential implication. The CA could cite its CPS as 
mandating that it follow this procedure, as a defense of the 
practice, but who knows if this would suffice.

	- reason codes are defined by an ENUMERATED data type.  This 
means that there is a list of codes, each identified y an integer, 
and no provision for defining private reason codes. The list was 
motivated by the financial services industry, so there i no code that 
matches the notion of "the men in black made me do it." I note that 
the value "7" has no reason code assigned to it, but to use it for 
this purpose would be wrong :-).

So, before we ask Geoff to modify the Cert/CRL profile to allow for 
reasons codes, I'd like to get some sense of whether  the WG feels 
this is a reasonable path to follow.

Steve

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 20 Oct 2009 22:50:19 +0200

Steve,

Stephen Kent wrote on 15-10-2009 21:28:
> Folks,
> 
> At the RIPE meeting in Lisbon last week, there was some discussion about
> how relying parties (e.g. ISPs) might like to see reason codes used in
> the CRLs issued in the RPKI. The concern motivating this is a situation
> in which a CA (e.g., an RIR or an ISP) might be forced to revoke a cert
> for a customer because of some form of legal pressure, e.g., an effort
> to shut down a phishing site. The argument is that if an RIR were able
> to insert a reason code in the CRL entry for such a revocation, an ISP
> would be able to decide whether to accept or ignore the CRL entry in
> question. The relevant X,509 and PKIX standards allow for such a
> capability, but we removed it for the RPKI cert/CRL profile, because we
> didn't see a need for such codes.  The codes can be used on a per-CRL
> entry basis, so only when a cert is revoked for a reason that the AC
> elects to note would a code be inserted into the CRL entry for the
> revoked cert.
> 

I thing such feature may be useful as a general communication capability
of a CA to the RPs. Although maybe not exactly as a secret protocol
behind the LEAs backs :)

However, I don't think we should go ahead and modify the profile, mainly
for the reason that we won't be able to get it right at this point in
time. I don't think we can create realistic scenarios for usage of this
feature, and consistent interpretation of the reason codes is essential
(as opposed to per CA/CPS).

If we feel that we may not have enough time to introduce this feature
when needed, I am fine with reserving this in the profile, but providing
no guidance on how to process/interpret it (or rather advise not to
process the code).

Out of curiosity - how do the reason codes inform the validation process
in the conventional PKI?

> they also do not offer an automated capability for selective CRL entry
> processing.)
> 
> (relative to the current profile). the reason is that if we include this
> feature as part of the profile, ALL RPs MUST be prepared to process CRLs
> that make use of the feature. There is no requirement that ANY CA make
> use of the feature; it would be up to each CA and would be reflected in
> the CPS for the CA
> 
>     - it is not clear if law enforcement authorities would allow a CA
> (e.g., an RIR or an ISP) to mark a CRL in this fashion once they
> mandating that it follow this procedure, as a defense of the practice,
> but who knows if this would suffice.
> 
>     - reason codes are defined by an ENUMERATED data type.  This means
> that there is a list of codes, each identified y an integer, and no
> provision for defining private reason codes. The list was motivated by
> the financial services industry, so there i no code that matches the
> notion of "the men in black made me do it." I note that the value "7"
> has no reason code assigned to it, but to use it for this purpose would
> be wrong :-).
> 
> reasons codes, I'd like to get some sense of whether  the WG feels this
> is a reasonable path to follow.
> 
> Steve
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

Andrei

---

From: Rob Austein <[email-masked]>
Date: Fri, 23 Oct 2009 15:03:53 -0400

At Thu, 15 Oct 2009 15:28:35 -0400, Steve Kent wrote:
> ...

Another issue besides the one you listed: reason codes would further
complicate the software that has to generate all the certificates and
ROAs, perhaps significantly (haven't analyzed in detail yet).

Right now, we revoke certificates when resources shrink, when we're
rolling keys and want to kill off any certificates signed by the old
one, or when a child entity goes away.  The last case most closely
corresponds to the hypothetical situation in which you might want to
use these reason codes, but note that reason codes would change the
requirements: one would have to keep a tombstone for children that
have gone away, so that you know why, so that you know whether to use
a reason code and, if so what reason code to use.

Given this and the other problems you listed, I do not think it would
be productive to extend the CRL profile to allow reason codes, at
least not at this time.  I can see revisiting the issue after we have
some operational experience, but I see little value in opening this
can of worms at this time.