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? > > (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 > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr Andrei _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
