Subject: [sidr] Subject naming in the RPKI

From: "David A. Cooper" <[email-masked]>
Date: Wed, 14 Jul 2010 17:03:03 -0400

All,

The current RPKI documents (draft-ietf-sidr-res-certs, 
draft-ietf-sidr-cp, draft-ietf-sidr-cps-irs, draft-ietf-sidr-cps-isp, 
draft-ietf-sidr-arch) require that subject names in certificates be 
unique relative to all certificates issued by a given CA, but does not 
require that subject names be issued in a manner that would make it 
likely that subject names are globally unique (i.e., unique across the 
entire RPKI).

While it is true that there is less of a need for names to be unique 
across the RPKI than there is other other PKIs (since the RPKI does not 
use such things as name constraints, indirect CRLs, or attribute 
certificates), the existence of name collisions within the RPKI would 
not be without risk.  In particular, there is no requirement in X.509 
that the CRL used to determine the revocation status of a certificate be 
signed using the same key as the certificate.  Using the X.509 (and RFC 
5280) path validation rules, a CRL may be validated using an entirely 
different certification path than the certificate whose status is being 
checked.  If a path validation implementation does this, and there are 
two different CAs within the PKI that operate under the same name, then 
the library may use the CRL issued by one of the CAs to determine the 
status of certificates issued by the other CA.  This could lead to a 
revoked certificate being accepted as valid or a valid certificate being 
rejected as revoked.

It is my understanding that some current path validation implementations 
that are being developed for use with the RPKI make use of the OpenSSL 
path validation libraries.  At the moment, OpenSSL will not by default 
will not use a separate certification path to validate a CRL than was 
used to validate the certificate whose status is being checked, but the 
latest version of OpenSSL (1.0.0) does have that capability.  One of the 
changes that is mentioned for OpenSSL 1.0.0 is:

   *) Add support for distinct certificate and CRL paths. The CRL issuer
      certificate is validated separately in this case. Only enabled if
      an extended CRL support flag is set: this flag will enable additional
      CRL functionality in future.

If a future version of OpenSSL enables this feature by default, and that 
version of OpenSSL is used to validate certificates in the RPKI, and 
there are name collisions in the RPKI, then relying parties will be at 
risk of incorrectly accepting or rejecting certificates.

I understand that there is a desire to keep subject names within the 
RPKI simple and that the RPKI cannot impose a centralized or 
hierarchical naming structure to ensure that there are no name 
collisions.  However, with a very small change to the RPKI 
specifications, one could maintain a simple naming scheme while making 
the risk of name collisions negligible.

The current RPKI specification states that a subject name consists of a 
commonName attribute and optionally a serialNumber attribute.  However, 
there was some discussion recently about whether the specification could 
be changed to require that the subject name contain only a commonName 
attribute.  So, I will present examples of ways in which unambiguous 
names could be constructed that only include a commonName attribute.  
The idea is to include enough randomness in the name so that name 
collisions are unlikely.  According to the Birthday Paradox, if there 
are about one million (2^20) CAs in the RPKI, then collisions will be 
unlikely if there is significantly more than 40 bits of entropy in the 
name.  Some ways to achieve this would be:

1) Hash of the subject public key (encoded as ASCII HEX).
     example: cn="999d99d564de366a29cd8468c45ede1848e2cc14"

2) A Universally Unique IDentifier (UUID) - RFC 4122
     example: cn="6437d442-6fb5-49ba-bbdb-19c260652098"

3) A randomly generated ASCII HEX encoded string:
    example: cn="0f8fcc28e3be4869bc5f8fa114db05e1"
    (A string of 20 ASCII HEX digits would have 80-bits of entropy)

4) An internal database key or subscriber ID combined with one of the above
     example:  cn="<DBkey1> (6437d442-6fb5-49ba-bbdb-19c2606520980)"
    (The issuing CA may wish to be able to extract the database key or 
subscriber
    ID from the commonName.  Since only the issuing CA would need to be 
able to
    parse the commonName, the database key and the source of entropy
    (e.g., a UUID) could be separated in any way that the CA wanted, as 
long as
    it conformed to the rules for PrintableString.  The separator could 
be a space
    character, parenthesis, hyphen, slash, question mark, etc.  Of 
course, the
    source of entropy could also be placed in a separate attribute, if 
the profile
    permitted that.)

   If the internal database key or subscriber ID contained enough entropy by
   itself, then it may not be necessary to include anything else in the 
commonName
   attribute.

Of course, even if the RPKI documents required CAs to create subject 
names as described above, there is a risk that some CAs in the RPKI 
would not follow these rules and would accidentally (or deliberately) 
create name collisions.  This problem could be mitigated, however, given 
the way that certificates and CRLs are issued in the RPKI.  Unlike X.509 
in general, the RPKI requires that the CRL that provides the revocation 
status of a certificate be signed using the same key as the 
corresponding certificate.  The RPKI could take advantage of that by 
adding a step to the path validation algorithm (Step 5 in Section 7.2 of 
draft-ietf-sidr-res-certs) requiring the relying party to verify the 
signature on the CRL used to determine whether the certificate was 
revoked using the same public key as was used to verify the signature on 
the certificate itself.  At the moment, the RPKI path validation 
algorithm does not impose such a requirement.

It may also be a good idea to add a paragraph to the Security 
Considerations section noting that there may be a risk in using a path 
validation implementation that is capable of using separate 
certification paths for a certificate and the corresponding CRL if there 
are name collisions in the RPKI as a result of CAs not following the 
profiles requirements for constructing subject names.

This would result in a belts-and-suspenders approach.  Specifying naming 
rules that will make name collisions unlikely will increase the 
likelihood that relying parties can safely use any X.509 path validation 
implementation that has added support for the RFC 3779 extensions.  
Imposing a path validation requirement to only use CRLs that were signed 
using the same key as the certificate will encourage relying parties to 
use path validation software that will be at less risk of getting 
incorrect certificate validation results even if there are name 
collisions in the RPKI as as result of some CAs not complying with the 
naming rules.

Dave

---

From: Roque Gagliano <[email-masked]>
Date: Tue, 20 Jul 2010 22:43:07 +0200

Hi David,

Isn't this problem prevented by the requirement of including the AKI extension in all CRLs as expressed in section 5.7.1 of  draft-ietf-sidr-res-certs-18? 

Regards,
Roque.

----------------------------------------------------------------------------------------------------------------------------------------------
Roque Gagliano			                               					Cisco Systems International Sàrl	
Software Engineer										Mailstop ROL01/2/
Corporate Development  Technology Group					Avenue des Uttins 5
														1180 Rolle
[email-masked]										Switzerland
Phone: +41 21 823 2805									

For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html

On Jul 14, 2010, at 11:03 PM, David A. Cooper wrote:

> All,
> 
> The current RPKI documents (draft-ietf-sidr-res-certs, draft-ietf-sidr-cp, draft-ietf-sidr-cps-irs, draft-ietf-sidr-cps-isp, draft-ietf-sidr-arch) require that subject names in certificates be unique relative to all certificates issued by a given CA, but does not require that subject names be issued in a manner that would make it likely that subject names are globally unique (i.e., unique across the entire RPKI).
> 
> While it is true that there is less of a need for names to be unique across the RPKI than there is other other PKIs (since the RPKI does not use such things as name constraints, indirect CRLs, or attribute certificates), the existence of name collisions within the RPKI would not be without risk.  In particular, there is no requirement in X.509 that the CRL used to determine the revocation status of a certificate be signed using the same key as the certificate.  Using the X.509 (and RFC 5280) path validation rules, a CRL may be validated using an entirely different certification path than the certificate whose status is being checked.  If a path validation implementation does this, and there are two different CAs within the PKI that operate under the same name, then the library may use the CRL issued by one of the CAs to determine the status of certificates issued by the other CA.  This could lead to a revoked certificate being accepted as valid or a valid certificate being rejected as revoked.
> 
> It is my understanding that some current path validation implementations that are being developed for use with the RPKI make use of the OpenSSL path validation libraries.  At the moment, OpenSSL will not by default will not use a separate certification path to validate a CRL than was used to validate the certificate whose status is being checked, but the latest version of OpenSSL (1.0.0) does have that capability.  One of the changes that is mentioned for OpenSSL 1.0.0 is:
> 
> If a future version of OpenSSL enables this feature by default, and that version of OpenSSL is used to validate certificates in the RPKI, and there are name collisions in the RPKI, then relying parties will be at risk of incorrectly accepting or rejecting certificates.
> 
> I understand that there is a desire to keep subject names within the RPKI simple and that the RPKI cannot impose a centralized or hierarchical naming structure to ensure that there are no name collisions.  However, with a very small change to the RPKI specifications, one could maintain a simple naming scheme while making the risk of name collisions negligible.
> 
> The current RPKI specification states that a subject name consists of a commonName attribute and optionally a serialNumber attribute.  However, there was some discussion recently about whether the specification could be changed to require that the subject name contain only a commonName attribute.  So, I will present examples of ways in which unambiguous names could be constructed that only include a commonName attribute.  The idea is to include enough randomness in the name so that name collisions are unlikely.  According to the Birthday Paradox, if there are about one million (2^20) CAs in the RPKI, then collisions will be unlikely if there is significantly more than 40 bits of entropy in the name.  Some ways to achieve this would be:
> 
>  (The issuing CA may wish to be able to extract the database key or subscriber
>  ID from the commonName.  Since only the issuing CA would need to be able to
>  (e.g., a UUID) could be separated in any way that the CA wanted, as long as
>  it conformed to the rules for PrintableString.  The separator could be a space
>  character, parenthesis, hyphen, slash, question mark, etc.  Of course, the
>  source of entropy could also be placed in a separate attribute, if the profile
>  permitted that.)
> 
> itself, then it may not be necessary to include anything else in the commonName
> attribute.
> 
> 
> Of course, even if the RPKI documents required CAs to create subject names as described above, there is a risk that some CAs in the RPKI would not follow these rules and would accidentally (or deliberately) create name collisions.  This problem could be mitigated, however, given the way that certificates and CRLs are issued in the RPKI.  Unlike X.509 in general, the RPKI requires that the CRL that provides the revocation status of a certificate be signed using the same key as the corresponding certificate.  The RPKI could take advantage of that by adding a step to the path validation algorithm (Step 5 in Section 7.2 of draft-ietf-sidr-res-certs) requiring the relying party to verify the signature on the CRL used to determine whether the certificate was revoked using the same public key as was used to verify the signature on the certificate itself.  At the moment, the RPKI path validation algorithm does not impose such a requirement.
> 
> It may also be a good idea to add a paragraph to the Security Considerations section noting that there may be a risk in using a path validation implementation that is capable of using separate certification paths for a certificate and the corresponding CRL if there are name collisions in the RPKI as a result of CAs not following the profiles requirements for constructing subject names.
> 
> This would result in a belts-and-suspenders approach.  Specifying naming rules that will make name collisions unlikely will increase the likelihood that relying parties can safely use any X.509 path validation implementation that has added support for the RFC 3779 extensions.  Imposing a path validation requirement to only use CRLs that were signed using the same key as the certificate will encourage relying parties to use path validation software that will be at less risk of getting incorrect certificate validation results even if there are name collisions in the RPKI as as result of some CAs not complying with the naming rules.
> 
> Dave
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 20 Jul 2010 18:09:01 -0400

No.  Key identifiers are not used in path validation.  The AKI extension 
in a CRL provides a hint as to which key was used to sign the CRL, but 
when determining the status of a certificate, there is no requirement in 
X.509 to use a CRL that was signed using the same key as the certificate.

If the issuer of the CRL has multiple keys, the AKI may help the client 
more quickly determine which certificate has the key needed to verify 
the signature on the CRL.  But if two different entities within the RPKI 
are issuing certificates and CRLs under the same name, the AKI extension 
will do nothing to prevent a relying party from using a CRL issued by 
one of these entities to determine the status of a certificate issued by 
the other entity.

As I noted, the path validation algorithm in Section 7.2 of 
draft-ietf-sidr-res-certs could impose a requirement to only use a CRL 
that was signed using the same key as the certificate whose revocation 
status is being checked.  I believe that if a client performed such a 
check it would avoid the problem.  However, I believe that it would be 
risky for the RPKI to solely rely on the imposition of such as check.  
This would be effectively creating a situation in which using 
X.509-compliant path validation software to validate X.509 certificates 
in the RPKI would be a security risk.

One needs to assume that path validation software that is being 
developed for the RPKI will not be used only to perform path validation 
within the RPKI.  A statement in one of the SIDR RFCs indicating that 
there are different rules for performing path validation within the RPKI 
than in a generic X.509 PKI may not be noticed by developers who are 
working on revising general-purpose path validation software that just 
happens to include support for the RFC 3779.  Even a warning in the 
Security Considerations section of one of the SIDR RFCs that the RPKI 
does not comply with X.509 and that there may be security risks 
associated with using path validation software that is not RPKI-specific 
would likely not be noticed.

OpenSSL, for example, is a general purpose path validation library that 
has added support for the RFC 3779 extensions.  OpenSSL already has the 
capability to validate a CRL using a different certification path than 
the one used to validate the corresponding certificate, as is permitted 
by X.509.  Several years from now, the developers of that code may 
decide to enable this feature by default.  They would be unlikely to be 
reading through the SIDR RFCs at the time they made this decision.  RPKI 
clients that use the OpenSSL implementation would eventually begin to 
use this updated version and then things would begin to stop working 
correctly.

Given that this problem could easily be avoided, I can't see any reason 
to create unnecessary problems.

Dave

---

From: Rob Austein <[email-masked]>
Date: Tue, 20 Jul 2010 20:07:13 -0400

FWIW, at least one implementation (mine) already generates subject
names containing a SHA-1 hash of the public key (ie, another encoding
of the same value we're already using as the SKI).  I'll let the other
implementors speak to whether their implementations already do
something like this, or how hard it would be to add if needed.

I'd have no particular objection to specifying that the relying party
should check whether the CRL and the certificate being revoked were
signed by the same key, probably by comparing the AKI values, thus
doing approximately what Roque thought we were doing already. :)

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Jul 2010 21:14:42 -0400

At 10:43 PM +0200 7/20/10, Roque Gagliano wrote:
>Content-Type: multipart/signed; boundary=Apple-Mail-229-703677170; 
>protocol="application/pkcs7-signature"; micalg=sha1
>
>Hi David,
>
>Isn't this problem prevented by the requirement of including the AKI 
>extension in all CRLs as expressed in section 5.7.1 of 
>draft-ietf-sidr-res-certs-18?
>
>
>Regards,
>Roque.

Roque,

i think other text in the resource cert profile also addresses this. 
Specifically, 4.9.6 says that:

    In this profile the certificate Issuer is also the CRL Issuer,
    implying that the CRLIssuer field MUST be omitted, and the
    distributionPoint field MUST be present.  The Reasons field MUST be
    omitted.

The profile makes no provision for a separate cert issued by the CA 
to be used for CRL validation (unlike the general case of 5280). Thus 
RPs ought to require that the key used to verify a cert is the same 
key used to verify the CRL. It will be easy to add that requirement 
to this document.

I agree that the AKI extension, if checked during validation, 
provides an additional binding to the CA's key.  However, David would 
note that 5280 does not call for checking the AKI during path 
validation, so the check that one might envision here need not be 
performed. I would observe that if one used the AKI for path 
construction, especially during key rollover, then an RP would be 
lead to the right cert.

I also note that the profile calls for inclusion of a URI in the 
CRLDP and in the IDP of the CRL.  Since these URIs are globally 
unique publication points, no "accidental" name collisions in CAs 
will cause confusion re picking the right CRL to use. To avoid 
secruity problems in the face of a malicious CA name reuse, the only 
safe solution appears to be mandating a check that the key used to 
verify the cert is the same key used to verify the CRL.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 21 Jul 2010 09:27:13 -0400

Steve,

draft-ietf-sidr-res-certs-18 only calls for two CRL extensions:
authorityKeyIdentifier and cRLNumber.  But even if it did call for
inclusion of an issuingDistributionPoint extension, what is the
compelling reason to mandate that the RPKI be designed in a manner that
is not X.509-compliant?  Why take that risk when the problem could so
easily be avoided?

Dave

On 07/20/2010 09:14 PM, Stephen Kent wrote:

I also note that the profile calls for
inclusion of a URI in the CRLDP and in the IDP of the CRL.  Since
these URIs are globally unique publication points, no
"accidental" name collisions in CAs will cause confusion re
picking the right CRL to use. To avoid secruity problems in the face
of a malicious CA name reuse, the only safe solution appears to be
mandating a check that the key used to verify the cert is the same key
used to verify the CRL.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 Jul 2010 07:13:57 -0400

At 9:27 AM -0400 7/21/10, David A. Cooper wrote:
>compelling reason to mandate that the RPKI be designed in a manner 
>that is not X.509-compliant?  Why take that risk when the problem 
>could so easily be avoided?

You are right about the RPKI CRL extensions; I misread the CRLDP text.

We disagree on your notion of what is and is not X.509 compliant, and 
further discussion here is not likely to change that.

Nonetehless, the fundamental issue here is that an assumption of name 
uniqueness for CAs in a PKI cannot be a viable basis for security. 
Even if a PKI "mandates" such uniqueness, the mandate cannot be 
enforced in the face of a malicious CA, since that CA can generate a 
subordinate CA with any name it wishes. The RPKI will have about 30K 
CAs, distributed around the world.  Some will be in countries where, 
today, local authorities fail to address well-documented, repeated 
incidents of "bad" Internet behavior by identified actors.  Thus it 
would be unwise to have the security of the RPKI rest on the 
assumption of CA name uniqueness.

The security requirement for CRLs in the RPKI is that the key used to 
verify the CRL has to be the same as the key used to verify certs 
issued by the CA in question. Adding the CRDLP URI to the CRL would 
minimize the likelihood of a non-malicious name collision, but it is 
not a secure basis for deciding whether an RP is using the "right" 
CRL.

Steve

---

From: Tim Bruijnzeels <[email-masked]>
Date: Thu, 22 Jul 2010 14:20:45 +0200

> something like this, or how hard it would be to add if needed.

As another implementor:
Our system uses the base64 encoded SHA-1 hash of the public key to
determine the subject name for a certificate. We are using the same
strategy for subject names, as is currently proposed to determine file
names as described here:
http://tools.ietf.org/html/draft-ietf-sidr-repos-struct-04#section-2.2

There is one exception to this. For our TAs we felt is might be better
to use human readable subjects and filenames for now:
ETA:	rsync://certrepo.ripe.net/eta/CN=ETA,O=RIPE%20NCC,C=NL.cer
RTA:	rsync://certrepo.ripe.net/rta/CN=RTA,O=RIPE%20NCC,C=NL.cer

Regards,

Tim

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 22 Jul 2010 14:41:25 +0200

hi Stephen,

> 
> The security requirement for CRLs in the RPKI is that the key used to verify the CRL has to be the same as the key used to verify certs issued by the CA in question. Adding the CRDLP URI to the CRL would minimize the likelihood of a non-malicious name collision, but it is not a secure basis for deciding whether an RP is using the "right" CRL.
> 

In order to verify this point, do you agree in adding the AKI check on the certificate validation section to certified that the cert and the CRL were signed by the same key? 

I believe it is the most reasonable suggestion on the table.

Roque.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 22 Jul 2010 16:11:43 -0400

Geoff, George, Robert,

The current version of draft-ietf-sidr-res-certs contains a number of
contradictions with respect to naming that need to be addressed.  While
the introduction says that "Resource Certificates are X.509
certificates that conform to the PKIX profile [RFC5280]", this is not
the case.  draft-ietf-sidr-res-certs-18 specifically states that names
do not have to be globally unique, and via reference to
draft-ietf-sidr-arch actually encourages the use of names that are not
unique (draft-ietf-sidr-arch suggests the use of internal database keys
or subscriber IDs as subject names).

X.509 mandates that names be globally unique:

NOTE 1 – Although the CAs are unambiguously
defined by a distinguished name in the DIT, this does not imply that
there is any relationship between the organization of the CAs and the
DIT.

The directory names used in X.509 are defined in X.501:

9.1.4 (directory) name: A construct that
singles out a
particular object from all other objects. A name shall be unambiguous
(that is, denote just one object); however, it need not be unique (that
is, be the only name which unambiguously denotes the object).

9.2 Names in general: A (directory) name is a
construct that identifies a
particular
object from among the set of all objects. A name shall be unambiguous,
that is, denotes just one object.

X.509 uses names for many purposes, including determining the scope of
a CRL.  In X.509, the neither the key used to sign the CRL nor the
location of a CRL in a directory nor the value of the CRLDP extension
in a certificate affect the scope of the CRL.  While some may believe
this was a bad (and potentially dangerous)
design decision, we need to acknowledge what is, rather than treating
X.509 as if it were designed in the way we wish it had been.  There are
lots of X.509 path validation libraries, including OpenSSL, that are
capable of working with certificates and CRLs that were signed using
different keys, and that cannot be simply ignored.

draft-ietf-sidr-res-certs-18 incorrectly states that names can't be
globally unique within the RPKI since CAs can't coordinate unique
subject names, this is not the case.  As I have demonstrated
(http://www.ietf.org/mail-archive/web/sidr/current/msg01739.html), if
the profiles required the inclusion of some randomness in the names,
this would effectively ensure name uniqueness without requiring any
coordination.  Even if there is a risk that there will be "malicious
CAs" in the RPKI that won't following the naming rules, that isn't
justification for not having them.  After all, the SIDR WG is
developing certificate profiles, certificate policies (CP), and
certification practice statements (CPS), even though if there are any
"malicious CAs" in the RPKI, they will not follow the requirements in
these documents as well.

While it would be unnecessarily risky to intentionally develop an RPKI
in such a way that standard X.509 path validation software (e.g.,
OpenSSL) cannot be safely used to validate certification paths within
the RPKI, that does not mean that the SIDR documents cannot encourage
the use of path validation software that takes a more restrictive
approach to path validation than is allowed by X.509.  Adding a
requirement in the path validation section of draft-ietf-sidr-res-certs
to only use a CRL that was signed using the same key as the
corresponding certificate would fall into this category.  This would be
a new requirement, and not an unreasonable one given that it is
consistent with the way that CAs are required to issue CRLs.

X.509 was not, in general, designed with the consideration that a PKI
might include "malicious CAs".  CAs are considered to be trusted
entities.  A relying party makes a decision to accept one or more CAs
as trust anchors, and trusts that these CAs will not act in a malicious
manner.  In turn these CAs are expected to only issue CA certificates
to CAs that can be trusted, and so on.  If a CA suspects that a CA to
which it has issued a cross-certificate is misbehaving, it would revoke
the cross-certificate, effectively removing the misbehaving CA from the
PKI.  X.509 does define constraint extensions (name constraints, path
length constraints, policy constraints, etc.) that can limit the degree
to which a CA is trusted and thus mitigate the effects of any
"misbehavior", but the RPKI does not take advantage of these extensions.

If the SIDR WG believes that the RPKI may include "malicious CAs" that
cannot be excluded from the PKI, then that is really something that
needs to be covered in the Security Considerations section.  If there
is a serious risk that "malicious CAs" that cannot be excluded from the
PKI will issue certificates to subordinate CAs under the same name as a
"non-malicious CA", then the Security Considerations section needs to
say that and explain the implications.  In particular, it needs to
point out that:

1) X.509 does not require the CRL used to determine the status of a
certificate be signed using the same key as the corresponding
certificate, and there are many path validation libraries available
that will use a CRL signed to one key to determine the status of a
certificate signed using a different key.

2) A "malicious CA" could create a subordinate CA with the same name as
a "non-malicious CA" and then have that subordinate CA issue CRLs that
either make it appear that revoked certificates have not been revoked
or that valid certificates have been revoked.

3) Clients can protect against being tricked by such CA into using the
wrong CRL by only using a CRL to determine the status of a certificate
if the CRL and certificate were signed using the same key.

Without warnings such as this being prominently placed within the SIDR
documents, even someone who carefully reads through the SIDR documents
may not understand that the RPKI is "different" from other X.509 PKIs,
and that there may be security risks to using just any X.509 path
validation library that implements the RFC 3779 certificate
extensions.  Of course, not everyone validating paths within the RPKI
will carefully read these documents, which is why it is important for
the profile to not encourage "non-malicious CAs" to assign names in a
manner that would unintentionally create the same problems that some
are worried that "malicious CA" will intentionally create.

We have already heard from implementers that are using the hash of the
subject public key as the subject name, and haven't heard from any who
have argued that it would be unacceptable to ask them to satisfy the
X.509 requirement to create names that are unambiguous across the RPKI,
so it shouldn't be a problem for the profile to impose that as a
requirement, while including a few examples of naming schemes that CAs
could use that would satisfy the requirement.

Dave

On 07/22/2010 07:13 AM, Stephen Kent wrote:

Steve,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Jul 2010 10:59:24 -0400

At 2:41 PM +0200 7/22/10, Roque Gagliano wrote:
>hi Stephen,
>
>>
>>  The security requirement for CRLs in the RPKI is that the key used 
>>to verify the CRL has to be the same as the key used to verify 
>>certs issued by the CA in question. Adding the CRDLP URI to the CRL 
>>would minimize the likelihood of a non-malicious name collision, 
>>but it is not a secure basis for deciding whether an RP is using 
>>the "right" CRL.
>>
>
>In order to verify this point, do you agree in adding the AKI check 
>on the certificate validation section to certified that the cert and 
>the CRL were signed by the same key?
>

Roque,

As David has noted, the normal (5280) validation process does not 
call for such checks. Also, one would really have two checks here; 
one for verify that the AKI is a hash of the public key, and one to 
match the AKI/SKI in the certs.

It might just be better to expand on the text in 4.9.6 to remind RPs 
that the CA is the CRL issuer and thus the same public key MUSt be 
used to verify a cert and the CRL being checked for that cert.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 29 Jul 2010 08:36:49 -0400

David,

Even though your message did not include me in the salutation, it was 
a reply to my message, so I'll take the liberty of replying.

I think the techniques you proposed for generating Subject names that 
are unlikely to collide in a non-malicious context are good 
suggestions.  If the Wg agrees, we could add these suggestions to one 
of the SIDR docs, as recommend (not mandated) name generation 
techniques.

However, as I have explained previously, we cannot assume that there 
will be no malicious name collisions, given the extent and the nature 
of the RPKI. Thus we need to adopt defensive strategies, based on 
crypto-validation of bindings, not just names. Because the RPKI 
requires each CA to directly issue CRLs, its not hard to verify this 
binding.

I agree that it is generally desirable to impose validation criteria 
that is well-supported by extant tools like OpenSSL. However, I would 
not make compatibility with that software dictate what we do. This is 
especially true given that we have seen OpenSSL deviate from PKIX 
standards in many ways over the years.

Steve