Subject: [pkix] Proposal for matching uniform resource identifiers with regular expressions in certificates

From: Sean Leonard <[email-masked]>
Date: Wed, 17 Mar 2010 11:28:22 -0700

Hello PKIX list:

I am working on a proposal to make URI matching possible using
certificates and other PKIX structures in a much more rigorous way. I
would like to solicit feedback to see what the level of interest is on
the list in this proposal, before finishing up a more formal I-D. The
proposal is to combine two great and well-tested technologies that are
already used together in the wild, URIs and regular expressions, and to
use regular expressions in certificates to match URIs. Jeffrey Schiller 
has helped me with formulating this proposal.

THE PROBLEM

PKIX artifacts (certificates, attribute certificates, etc.) are
frequently used to authenticate services and resources, but not all of
the actual names may be known in advance. URIs can be used at the
application level to identify resources, but while RFC 3986 provides
guidance on matching URIs, the equivalence rules
are either too strict or too nuanced for many applications. Furthermore,
wildcard characters, such as the ubiquitous * used in the dNSName or
Common Name of SSL/TLS, are permitted but not addressed by RFC 5280 (see
Section 4.2.1.6).

It is therefore desirable to define a uniform, consistent, and intuitive
way to perform pattern matching against URIs.
This proposal provides a such a matching mechanism using regular
expressions.

EXAMPLE CASE

For example, a regular expression that matches against an rsync URI (RFC
5781) by requiring:
     the scheme to be /^rsync$/,
     the host to be /^rsync\.example\.com$/, and
     the source path to be /^\/dailybackups\//
can be used to limit a public key certificate or attribute certificate
to the "dailybackups" resources of an rsync service at that hostname.

A DNS name does not adequately meet the need, but on the other hand, it
would be too burdensome to write out all of the possible URI
combinations. There are also case-sensitivity issues that are best
handled by the URI processor and by the certificate/artifact, where the
issuer has more information about how to treat uppercase and lowercase
characters.

This proposal has a similar intent to, but should be much better than,
wildcard matching in GeneralName/dNSName entries, also known as
"wildcard SSL certificates."

The main difference is that URIs are application-layer identifiers, and
accordingly an URI regular expression match is supposed to be performed
by application layer software, not at all by the cryptography stack or
low-level networking code. This gives the regular expression matcher a
lot more context to work with than a relatively insignificant host name,
as well as battle-tested and mature libraries for evaluating regular
expressions.

When an URI is used as an application-layer identifier, a public key
certificate, attribute certificate, or other PKIX artifact can provide
application-layer granularity using this proposal.

SOLUTION: GENERAL ASN.1 SYNTAX

id-pkixon-uriRegExps OBJECT IDENTIFIER ::= { TBD uriRegExps(x) }

URIRegExps ::= SET SIZE (1..MAX) OF URIRegExp

URIRegExp ::= SEQUENCE {
     name IA5String (SIZE (1..MAX)),
     pattern CHOICE {
       a IA5String,
       u UTF8String,
       n NULL
     },
     flags IA5String (SIZE (1..MAX)) OPTIONAL
     }

URIRegExps is a SET OF URIRegExp. All regular expressions must match for
the match to succeed.

The name field identifies an URI component, such as "scheme", "host", or
"path". The pattern field is a regular expression to match against the
URI component. Valid names are defined by RFC 3986, RFC 3987, and other
URI specifications. The reason why this is an open-ended string 
(IA5String) is because different URI standards, such as URNs, can define 
their own URI components. Making it a general string allows for 
flexibility so that as new URI proposals crop up, a parser can handle 
those without needing to rewrite the ASN.1. Additionally, you can 
specify multiple regular expressions to match against the same URI 
component.

Other considerations include treatment of IRIs and which regular
expression patterns must be supported. Those are details that will be
discussed in the I-D.

***********

Thank you,

Sean

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Mar 2010 12:35:43 -0700

I believe that this is best discussed on the new CertID mailing list, <https://www.ietf.org/mailman/listinfo/certid>. They are starting to deal with this issue from the relying party's end, namely "how do I know that the party identified in the cert is actually associated with the service that I want to connect to".

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Mar 2010 16:23:38 -0400

Paul's comment is correct with regard to the issue of matching 
Subject names in certs against application-layer identifiers.

However, to the extent that you want to propose new names forms for 
use in certs, that is a PKIX issue.

As I mentioned in a prior, private exchange, I think putting regular 
expressions in certs in name forms would be a bad idea. It adds 
complexity to cert processing, and raises questions of how the name 
constraints extension would interact with such names. It appears that 
a principle rationale for doing this is a marketplace artifact.  If 
the cost for EE certs for each server with a distinct DNS name were 
not too high (from widely accepted web site cert TAs), this would not 
seem to be a very big issue, right? Alternatively, if such TAs were 
willing to issue a CA (vs. EE) cert to a web site owner (for a 
reasonable price), the web site owner could then issue EE certs for 
each of it's servers as more were brought online. If a name 
constrains extension were put into these CA certs by the TAs, the EE 
certs would be constrained so that web site owners are not empowered 
to issue certs for syntactically inappropriate sites. I am loathe to 
suggest major changes to name forms and to cert processing to 
accommodate marketplace-induced issues of this sort.

Steve

---

From: Sean Leonard <[email-masked]>
Date: Wed, 17 Mar 2010 13:39:01 -0700

Steve,

This is not a marketplace artifact.

The issue is that it is burdensome (or impossible) to enumerate all 
resources in advance. Not only is it burdensome, it is a waste of 
bandwidth and a waste of administrative time.

Suppose that you want to match against rsync://rsync.example.com/XX/...

where XX is any ALPHA character (A-Z, a-z) and ... is anything else.

Under current standards, you have a choice:
Issue one certificate with at least 2704 uniformResourceIdentifiers (AA, 
AB..AZ..Aa..Az..BA..zz).
Issue 2704 certificates each with one uniformResourceIdentifier.

And, of course, none of these deal with the "..." at the end, to permit 
anything to match after that. If you consider permuations with "...", 
you are asking for a certificate with an infinite number of 
uniformResourceIdentifiers, or an infinite number of certificates, or an 
infinite combination of both. Last I checked, we do not have an infinite 
amount of bandwidth to waste on an infinite number of URLs, or an 
infinite amount of computation time to check an infinite numbers of URLs 
against one particular URL in one particular case.

We have also formulated the proposal carefully to avoid the issue of 
"servers". A certificate that identifies an URI identifies the resource 
at that URI, not a server. TLS is a potential application but is not the 
primary driver of this proposal. That is also why this is all about 
URIs, not about DNS names.

My only initial comment on the name constraints issue is that URI 
RegExps were not intended to be used with the name constraints 
extension. I suppose that they can lend themselves to name constraints 
in a much more obvious and easy way than the existing RFC 5280 
specification, however, but would rather open that can of worms (if at 
all) in the context of an existing I-D. In any event, RFC 5280 does not 
require implementations to support any name constraint other than 
directoryName, so I would leave it at that.

-Sean

Stephen Kent wrote:
> Paul's comment is correct with regard to the issue of matching Subject 
> names in certs against application-layer identifiers.
>
> each of it's servers as more were brought online. If a name constrains 
> extension were put into these CA certs by the TAs, the EE certs would 
> be constrained so that web site owners are not empowered to issue 
> certs for syntactically inappropriate sites. I am loathe to suggest 
> major changes to name forms and to cert processing to accommodate 
> marketplace-induced issues of this sort.
>
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 17 Mar 2010 17:09:42 -0400

>Suppose that you want to match against rsync://rsync.example.com/XX/...

what is the concrete, real situation where this need arises?  I think 
most folks understand the web site case that motivates use of 
wildcard DNS names. What you are describing is not congruent to that, 
so I think some more concrete motivation is needed. None of the later 
text in your message addresses is specific. It talks in terms of  TLS 
as not being the primary application, but fails to say what is the 
primary application :-).  It says that the proposal is not focusing 
on servers, but with URIs, which is a similarly vague 
characterization.

The observation that names with regular expressions might be 
incompatible with the name constraints extension is a useful 
clarification, but not an encouraging one :-).You said that "RFC 5280 
does not require implementations to support any name constraint other 
than directoryName, so I would leave it at that."  Note that 5280 
says that support for name constraints for rfc822 names, URIs, DNS 
names and IP addresses is a SHOULD, so I think you are trying to draw 
too fine a line here (maybe a bias from your legal training :-)?). 
Also note the sentence at the end of the paragraph from which you 
quoted:

     If a name constraints extension that is marked as critical
    imposes constraints on a particular name form, and an instance of
    that name form appears in the subject field or subjectAltName
    extension of a subsequent certificate, then the application MUST
    either process the constraint or reject the certificate.

In any case, I don't think PKIX will seriously entertain this sort of 
proposal without concrete examples to motivate it.

Steve

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 17 Mar 2010 18:13:39 -0400

You've lost me at the point where you switch from "authenticate" to
"identify".   One can identify many things (e.g., files, documents, web
pages), but one can only authenticate key holders (e.g, service
providers).  How many active entities (private key holders) are involved
in the URI:

    "rsync://rsync.example.com/XX/...
        where XX is any ALPHA character (A-Z, a-z) and ... is anything
else."

What is a CA certifying if it issues a certificate containing this URI?
It is reasonably clear who owns the right to use a DNS name, and thus
why someone else trying to use that name should fail to authenticate.
But (apart from virtual hosting, which you deny interest in), it is not
clear why one resource (key holder) hosted at rsync.example.com should
authenticate while a different key holder at the same host that does not
match the expression should fail to authenticate.

Before extolling the advantages of "combining two great and well-tested
technologies that are already used together in the wild, URIs and
regular expressions", you need to describe how active entities are
related to those great technologies.  This is a security working group,
and security involves enabling good things while preventing bad things.
Understanding the actors in any scenario (Alice the resource provider,
Bob the resource consumer, Carol the CA, and Mal the attacker) is a
prerequisite to considering any proposal to stuff URIs into
certificates.  Syntax is trivial, but security is about semantics.  The
fact that you don't care about name constraints is an indication that
you haven't given much thought as to what you are trying to
authenticate.

Dave

-----Original Message-----
From: Sean Leonard

PKIX artifacts (certificates, attribute certificates, etc.) are
frequently used to authenticate services and resources, but not all of
the actual names may be known in advance. URIs can be used at the
application level to identify resources, ...

---

From: Sean Leonard <[email-masked]>
Date: Wed, 17 Mar 2010 15:29:23 -0700

Stephen Kent wrote:
> most folks understand the web site case that motivates use of wildcard 
> DNS names. What you are describing is not congruent to that, so I 
> think some more concrete motivation is needed. None of the later text 
> in your message addresses is specific. It talks in terms of  TLS as 
> not being the primary application, but fails to say what is the 
> primary application :-).  It says that the proposal is not focusing on 
> servers, but with URIs, which is a similarly vague characterization.
What is vague about:
rsync://rsync.example/com/XX/..?

We want to identify resources by URI, on a per-URI basis. RSYNC is a 
concrete example. So is ftp, http, ldap, and so on. There are times when 
we want to match against URNs, where the URN is known. For example, we 
want to identify XML schemas which are identified by URN. (That is a 
real case: yes, we want that.) And we want to identify those resources 
using GeneralName in certificates and attribute certificates. Does there 
need to be a more concrete discussion of the application?

Here is a more concrete application: We are developing an application 
that accesses and identifies resources by URIs and decides whether to 
proceed with processing the resource or not. If it's an HTTP resource, 
it says "open a network channel; get me the HTTP resource." If it's an 
LDAP resource, it says "give me the resource using LDAP." If it's a data 
URL, you get the picture. The resource itself can change, so we are not 
validating a signature against the data of the resource. If we were 
doing that then we would probably use id-kp-emailProtection (if 
e-mails), id-kp-codeSigning (if blobs of code), and so on.

Perhaps there is a disconnect because perhaps you are thinking that 
certificates are good for nothing other than SSL/TLS authentication. :-) 
Certificates are just vessels to certify *things* according to 
certification authorities and the certificate path validation algorithm. 
Attribute certificates are just vessels to certify authorization to 
access to things by other things.

Also perhaps I am misunderstanding but on the one hand there is some 
sentiment about finding some big commercial reason to support the 
further development of some standard, but on the other hand there is a 
resistance to what the marketplace actually wants...

Sean

---

From: Sean Leonard <[email-masked]>
Date: Wed, 17 Mar 2010 15:50:46 -0700

> "identify".   One can identify many things (e.g., files, documents, web
When used in the attribute certificate context, a GeneralName can be 
used to identify a resource that is authorized for access. Authorization 
and authentication are different things. Both, however, rely on 
identification.

When a client connects to rsync://rsync.example.com/ab/docs, if TLS is 
being used the client has to rely on the server at rsync.example.com to 
provide proper resolution of "/ab/docs" to the right resource. But, that 
is inherent to the way that URIs work.

You can use the proposal for identification, which can be used for 
authentication, for authorization, or for both.

If you use an URI RegExp as an authenticator, the resource might present 
this to the client, which the client would check against the URI that is 
requesting. Yes, it has to "trust" (a touchy subject around here, which 
nobody can seem to define) that the server provided it the right 
resource for the URI. But it has to trust the server anyway to provide 
resolution, which it can infer from other means (namely TLS 
certificate...and even then, who is saying that TLS certifies all that 
much).

If you use an URI RegExp as part of authorization, the server might 
examine the authorization token (attribute certificate) and see that the 
client is authorized to access this resource. When making this 
authorization decision, again it's a lot easier to specify one pattern 
than the millions of different URLs that could possibly be authorized. 
And the assumption with attribute certificates is that the AA is not 
some big aloof CA in a faraway land, but a system running in the 
organization or under the organization's control that has access to some 
master access control lists.

If you want an example with actors:
Alice is the resource provider.
Bob is the client, the resource consumer.
Carol is a CA.
Dave is an Attribute Authority, that issues attribute certificates.
E is Elmer, a server that offers resources by URIs.

A and D are in the same organization. B is an employee of the same 
organization. E is run by the organization. C and A/B/D have a contract: 
C issues infinite certificates to A/B/D for $1. B has a client 
certificate issued by C to identify B as B using any protocol that uses 
certificates.

Now B wants to access a resource made available by A on E, but B's 
certificate only identifies B as B. So B procures an attribute 
certificate from D that identifies A's resources by URI on E. B submits 
a request to E asking for A's resources. E can look at the attribute 
certificate from D and let B pass without constantly bombarding D or A 
with requests for "can B access this resource? Can B access that 
resource? Can B access yet another resource over here?"

Scenario 2:
Rather than procuring an attribute certificate from D, B can just get a 
certificate from C that contains this authorization information (for 
example, in the subject directory attributes extension). That saves 
issuing attribute certificates if you want to cut out that step.

Do these examples help?

Sean

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Mar 2010 15:05:54 -0800

Okay, so if this would be useful for authorization but not
authentication, it seems to me that it might not be a bad
idea to limit their applicability to attribute certificates.
I've been squinting at this trying to decide how comfortable
I am with the proposal, and excluding them from use for
authentication moves the comfort level in a positive direction.

Melinda

---

From: Patrick Patterson <[email-masked]>
Date: Wed, 17 Mar 2010 19:07:20 -0400

On 17-Mar-10, at 6:29 PM, Sean Leonard wrote:

>>> The issue is that it is burdensome (or impossible) to enumerate  
>>> all resources in advance. Not only is it burdensome, it is a waste  
>>> of bandwidth and a waste of administrative time.
>>>
>> what is the concrete, real situation where this need arises?  I  
>> think most folks understand the web site case that motivates use of  
>> wildcard DNS names. What you are describing is not congruent to  
>> that, so I think some more concrete motivation is needed. None of  
>> the later text in your message addresses is specific. It talks in  
>> terms of  TLS as not being the primary application, but fails to  
>> say what is the primary application :-).  It says that the proposal  
>> is not focusing on servers, but with URIs, which is a similarly  
>> vague characterization.
> What is vague about:
> concrete example. So is ftp, http, ldap, and so on. There are times  
> when we want to match against URNs, where the URN is known. For  
> example, we want to identify XML schemas which are identified by  
> URN. (That is a real case: yes, we want that.) And we want to  
> identify those resources using GeneralName in certificates and  
> attribute certificates. Does there need to be a more concrete  
> discussion of the application?
>
I sincerely doubt there is any system alive that can or should  
advertise the fact that "Hi, I'm an RSync server, located at  
rsync.example.com, and to help you attack me, I'd like to tell you the  
first part of the naming scheme that I serve".

If you are trying to put "I am ALLOWED to access rsync:// 
rsync.example.com/Aa/..." in an identity certificate, you are  
completely missing the point of what a certificate is about.

> Here is a more concrete application: We are developing an  
> application that accesses and identifies resources by URIs and  
> decides whether to proceed with processing the resource or not. If  
> it's an HTTP resource, it says "open a network channel; get me the  
> HTTP resource." If it's an LDAP resource, it says "give me the  
> resource using LDAP." If it's a data URL, you get the picture. The  
> resource itself can change, so we are not validating a signature  
> against the data of the resource. If we were doing that then we  
> would probably use id-kp-emailProtection (if e-mails), id-kp- 
> codeSigning (if blobs of code), and so on.
>
Once again, you are confusing authentication and identification.  
Certificates say "Hi, I am me, because this trusted third party says  
so" - that's it, that's all - it's up to the application to either  
handle authorisation itself, or to use another mechanism that is much  
better for conveying this (like Identity Federation or Attribute  
Certificates, although the former tends to be MUCH more widely used  
than the latter).

> certificates are good for nothing other than SSL/TLS  
> authentication. :-) Certificates are just vessels to certify  
> *things* according to certification authorities and the certificate  
> path validation algorithm. Attribute certificates are just vessels  
> to certify authorization to access to things by other things.
>

No - as I just said - certificates are useful for Identification -  
whether that is by identifying the end points of an SSL/TLS or IPSec  
connection, or identifying who I am encrypting to, or identifying who  
signed this document, email, or assertion. It simply says that some  
third party has identified me as me (according to their policy), and  
that if you trust that third party, you should trust in this identity  
vouched for by that third party.

> further development of some standard, but on the other hand there is  
> a resistance to what the marketplace actually wants...
>
If you can provide some use case that properly uses certificates to  
Identify entities that require the use of Regex's (beyond the * that  
is currently used), and can come up with the name constraint rules and  
schema to enable proper "source of authority" tracing and enforcement,  
then I think that this workgroup is willing to listen. It's just that  
your examples so far have been based on an "authorisation" rather than  
an "identification" model for certificate use, which, I believe, is  
not the widely held view of what certificates *SHOULD* be used for  
(and, has been widely viewed as a flawed model, which is WHY there are  
attribute certs, and Identity Federation).

Best Regards,

---
Patrick Patterson
President and Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

---

From: Sean Leonard <[email-masked]>
Date: Wed, 17 Mar 2010 16:48:27 -0700

Thank you for the comments.

So to summarize the state of play:
Authorization: The general sentiment of using regular expression 
patterns for authorization purposes is positive (or, at least, 
non-negative). In authorization, you have an identity that has been 
sufficiently authenticated according to the application's usage, and now 
the application is checking that identity against an access control list.

Such is generally the model for attribute certificates and Identity 
Federation. But the underlying point is that you are using the pattern 
or list for an authorization purpose.

Authentication: This is more problematic. To state it succinctly, if you 
use a pattern for "authentication", you really don't know who or what 
you are dealing with. The model for certificates is that a certificate 
is issued to a concrete person or thing, and therefore the certificate 
should say what, exactly, the person or thing is.

So the objection has less to do with URI regular expressions per-se, and 
more to do with the general premise of using open-ended patterns for 
authentication purposes. An open-ended pattern, it is claimed, does not 
identify a single, specific resource, and the idea of identifying lots 
of resources (e.g., lots of servers) with one certificate implies that 
they are also sharing the same private key (which is seen as a bad 
security practice). This is probably why the wildcard * in DNS names has 
been greeted with a lot of pushback (but is begrudgingly accepted since 
everybody has been doing it for years anyway in the DNS + SSL/TLS case). 
The WG would rather see open-ended patterns die out for authentication 
purposes, but has to support the legacy case.

Is this correct?

I would be comfortable with a statement in the I-D that limits regular 
expressions to authorization, or that explains the rationale for why 
they SHOULD NOT be used for authentication purposes.

Sean

Melinda Shore wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Mar 2010 16:57:09 -0700

At 4:48 PM -0700 3/17/10, Sean Leonard wrote:
>Authorization: The general sentiment of using regular expression patterns for authorization purposes is positive (or, at least, non-negative).

No. One person said that, and she was tentative.

> In authorization, you have an identity that has been sufficiently authenticated according to the application's usage, and now the application is checking that identity against an access control list.

You still have not given us a real-world example of where this is useful. The rsync example you used earlier was for authentication of an rsync server, not authorization.

Please try again.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 17 Mar 2010 16:23:25 -0800

> No. One person said that, and she was tentative.

Right, and I'm still not sure.  The main point was
that limiting the scope to describing things-against-
which-authorizations-would-be-applied helps remove
the concerns about authentication, because ... they
wouldn't be used for authentication.  But I'm just
not sure about the rest.  The attribute cert stuff
that's come out of pkix is frankly very Globus/grid-
centric, and if you're going to change both the
syntax and the semantics of objects of authorizations,
it begs the question of what the authorizations are
and that seems to me to be a whole other can of
worms.

I'm not against the proposal to use regular expressions
here, but rather trying to understand the implications.

Melinda

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Mar 2010 11:50:01 -0400

At 3:50 PM -0700 3/17/10, Sean Leonard wrote:
>used to identify a resource that is authorized for access. 
>Authorization and authentication are different things. Both, 
>however, rely on identification.

no, they don't. Authoriation based on ACLs relies on identification, 
while authorization based on capabilities need not.

I won't comment on the rest of your message as I found the example to 
be very confusing (confused?).  Maybe this thread will yield a better 
explanation as it progresses.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Mar 2010 11:46:05 -0400

At 3:29 PM -0700 3/17/10, Sean Leonard wrote:
>We want to identify resources by URI, on a per-URI basis.

identify vs. authenticate?

>RSYNC is a concrete example. So is ftp, http, ldap, and so on. There 
>are times when we want to match against URNs, where the URN is 
>known. For example, we want to identify XML schemas which are 
>identified by URN. (That is a real case: yes, we want that.) And we 
>want to identify those resources using GeneralName in certificates 
>and attribute certificates. Does there need to be a more concrete 

these are not descriptions of applications. they are syntactic 
examples prefixed with "we want." more details of the applications 
are needed.

>would probably use id-kp-emailProtection (if e-mails), 
>id-kp-codeSigning (if blobs of code), and so on.

validating a signature on what?

>certificates are good for nothing other than SSL/TLS authentication. 

yes, I obviously think that certs are useful only for TLS, given my 
authorship of RFC 4301 :-).

>certification authorities and the certificate path validation 
>algorithm. Attribute certificates are just vessels to certify 
>authorization to access to things by other things.

the terminology above is way too vague. A public key cert (PKC) binds 
attributes to a key.  typically the attribute of interest is a name, 
but not always (e.g., see the resource certs for the RPKI in the SIDR 
WG). An AC binds authorization attributes to an entity via reference 
to the PKC for that entity.

>a resistance to what the marketplace actually wants...

PKIX pursues standardization of protocols and formats for PKI objects 
that are of perceived to be of general utility (not 
application-specific) in PKI cntexts. When someone proposes a work 
item we want to understand whether the item fits these criteria.  If 
the description is one that most PKIX members can understand as 
meeting these criteria, we proceed. If not, we don't. Comments like 
"what the marketplace actually wants" have little weight here, since 
an individual making such a comment is rarely a representative of 
"the marketplace," but rather someone who thinks he/she had an idea 
that will be marketable :-).

Steve

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 18 Mar 2010 13:28:47 -0400

Sean,

It seems there is still some confusion.

> they SHOULD NOT be used for authentication purposes.

The reasons for not using open-ended anything for authorization have been made pretty clear and I will not reiterate them. In the context of attribute certificates (AC) regular expressions are also inappropriate. Perhaps the terminology needs some clarification. 

There are two specific ways to use the word "authorize":
1) As a verb - to authorize, the act of allowing or denying access to a resource 
2) As a noun - authorization, proof of privilege to access a resource

As you use it above is not precise or correct, authorization is not synonymous with defining authorization policy. A URI (uniform Resource identifier) identifies a resource, and regular expressions define policy. When you say

On Mar 17, 2010, at 4:39 PM, Sean Leonard wrote
> bandwidth and a waste of administrative time.

This is a policy decision, not an authorization assertion, so I fail to see the applicability of the example.

> rsync://rsync.example/com/XX/..?

Using a wildcard like this is poor security practice because it presumes knowledge of future policy. Should that policy change, you have no choice but to scrap the URI. In production, if left no alternative, we would instead use a single URI representing a level of privilege (ex rsync://rsync.example.com/XX/policy#2010) in the AC and perform the actual authorization decision at the resource level. 

The rules (i.e. policy) for performing authorization decisions do not belong in authentication or attribute certificates, which are personal or privilege authentication medium. There are standards tracks for securely distributing authorization policy rules, for example the Match rule in XACML, but these rules can change more often than the individuals and resources they identify and therefore do not belong in certificates.

Theory aside, Steve hit the nail on the head:

> that will be marketable :-).

Standards are worth perusing when there are a class of applications that would benefit from interoperability. I haven't seen a single applicable application, let alone a class of them. If there is a commercial application that must use certificates improperly, the best route is a non-critical extension under your organization's OID arc. 

Jacob

--------
Jacob Dilles
Research and Development
Pericore, Inc. 
http://www.pericore.com

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 18 Mar 2010 14:19:51 -0400

Actually there are, unfortunately, three ways that authorization has
been used:

1)      An approval that is granted to a system entity to access a
system resource (concrete noun referring to a thing)

2)      A process for granting approval to a system entity to access a
system resource (abstract noun referring to an activity)

3)      A process for deciding whether a system entity has been granted
approval to access a system resource (abstract noun referring to an
activity)

The first two are straight from RFC 4949, the Internet Security
Glossary, and refer to authorizing a user.   The third I just made up,
to paraphrase the SAML definition of "authorization" using words similar
to RFC 4949.  The actual, incorrect, SAML definition is:

The process of determining, by evaluating applicable access control
information, whether a subject is allowed to have the specified types of
access to a particular resource.

Authorizing a subject involves creating access control information -
authorization *is* the process of establishing access control policy.
It cannot mean evaluating policy in order to make an access control
decision because if that were true, anyone who breaks into a system and
steals protected information could claim "I am authorized to have this
information because the system gave it to me."   A positive access
control decision is *not* an authorization, and the process of making
access control decisions is *not* the process of authorization.  See
http://en.wikipedia.org/wiki/Authorization -> Confusion.

Dave

From: Jacob Dilles

1) As a verb - to authorize, the act of allowing or denying access to a
resource 

As you use it above is not precise or correct, authorization is not
synonymous with defining authorization policy. A URI (uniform Resource
identifier) identifies a resource, and regular expressions define
policy.

---

From: Bill Russell <[email-masked]>
Date: Thu, 18 Mar 2010 14:37:16 -0400

Hi Dave,

I think you've highlighted well the confusion around trying to define authorization based on conflicting definitions out there. At a surface level, I agree with your statement that authorization is the process of establishing access control policy, but only if the policy itself doesn't leave open variables. The problem we run into with RAdAC is that the policy definitions can be complicated, and operate more like a rule rather than an authorization. So, I'd be careful not to make that case too strongly.

Nonetheless, I think the bigger issue is how far do we stretch certificates and attribute certificates in the search of providing authorization mechanisms. It seems like we are trying to do too much with certificates.

Take care,
Bill

From: [email-masked] [mailto:[email-masked]] On Behalf Of Kemp, David P.
Sent: Thursday, March 18, 2010 2:20 PM
To: [email-masked]
Subject: [pkix] Authorization: was RE: Proposal for matching uniform resource identifiers with regular expressions in certificates

Actually there are, unfortunately, three ways that authorization has been used:

1)      An approval that is granted to a system entity to access a system resource (concrete noun referring to a thing)

2)      A process for granting approval to a system entity to access a system resource (abstract noun referring to an activity)

3)      A process for deciding whether a system entity has been granted approval to access a system resource (abstract noun referring to an activity)

The first two are straight from RFC 4949, the Internet Security Glossary, and refer to authorizing a user.   The third I just made up, to paraphrase the SAML definition of "authorization" using words similar to RFC 4949.  The actual, incorrect, SAML definition is:

The process of determining, by evaluating applicable access control information, whether a subject is allowed to have the specified types of access to a particular resource.

Authorizing a subject involves creating access control information - authorization *is* the process of establishing access control policy.  It cannot mean evaluating policy in order to make an access control decision because if that were true, anyone who breaks into a system and steals protected information could claim "I am authorized to have this information because the system gave it to me."   A positive access control decision is *not* an authorization, and the process of making access control decisions is *not* the process of authorization.  See http://en.wikipedia.org/wiki/Authorization -> Confusion.

Dave

From: Jacob Dilles

As you use it above is not precise or correct, authorization is not synonymous with defining authorization policy. A URI (uniform Resource identifier) identifies a resource, and regular expressions define policy.

---

From: Jacob Dilles <[email-masked]>
Date: Thu, 18 Mar 2010 16:14:29 -0400

Dave,

Perhaps it has been used, but I disagree with your definition. Authorization is granted to a "system entity" by policy, and does not encompass the methods used to evaluate that policy. A concrete example is necessary lest we talk around in circles.

Bob has a secret clearance. What does that mean? Someone (with the authority to do so) has determined that Bob is authorized to access resources categorized as secret. This determination is recorded as part of the classification policy pertaining to a set of resources.

Say there is a classified document on http://www.example.com/ProjectX that Bob wishes to access. After authenticating with the server/application/etc.. to prove he is who he says he is, the server must decide if he is authorized to access the document. Is the process by which it arrives at this decision the authorization? No - Bob is clearly already authorized from the time he obtained his clearance (and was added to the policy), by the authority who defined the policy. Bob is not granted access because of some process in the access control mechanism, he is granted access because of policy. The access is the authorization. It does not matter if the URI is stored in an attribute certificate, Bob's username is in a database, or the document is printed out sitting on his desk, Bob is authorized to access it.

I don't think that someone who has maliciously gained access to protected information can claim they are authorized to do so - they were never included in the policy, regardless of the process used to gain access to that information. The failure is in the access control, not the policy, and they have never and will never have authorization to access that information.

All of that (and Wikipedia) aside, I think that RFC 4949 makes it pretty clear that access control is the decision process while authorization is the decision itself. The expanded definition including the decision process - though occasionally (mis)used - is inaccurate.

Jacob

$ access control

      2. (I) A process by which use of system resources is regulated
      according to a security policy and is permitted only by authorized
      entities (users, programs, processes, or other systems) according
      to that policy. (See: access, access control service, computer
      security, discretionary access control, mandatory access control,
      role-based access control.)

$ authorization

      1a. (I) An approval that is granted to a system entity to access a
      system resource. (Compare: permission, privilege.)

      1b. (I) A process for granting approval to a system entity to
      access a system resource.

$ security policy

      2a. (I) A set of policy rules (or principles) that direct how a
      system (or an organization) provides security services to protect
      sensitive and critical system resources. (See: identity-based
      security policy, policy rule, rule-based security policy, rules of
      behavior. Compare: security architecture, security doctrine,
      security mechanism, security model, [R1281<http://tools.ietf.org/html/rfc4949#ref-R1281>].)

http://tools.ietf.org/html/rfc4949

On Mar 18, 2010, at 2:19 PM, Kemp, David P. wrote:

The first two are straight from RFC 4949, the Internet Security Glossary, and refer to authorizing a user.   The third I just made up, to paraphrase the SAML definition of “authorization” using words similar to RFC 4949.  The actual, incorrect, SAML definition is:

Authorizing a subject involves creating access control information – authorization *is* the process of establishing access control policy.  It cannot mean evaluating policy in order to make an access control decision because if that were true, anyone who breaks into a system and steals protected information could claim “I am authorized to have this information because the system gave it to me.”   A positive access control decision is *not* an authorization, and the process of making access control decisions is *not* the process of authorization.  See http://en.wikipedia.org/wiki/Authorization -> Confusion.

Dave

From: Jacob Dilles

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Patrick Patterson <[email-masked]>
Date: Thu, 18 Mar 2010 16:30:25 -0400

Hi Bill:

On 18/03/10 2:37 PM, Bill Russell wrote:
> 
> Nonetheless, I think the bigger issue is how far do we stretch
> certificates and attribute certificates in the search of providing
> authorization mechanisms. It seems like we are trying to do too much
> with certificates.
> 
>
I agree with you completely - Certificates do a reasonably good job at
conveying identity, and a select few very persistant attributes (email
address - which can be argued to be an identity in and of itself). They
tend to fail rather miserably if one also tries to stuff authorizations
in them - the short statement I like to use when explaining the
difference is:

Certificates say "WHO" the holder is.

An Attribute service (Federated Identity, AC, etc.) say WHAT they are
allowed to do.

The more that we can re-enforce that difference, the easier it will be
to keep PKI certificates completely interoperable, and leave the
non-interoperable bits (which attributes inevitably are - they tend to
be application, domain, technology or company specific) to others to
sort out :)

Have fun.

Patrick.

---

From: Michael Myers <[email-masked]>
Date: Thu, 18 Mar 2010 19:34:29 -0700

I can't find the source document related to this thread.  Would  
someone please give me a pointer?

Mike

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Mar 2010 21:27:59 -0600

On 3/18/10 8:34 PM, Michael Myers wrote:
> I can't find the source document related to this thread.

That's because there is no source document.

> Would someone please give me a pointer?

The only pointer is this thread itself, starting here:

http://www.ietf.org/mail-archive/web/pkix/current/msg27587.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Mar 2010 21:45:37 -0600

> match the expression should fail to authenticate.

Excellent question. On what basis would a certification authority decide
to issue a certificate for "rsync://rsync.example.com/XX/" but not
"rsync://rsync.example.com/YY/"? It seems to me that such knowledge
might exist within the example.com domain but would not be available to
a CA outside that domain.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Mar 2010 11:11:33 -0400

At 4:30 PM -0400 3/18/10, Patrick Patterson wrote:
>...

In general your characterization is correct, i.e., most certs are 
issued as identification credentials, but that is not always the 
case.  See the resource certs used in the RPKI (SIDR WG) for example.

Steve

---

From: Sean Leonard <[email-masked]>
Date: Sun, 21 Mar 2010 00:49:13 -0700

Thank you all for the comments thus far.

We identified a technical problem: how to identify resources when a **class** of URI resources are known, but putting all the resources in the attribute certificate (or certificate) would yield a really huge attribute certificate (or certificate). To say that "the resources are not all known in advance" or to use "open-ended" is to only partially state the point. A class of resources IS known, that that class is defined by something broader than a single URI (uniformResourceIdentifier), but lesser than an entire host (dNSName) or IP address (iPAddress). We are using the class primarily for authorization purposes against paths (foo.com/path1), but nothing technically limits the problem or the solution to authorization purposes or to the first parts of paths.

We believe that this is a class of technical problems that will benefit from interoperability. Even if there are no actual users of patterns in URIs at this time, there is also no way to do it in an interoperable way. Surely someone in a similar situation will face the same problem, and PKIX can provide a solution for them. (Compare with RFC 3185--"nobody" really uses that technique, but it is a technical problem, it admits of a technical solution, and if two parties want to do that in an interoperable way, they have an IETF-published method to do it.) The main point of the initial e-mail was to see if there is any interest and if others have a need for it, so that we could offer a free contribution of this proposal to the IETF process.

If there are literally NO other people who could possibly use patterns of resources, then some claim that the standardization discussion is over until there are other people who come forward with a "need" for interoperability, I suppose. If there are material security issues with the proposal, then those need to be addressed before continuing. But it's a lot easier to develop interoperable standards if you do it openly in the first place, get feedback from the community, publish a specification, and let others emulate it. How can you interoperate with applications, if there is no format to interoperate with in the first place?

The points about authentication, authorization, and authorization policy are understood. However, it is incorrect to say that certificates or attribute certificates are only about bald statements of the "fact" of an authorization decision. As has already been pointed out, PKIX artifacts are not "authentications" or "authorizations". An authorization is a decision, made by someone with authority, that a subject is allowed to access a resource. Certificates and attribute certificates are merely **digital artifacts**. Computers just apply the attributes in them using patterns of rules to data in order to compute a result.

Take a look at your driver's license. It identifies you. But is it authentication, or authorization? It is neither--it is a physical artifact that is evidence of an authorization for *you* to drive a motor vehicle. That is why it is called a "license"--because it authorizes you to drive! But it's also used for authentication, right? Sure. It has an image of your likeness, which an officer can use to verify you face-to-face. The combination saves the officer time, and it puts people on notice without making an unnecessary trip to "the well" (the driver license database) when the risk of stale information is much smaller than the burden of checking for the latest updated information. If the driver's license only lets you drive regular passenger autos and not Armored Personnel Carriers, and you're in an APC, the officer can arrest you on the spot. (How the officer takes down an APC is an exercise for the reader to determine. :)

The big advantage of digital signature technology in contrast to physical IDs, however, is that when implemented properly, PKIX artifacts are provably infeasible to forge. Thus the risk that information inside of them is bad is limited to the issuer issuing bad information and the information changing before the artifact expires. Both of these risks are well-studied problems that PKIX addresses.

If you don't want to use certificates for "authorization", or you don't want to use attribute certificates for "authentication", don't use them that way. You don't have to, and you don't have to accept artifacts from CAs that use them that way. But the line is not nearly as fine as some seem to believe. Nothing in RFC 5280 limits certificates to "authentication"; in fact, using PKIX certificates for authorization is explicitly acknowledged by RFC 5755 sec. 1: "Authorization information may be placed in a PKC extension or placed in a separate attribute certificate (AC)." The RFC goes on to explain two key reasons why this is undesirable. But take a look at X.509-2005, which clarifies a lot of the vagaries of X.509-2000. It is no accident that the Subject Directory Attributes extension in a PKC encompasses the exact same attributes as the Attributes field in an AC. Issuing ACs separately from PKCs is an optimization when the PKC issuer doesn't have the wherewithals to include that information itself, or when that information changes with greater frequency than the main purpose of the PKC (namely, to bind required attributes to the key). Stuffing so-called "authorization" information into a PKC is also an optimization when the underlying protocol has no AC transfer mechanism, or when the authorization information's lifetime is coterminus with the PKC itself. In many cases, the CA chain itself serves as the authorization mechanism: anybody with a certificate (and corresponding private key) is granted access to a resource when the certificate validates to a particular CA root.

Steve said it succinctly: all certificates do is bind attributes to a public key. The only difference with an attribute certificate is that ACs bind attributes to a "Holder", which may or may not be a public key certificate (and therefore, a public key).

Heuristics (what people have called "policies") are in certificates: just look at the Certificate Policies extension or policy mappings extension with anyPolicy, for examples. Similarly with name constraints: the name constraints extension defines a policy of what CA certificates down the chain are authorized to certify or not. The entire certificate (or attribute certificate) can be seen as patterns of rules that are applied to a particular resource in order for computers to go down one code path or another. A dNSName of "foo.example.com" may look like it is not a pattern, but you are ignoring the fact that the entire certificate is just a pattern--the only variable to be matched against is the DNS name. Leaving extended key usage absent is tantamount to saying that you can use it with * protocol, not just TLS, e-mail, XMPP, and so on. And "patterns" are all over RPKI: look at draft-ietf-sidr-res-certs and RFC 3779 as examples. (Incidentally, RPKI also uses certificates to convey "right-of-use" information. This is authorization information with a slightly obfuscated name.)

I really think these are two sides of the same coin. Rather than saying that resources are not known in advance, consider that the resources are known in advance, but are all precisely encapsulated by a pattern. A list of names (as a list of GeneralNames) is just a list of very limited patterns. So rather than seeing rsync://example.com/foo/* as "open-ended", it bounds the inquiry to example.com, rsync, and /foo. It is much more bounded than the dNSName "example.com", which is much more open-ended. The only difference is that the open-endedness is hidden by the fact that you see only "dNSName" matching and not matching based on other parts of the identity of the resource.

Peter asked "how would a certification authority decide to issue to rsync://rsync.example.com/XX/ but not /YY/". The owner of example.com is the beneficiary of the certificate or attribute certificate. The beneficiary has that domain-specific knowledge (literally). But the certificate or attribute certificate provider and the beneficiary are in privity with one another. The provider has a contract to issue certificates and attribute certificates for the beneficiary, which the beneficiary pays for, and the beneficiary agrees to request certificates or attribute certificates only with patterns that the beneficiary actually needs. 

Least privilege is good security practice, not bad. And by adding patterns, you can get least privileges without enumerating millions of URI combinations. PKIX artifacts are just that--digital artifacts. They are building blocks to implement efficient and interoperable systems that adequately authenticate entities as they are, and that authorize entities to access resources, on the Internet. And at the application level, the Internet runs on URIs.

If the pattern changes, you don't have to scrap the URI. You can revoke the certificate or attribute certificate. And that is the point of revocation--when the patterns in the certificate or attribute certificate don't match reality, you revoke and re-issue. By using patterns to apply to URIs in certificates, we can have computers quickly and accurately determine the right results without making unnecessary trips to "the well" (namely, a remote database with the access control lists). The only trip necessary is the one to make sure that the PKC or AC are not revoked. The revocation issue is already handled adequately by PKIX-conformant implementations.

Now then, are any of the following actually true:
a) the general premise of limiting identification to a larger class of resources than a single resource, but a smaller class than "*" has materially negative security properties;
or, that
b) there are no conceivable applications of patterns of URIs in the PKIX context to anyone now or in the future--and not just "no plans that I will implement this in my application?"

Thank you,

Sean

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 21 Mar 2010 10:49:30 +0100

There was an abundance of words here.
Personally I think you may do whatever you want including a standards track RFC.

The *real* problem is (as always) getting vendor support.

In this case I think the problem is that authorization issues are better handled
by dynamic settings in authorization databases than in static certificates.
This is *one* of the reason why ACs (Attribute Certificates) haven't got much
traction on the market.

Essentially there are only two good uses of static certificates:
1. identifying something
2. vouching for capabilities

What you may do with an identity or a capability is a question for the
relying party, not the issuer.

If the relying party and the issuer is the same entity only reason for including
*redundant information* in a certificate would be to use it in an off-line situation.

Anders

----- Original Message ----- 
From: Sean Leonard
To: [email-masked]
Sent: Sunday, March 21, 2010 08:49
Subject: Re: [pkix] Proposal for matching uniform resource identifiers withregular expressions in 
certificates

We identified a technical problem: how to identify resources when a **class** of URI resources are 
known, but putting all the resources in the attribute certificate (or certificate) would yield a 
really huge attribute certificate (or certificate). To say that "the resources are not all known in 
advance" or to use "open-ended" is to only partially state the point. A class of resources IS known, 
that that class is defined by something broader than a single URI (uniformResourceIdentifier), but 
lesser than an entire host (dNSName) or IP address (iPAddress). We are using the class primarily for 
authorization purposes against paths (foo.com/path1), but nothing technically limits the problem or 
the solution to authorization purposes or to the first parts of paths.

We believe that this is a class of technical problems that will benefit from interoperability. Even 
if there are no actual users of patterns in URIs at this time, there is also no way to do it in an 
interoperable way. Surely someone in a similar situation will face the same problem, and PKIX can 
provide a solution for them. (Compare with RFC 3185--"nobody" really uses that technique, but it is 
a technical problem, it admits of a technical solution, and if two parties want to do that in an 
interoperable way, they have an IETF-published method to do it.) The main point of the initial 
e-mail was to see if there is any interest and if others have a need for it, so that we could offer 
a free contribution of this proposal to the IETF process.

If there are literally NO other people who could possibly use patterns of resources, then some claim 
that the standardization discussion is over until there are other people who come forward with a 
"need" for interoperability, I suppose. If there are material security issues with the proposal, 
then those need to be addressed before continuing. But it's a lot easier to develop interoperable 
standards if you do it openly in the first place, get feedback from the community, publish a 
specification, and let others emulate it. How can you interoperate with applications, if there is no 
format to interoperate with in the first place?

The points about authentication, authorization, and authorization policy are understood. However, it 
is incorrect to say that certificates or attribute certificates are only about bald statements of 
the "fact" of an authorization decision. As has already been pointed out, PKIX artifacts are not 
"authentications" or "authorizations". An authorization is a decision, made by someone with 
authority, that a subject is allowed to access a resource. Certificates and attribute certificates 
are merely **digital artifacts**. Computers just apply the attributes in them using patterns of 
rules to data in order to compute a result.

Take a look at your driver's license. It identifies you. But is it authentication, or authorization? 
It is neither--it is a physical artifact that is evidence of an authorization for *you* to drive a 
motor vehicle. That is why it is called a "license"--because it authorizes you to drive! But it's 
also used for authentication, right? Sure. It has an image of your likeness, which an officer can 
use to verify you face-to-face. The combination saves the officer time, and it puts people on notice 
without making an unnecessary trip to "the well" (the driver license database) when the risk of 
stale information is much smaller than the burden of checking for the latest updated information. If 
the driver's license only lets you drive regular passenger autos and not Armored Personnel Carriers, 
and you're in an APC, the officer can arrest you on the spot. (How the officer takes down an APC is 
an exercise for the reader to determine. :)

The big advantage of digital signature technology in contrast to physical IDs, however, is that when 
implemented properly, PKIX artifacts are provably infeasible to forge. Thus the risk that 
information inside of them is bad is limited to the issuer issuing bad information and the 
information changing before the artifact expires. Both of these risks are well-studied problems that 
PKIX addresses.

If you don't want to use certificates for "authorization", or you don't want to use attribute 
certificates for "authentication", don't use them that way. You don't have to, and you don't have to 
accept artifacts from CAs that use them that way. But the line is not nearly as fine as some seem to 
believe. Nothing in RFC 5280 limits certificates to "authentication"; in fact, using PKIX 
certificates for authorization is explicitly acknowledged by RFC 5755 sec. 1: "Authorization 
information may be placed in a PKC extension or placed in a separate attribute certificate (AC)." 
The RFC goes on to explain two key reasons why this is undesirable. But take a look at X.509-2005, 
which clarifies a lot of the vagaries of X.509-2000. It is no accident that the Subject Directory 
Attributes extension in a PKC encompasses the exact same attributes as the Attributes field in an 
AC. Issuing ACs separately from PKCs is an optimization when the PKC issuer doesn't have the 
wherewithals to include that information itself, or when that information changes with greater 
frequency than the main purpose of the PKC (namely, to bind required attributes to the key). 
Stuffing so-called "authorization" information into a PKC is also an optimization when the 
underlying protocol has no AC transfer mechanism, or when the authorization information's lifetime 
is coterminus with the PKC itself. In many cases, the CA chain itself serves as the authorization 
mechanism: anybody with a certificate (and corresponding private key) is granted access to a 
resource when the certificate validates to a particular CA root.

Steve said it succinctly: all certificates do is bind attributes to a public key. The only 
difference with an attribute certificate is that ACs bind attributes to a "Holder", which may or may 
not be a public key certificate (and therefore, a public key).

Heuristics (what people have called "policies") are in certificates: just look at the Certificate 
Policies extension or policy mappings extension with anyPolicy, for examples. Similarly with name 
constraints: the name constraints extension defines a policy of what CA certificates down the chain 
are authorized to certify or not. The entire certificate (or attribute certificate) can be seen as 
patterns of rules that are applied to a particular resource in order for computers to go down one 
code path or another. A dNSName of "foo.example.com" may look like it is not a pattern, but you are 
ignoring the fact that the entire certificate is just a pattern--the only variable to be matched 
against is the DNS name. Leaving extended key usage absent is tantamount to saying that you can use 
it with * protocol, not just TLS, e-mail, XMPP, and so on. And "patterns" are all over RPKI: look at 
draft-ietf-sidr-res-certs and RFC 3779 as examples. (Incidentally, RPKI also uses certificates to 
convey "right-of-use" information. This is authorization information with a slightly obfuscated 
name.)

I really think these are two sides of the same coin. Rather than saying that resources are not known 
in advance, consider that the resources are known in advance, but are all precisely encapsulated by 
a pattern. A list of names (as a list of GeneralNames) is just a list of very limited patterns. So 
rather than seeing rsync://example.com/foo/* as "open-ended", it bounds the inquiry to example.com, 
rsync, and /foo. It is much more bounded than the dNSName "example.com", which is much more 
open-ended. The only difference is that the open-endedness is hidden by the fact that you see only 
"dNSName" matching and not matching based on other parts of the identity of the resource.

Peter asked "how would a certification authority decide to issue to rsync://rsync.example.com/XX/ 
but not /YY/". The owner of example.com is the beneficiary of the certificate or attribute 
certificate. The beneficiary has that domain-specific knowledge (literally). But the certificate or 
attribute certificate provider and the beneficiary are in privity with one another. The provider has 
a contract to issue certificates and attribute certificates for the beneficiary, which the 
beneficiary pays for, and the beneficiary agrees to request certificates or attribute certificates 
only with patterns that the beneficiary actually needs.

Least privilege is good security practice, not bad. And by adding patterns, you can get least 
privileges without enumerating millions of URI combinations. PKIX artifacts are just that--digital 
artifacts. They are building blocks to implement efficient and interoperable systems that adequately 
authenticate entities as they are, and that authorize entities to access resources, on the Internet. 
And at the application level, the Internet runs on URIs.

If the pattern changes, you don't have to scrap the URI. You can revoke the certificate or attribute 
certificate. And that is the point of revocation--when the patterns in the certificate or attribute 
certificate don't match reality, you revoke and re-issue. By using patterns to apply to URIs in 
certificates, we can have computers quickly and accurately determine the right results without 
making unnecessary trips to "the well" (namely, a remote database with the access control lists). 
The only trip necessary is the one to make sure that the PKC or AC are not revoked. The revocation 
issue is already handled adequately by PKIX-conformant implementations.

Now then, are any of the following actually true:
a) the general premise of limiting identification to a larger class of resources than a single 
resource, but a smaller class than "*" has materially negative security properties;
or, that
b) there are no conceivable applications of patterns of URIs in the PKIX context to anyone now or in 
the future--and not just "no plans that I will implement this in my application?"

Thank you,

Sean

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 2010 12:28:50 -0400

Sean,

Your reply is very large and I am not going to address each of the 
comments you made in response to critiques from several folks. But I 
do want to reply to one of your comments because it reflects a common 
mischaracterization:

>...
>
>Take a look at your driver's license. It identifies you. But is it 
>authentication, or authorization? It is neither--it is a physical 
>artifact that is evidence of an authorization for *you* to drive a 
>motor vehicle. That is why it is called a "license"--because it 
>authorizes you to drive! But it's also used for authentication, 
>right? ...

A drivers license is an authorization document that is common, but 
inappropriately, used for identification.  This misuse results in a 
lot of problems from a privacy and from a security perspective. See 
the 2002 and 2003 NRC reports "IDs - Not That Easy, Questions About 
Nationwide Identity Systems,"  and "Who Goes There? Authentication 
Through the Lens of Privacy."

Steve