Internet Draft D. Groth
Intended status: Experimental ITUA Inc.
Expires: 15 February 2009 15 August 2008
OpenPGP Attribute Extension
draft-groth-openpgp-attribute-extension-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on 15 February 2009.
Abstract
A RFC was accepted extending TLS usage to include OpenPGP keys (RFC
5081) as an alternative or in addition to X.509 certificates,
however the author did not really standardise the way the
information in OpenPGP keys was to be presented and this could be
detrimental or fragment efforts to utilise OpenPGP keys in this
manner.
The author didn't touch on the issue generating confidence scores
beyond potential use of Certificate Authorities.
Groth, D. Expires 15 February 2009 [Page 1]
Internet-Draft OpenPGP Attribute Extension August 2008
Table of Contents
1. Introduction.....................................................2
2. From the Client Perspective......................................2
2.1. 6 degrees of separation in a practical sense................2
2.2. Refining Confidence Scores..................................3
2.3. Out of band fingerprint verification........................3
2.4. Commercial Services.........................................4
2.5. Retrieving Meta Information.................................4
2.6. Verification of dnsNames....................................4
3. Structure of Host Information in OpenPGP Keys....................5
3.1. New User Attribute Type -- subjectAltNames..................5
3.2. Host Names..................................................5
4. IANA Considerations..............................................5
5. Conclusions......................................................5
6. Informative References...........................................6
Acknowledgements....................................................6
Author's Addresses..................................................6
Disclaimer of Validity..............................................7
Copyright Statement.................................................7
Intellectual Property Statements....................................7
1. Introduction
This document outlines ways User Attribute fields can be used,
suitable for any OpenPGP keys being used in for a server purpose and
the information would also be in a suitable format that computers
can easily parse.
An understanding of OpenPGP (RFC 4880) is assumed by this document.
Unless otherwise specified, the character set for text is the UTF-8
(RFC 3629) encoding of Unicode (ISO 10646).
2. From the Client Perspective
2.1. 6 degrees of separation in a practical sense
The PGP web of trust is in part based on the six degrees of
separation principle: anecdotally, everyone in the world knows
everyone else through at most six other people. Henk P. Penning has
a website up that explores this very issue with OpenPGP keys,
http://pgp.cs.uu.nl/plot/ and according to his calculations most
keys have an average of just under six degrees of separation.
For the purpose of generating a tangible confidence rating that a
host controls a particular host key we will be using arbitrary
numbers. Default values of 100 points for keys marked 'I trust
ultimately', 50 points for keys marked 'I trust fully', 30 points
Groth, D. Expires 15 February 2009 [Page 2]
Internet-Draft OpenPGP Attribute Extension August 2008
for keys marked as 'I trust marginally', 0 points for keys marked 'I
don't know' and -1 point for any keys marked 'I do not trust' are
good base values although any arbitrary number should work, but may
vary based on individual circumstances.
For anyone we don't know directly, we need to calculate trust paths
between keys by decaying points from the second relationship
outwards. Again these are arbitrary values and they can be
customised based on individual needs. The general case will use a
base of 75% for ultimately trusted introduction, 50% for full
trusted introduction, 25% trust for marginal introduction, -1 for
untrustworthy and 0 for don't know.
You follow trust paths between the local key ring and the key of the
server you are intending to request information from, branching out
until you get a points value of 0 or less, or find a direct path to
the host key. In either case you no longer follow that branch any
further.
For the system to be confident about an OpenPGP key you set the
minimum points required, again this can be any arbitrary number such
as 100.
2.2. Refining Confidence Scores
The system must have the ability for more finely grained control
over individual scores. The default method in OpenPGP is too coarse,
and doesn't easily allow you to distinguish between the capabilities
of different individuals. For example you trust Bob's judgement when
verifying other people holding the right keys more than most. You
add an exception for Bob so that anything he trusts will be assigned
75 points instead of 50.
Alice on the other hand is gullible. While you trust Alice, you
don't trust the verifications she makes. An exception is made for
Alice so that anything Alice trusts will only be assigned 10 points.
In this hypothetical example, even with both Alice and Bob trusting
a key your system still wouldn't hit the 100 points needed, so you
obviously need to get out and make more friends.
2.3. Out of band fingerprint verification
Just as people already hold key signing parties to verify each
others OpenPGP user ids, variations on this would start to appear
depending on the level each party needs or wants to secure their
resources. It is a reasonable assumption that not all services need
strong protection, and it is up to both the administrators and those
making requests or connections to those services to have the right
Groth, D. Expires 15 February 2009 [Page 3]
Internet-Draft OpenPGP Attribute Extension August 2008
level of confidence that the server or service being communicated
with is really who it claims to be.
For example a bank would be at more at risk and hence worth
protecting more than a personal blog that gets 100 visitors a month.
Banks already have a relationship with their customers and it would
be easy for them to provide the fingerprint of their key(s) on
business cards and other stationary items.
This process is commonly used to verify personal keys but there is
no reason this concept couldn't be extended so people could also
sign host keys or the main organisations key which in turn is used
to sign host keys.
The worst level of confidence when connecting to another host would
be no different than using self signed X.509 certificates.
2.4. Commercial Services
It is possible to leverage existing OpenPGP web of trust meta
information to draw similar conclusions about the confidence that the
server being sent packets is the owner of the OpenPGP key used to
encrypt the request, in a similar manner people make judgements on
the confidence about the server they are connecting to with their web
browser owns the private key matching the X.509 certificate issued by
a commercial Certificate Authority.
While the focus of this draft is on individuals making their own
choices, there is nothing preventing commercial entities from
offering signing services against host keys. The standard practise is
for OpenPGP User ID(s) to be signed by multiple entities, and this
practise could be utilised by multiple commercial entities, which
would potentially increase the confidence in the key being owned by
the host you send packets to.
2.5. Retrieving Meta Information
To be able to calculate confidence scores the full host keys will
need to be retrieved from PGP key servers, this can be a timely
process and will need to be periodically re-run to ensure signatures
are still valid.
2.6. Verification of dnsNames
Before accepting such a User Attribute during use, it is a policy
decision of the client to decide which sections of the Subject
Alternative Name to consult (e.g. when connecting to
https://example.com, a web browser may receive an OpenPGP
certificate with a Subject Alternative Name UAT with two parts:
Groth, D. Expires 15 February 2009 [Page 4]
Internet-Draft OpenPGP Attribute Extension August 2008
DNS:example.com and DNS:example.net; for the browser, the second
part of the UAT is irrelevant).
3. Structure of Host Information in OpenPGP Keys
3.1. New User Attribute Type -- subjectAltNames
OpenPGP has for the longest time been mostly used for text based
communication and file encryption, so the User ID section of keys
contain a name, an email address and possibly a comment.
For computer based systems to be able to easily parse the
information present, this draft assigns a new User Attribute Packet
type as defined in RFC 4880, to be used for Subject Alternative
Names.
This section defers options to RFC 3280, section 4.2.1.7. However
this section heavily references certificate authorities and for the
purposes of OpenPGP this is interchangeable with any certifying
agent.
3.2. Host Names
At least one user attribute type must always exist and contain a
valid dnsName for any server based keys.
The client will compare the host name it connects to with all
dnsName fields present in the server key. This field can contain a
fully qualified host name or a host name with a wild card character.
Only one wild card character is allowed to exist per dnsName, so
*.example.com is valid and would match hostname.example.com and
www.example.com but would not match this.hostname.example.com.
Multiple wild card characters per host name are expressly not
allowed, *.*.example.com for example should be handled by both
server software and client software as an invalid key, and no
software should allow the creation of such dnsNames.
4. IANA Considerations
IANA needs to assign an user attribute type as set out in this draft.
5. Conclusions
Even though this draft is specifically about using OpenPGP keys for
server purposes, there is nothing special about the methods used or
the way the structure of the information in OpenPGP keys is
presented that would prevent such keys from being utilised for other
purposes.
Groth, D. Expires 15 February 2009 [Page 5]
Internet-Draft OpenPGP Attribute Extension August 2008
6. Informative References
[RFC3280] Housley, et al., " Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", Network Working Group, RFC 3280, April
2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4880] Callas, et. al., "OpenPGP Message Format", Network Working
Group, RFC 4880, November 2007.
[RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport
Layer Security (TLS) Authentication", Network Working
Group, RFC 5081, November 2007.
Acknowledgements
All the people have given valuable input, listed in no particular
order:
Philipp Guehring, Daniel Kahn Gillmor, Sam Johnston and Denise Khoo.
Funding for the RFC Editor function is currently provided by the
Internet Society.
Author's Addresses
Duane Groth
Internet Telephony Users Association Inc.
P.O. Box 75
Banksia NSW 2216
Australia
Email: support@e164.org
Groth, D. Expires 15 February 2009 [Page 6]
Internet-Draft OpenPGP Attribute Extension August 2008
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Intellectual Property Statements
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Groth, D. Expires 15 February 2009 [Page 7]